The Privacy Paradox of Bidirectional State Synchronization

TL;DR

Bidirectional state synchronization poses a fundamentally different privacy challenge. Unidirectional oracles only needed to protect data flowing in one direction, but state synchronization creates a circular dependency: “you must disclose to synchronize, and you must synchronize to verify.” This research proposes an architecture that resolves this paradox through the philosophy of Selective Disclosure. The core insight is redefining privacy not as “what to hide” but as a four-dimensional problem: “who can see what, when, and under what conditions.” Oraclizer’s four-layer privacy stack—Identity, Contract, State, and Audit—forms independent defense lines at each layer while providing a unified, coherent privacy model. A critical innovation is the DA-based confidential storage architecture, where sensitive data is encrypted and stored in the Data Availability layer, accessible only to authorized parties with proper credentials.

---

1. Introduction: The Privacy Paradox of State Synchronization

Blockchain transparency has long been considered a virtue. The guarantee that anyone can verify the ledger and no central authority can manipulate records represents a core value of decentralized systems. Yet in the world of financial regulation, this very transparency paradoxically becomes a barrier.

In existing oracle systems, privacy was a relatively simple problem. Only a unidirectional pipeline flowing from data sources to the blockchain needed protection. Whether delivering price feeds or weather data, privacy considerations largely ended the moment an oracle node signed and posted data on-chain.

Bidirectional state synchronization poses a fundamentally different challenge:

• Reflecting on-chain state off-chain requires disclosing that state
• Reflecting off-chain state on-chain requires verifying that state’s validity
• Verification requires the verifier to know the state’s contents
• This creates a vicious cycle: “synchronization ↔ disclosure ↔ privacy loss”

This is not merely a technical challenge. GDPR requires data minimization, FATF Travel Rule requires sender/recipient information transmission, and MiCA mandates data protection obligations for crypto-asset service providers [1]. These regulations often appear to conflict. How can information be protected while simultaneously being transparently provided to regulators?

The Privacy principle of RCP (Regulatory Compliance Protocol) provides a framework for this question: a “Need to Know” based ledger model. Rather than hiding everything, it means delivering exactly the right information to exactly the right person at exactly the right time.

In this research, we explore the concrete architecture implementing this principle. Our core hypothesis: through the philosophy of Selective Disclosure and a four-layer privacy stack, the privacy paradox of bidirectional state synchronization can be resolved.

2. Redefining Selective Disclosure: Limitations of Existing Approaches

2.1 Assumptions of Existing Privacy Technologies

Current blockchain privacy technologies each have their strengths, but share one common assumption: privacy policies are fixed in advance.

Zero-Knowledge Proofs (ZKP) presuppose unidirectional decision rights where “the proof generator decides what to hide.” The prover can demonstrate to the verifier “I satisfy this condition” while concealing specific information. However, what to hide and what to reveal must be decided at proof generation time [2].

Multi-Party Computation (MPC) assumes static protocols where “participants perform only pre-agreed computations.” When designing MPC protocols, what inputs exist, what outputs emerge, and what each participant can know must be predefined.

Trusted Execution Environments (TEE) provide guarantees that data is not exposed externally since processing occurs “inside trusted hardware.” However, this requires centralized trust in the hardware.

2.2 What State Synchronization Demands

In the context of bidirectional state synchronization, these static assumptions prove insufficient.

Dynamic Policies: Financial contract states change over time. At contract inception, only the parties need to know, but when regulatory investigation begins, regulators must also gain access. At maturity, clearing institutions may need to intervene. Disclosure scope must change dynamically according to state changes.

Multi-party Decision Rights: Privacy policy decision rights don’t belong to a single entity. Senders want to protect their identity, receivers want to verify counterparty trustworthiness, and regulators must monitor for money laundering. All stakeholders need access rights according to their respective roles.

Time-Conditional Disclosure: Some information must be “hidden now, disclosed when specific conditions are met.” A bond’s interest rate may be public at issuance, but who holds that bond should only be disclosed upon regulatory request.

Hierarchical Access: The same data must provide different views depending on the accessor. Regulators can see complete transaction history, but general participants should only see portions relevant to them.

2.3 The Four-Dimensional Definition of Selective Disclosure

Reflecting these requirements, we redefine selective disclosure as follows:

SelectiveDisclosure(data) = f(WHO, WHAT, WHEN, CONDITION)

- WHO: The accessing entity's role and authority
- WHAT: Which attributes of the data to disclose
- WHEN: Time-based or event-based triggers
- CONDITION: Additional logical conditions

If traditional privacy asks “what to hide?”, selective disclosure in state synchronization asks “what to disclose, to whom, when, and under what conditions?” By defining privacy policies in this four-dimensional space, we can build a flexible privacy model that transcends the static “hide/reveal” dichotomy.

Figure 1: Four-Dimensional Selective Disclosure Matrix

3. RCP Privacy and Tensions with Other Principles

3.1 Privacy vs Traceability Tension

Among RCP’s five principles, Privacy and Traceability appear superficially contradictory.

Traceability demands transparent tracking of assets and transactions. Being able to trace who owns what and when transfers occurred is necessary to meet Anti-Money Laundering (AML) and Know Your Customer (KYC) requirements.

Privacy demands protection of sensitive information. Personal financial transaction history, asset holdings, and identity information should not be unnecessarily exposed.

The answer to “how can traceability coexist with privacy?” lies in information layering:

“What happened” is traceable, but “who was involved” is conditionally disclosed

That is, the fact that a transaction occurred, the transaction amount, and timestamp are always traceable, but the actual identities of transaction parties are linked only upon legitimate regulatory request. This is the essence of pseudonymity and conditional identity linking.

3.2 Privacy and Enforceability Cooperation

Interestingly, Privacy exists in a cooperative rather than adversarial relationship with Enforceability.

Enforceability enables regulatory intervention powers—asset freezing (FREEZE), seizure (SEIZE), confiscation (CONFISCATE), and more. For these powers to be exercised effectively, regulators must be able to access accurate information.

Paradoxically, indiscriminate transparency actually makes regulatory enforcement more difficult. When everything is public, finding signals in noise becomes harder, malicious actors secure privacy through other means, and only legitimate users suffer.

How Privacy enables Enforceability:

• Selectively disclosing specific information only to regulators → enables precise targeting
• Hierarchical access rights → prevents authority abuse and enables audit trails
• Cryptographic commitments → guarantees post-hoc verifiability

3.3 Mapping Global Regulatory Requirements

Mapping major global regulatory frameworks from a Privacy perspective:

Regulation	Requirement	Privacy Application
GDPR	Data minimization, purpose limitation	Record only essential minimum on-chain, remainder off-chain
FATF Travel Rule	Sender/recipient info transmission	Selective disclosure to regulators/FIs only, invisible to general participants
MiCA	CASP data protection obligations	Hierarchical access control, role-based permission management

The key insight from this mapping is that regulatory compliance does not require total transparency. Regulations demand specific entities’ access to specific information under specific conditions—precisely what the selective disclosure model provides.

4. Oraclizer Four-Layer Privacy Stack

To implement the four-dimensional definition of selective disclosure (WHO, WHAT, WHEN, CONDITION), Oraclizer has designed a four-layer privacy stack. Each layer forms an independent defense line while collectively providing a unified, coherent privacy model.

4.1 Overall Structure

Figure 2: Oraclizer Four-Layer Privacy Stack Architecture

4.2 Layer 1: Identity Layer

The Identity Layer forms the foundation of the privacy stack. Oraclizer implements zero-knowledge proof-based identity management using external solutions such as Privado.ID.

Core capabilities:

• Attribute Proofs: Proving specific “attributes” rather than entire identities. For example, proving “over 18” without disclosing the birthdate
• Differentiated Access by KYC Level: Services and asset classes accessible vary according to KYC verification level
• Reusable Credentials: Identity proofs issued once can be reused across multiple services

The GKR protocol-based proof system explored in our state proof optimization research can be utilized for identity proof verification at this layer. Selective Disclosure Credentials allowing users to selectively reveal portions of identity information are an actively researched area in the W3C and Hyperledger ecosystems [3].

4.3 Layer 2: Contract Layer

The Contract Layer centers on DAML’s “Need to Know” model. This layer provides contract participant-based information visibility.

DAML’s privacy model [4]:

• Signatory: Parties whose consent is required for contract creation/execution. Can see everything related to the contract
• Observer: Can view the contract but has no execution rights. Can only check state
• Default Invisibility: For all entities not mentioned, the contract’s very existence is invisible

template Trade(buyer, seller, asset, price):
  signatory: [buyer, seller]
  observer: [regulator]  -- regulator can view but not execute
  
  -- anyone outside buyer, seller, regulator doesn't know this contract exists

In the Canton network, this model is further strengthened. Each participant holds only contracts relevant to them locally, and the concept of global state itself does not exist. Synchronization occurs only between relevant parties [5].

This differs decisively from EVM. While all state is recorded on a public ledger in EVM, DAML provides different views per participant.

4.4 Layer 3: State Layer with DA-Based Confidential Storage

The State Layer handles OSS (Oracle State Synchronizer)’s selective state synchronization. A critical innovation at this layer is the DA-based confidential storage architecture.

Core mechanisms:

• Selective State Synchronization: Synchronizing only relevant states rather than the entire state tree
• GKR Proof-Based Verification: Utilizing the GKR protocol to efficiently verify “remaining state unchanged”
• Privacy Metadata: Tagging each state item with disclosure levels
• DA-Based Confidential Storage: Encrypted sensitive data stored in the Data Availability layer

The GKR protocol plays a crucial role at this layer because it enables selective disclosure of state portions while verifying the integrity of the entire state. Verifiers can see only disclosed portions yet be confident that “hidden portions have not violated any rules.”

DA-Based Confidential Storage Architecture

The traditional understanding of Data Availability (DA) focuses on ensuring transaction data remains accessible for verification. Oraclizer extends this concept: the DA layer becomes confidential storage infrastructure where encrypted sensitive data is stored, accessible only to authorized parties with proper credentials.

This architecture works as follows:

Figure 3: DA-Based Confidential Storage Architecture

Key properties of this architecture:

• Data Availability without Data Visibility: The DA layer guarantees data can be retrieved (availability) while encryption ensures it cannot be read without proper keys (confidentiality)
• Credential-Based Access: Only parties holding appropriate decryption credentials—whether transaction counterparties, designated regulators, or authorized auditors—can access the actual data
• Commitment Verification: On-chain commitments allow anyone to verify data integrity without accessing the underlying content
• Regulatory Access Path: Regulators with legitimate authority receive time-limited, scope-limited access credentials upon proper request

This design resolves the fundamental tension: sensitive financial data remains confidential during normal operations, yet becomes accessible to authorized parties when legitimate need arises—whether for transaction settlement, regulatory investigation, or compliance audit.

4.5 Layer 4: Audit Layer

The Audit Layer provides conditional identity linking through the OCID/RAI system.

How it works:

• Normal Operations: All activity is recorded in pseudonymous state
• Upon Regulatory Request: Only regulators with legitimate legal authority can conditionally link pseudonyms to real identities
• Backward Traceability: A “dormant link” activated only when necessary

This layer provides the balance point between privacy and regulatory compliance. Complete privacy is guaranteed during normal operations, but tracing becomes possible when legitimate regulatory intervention is required.

4.6 Inter-Layer Interactions

The four layers operate independently but have interdependencies:

• Lower layer privacy forms the foundation for upper layers: If Layer 1 (Identity) fails, the entire stack is neutralized
• Each layer can be upgraded independently: Maintaining modularity
• Defense in Depth: Even if one layer is compromised, other layers provide protection

This structure provides a coherent privacy model while avoiding single points of failure.

5. DAML’s “Need to Know”: Why EVM Alone Is Insufficient

5.1 EVM’s Fundamental Transparency

The EVM (Ethereum Virtual Machine) is completely transparent by design. This is not a bug but an intended feature. For all nodes to agree on identical state, all nodes must be able to see identical data.

However, this transparency creates fundamental limitations from a financial regulatory compliance perspective:

• All state is recorded on the public ledger
• Anyone can query contract storage via eth_getStorageAt
• Solidity’s private variables are actually public—they’re just hidden from the ABI [6]

// This variable is "private" but anyone can read it
uint256 private secretNumber;
// Accessible via web3.eth.getStorageAt(contractAddress, slot)

As a result of this transparency, “Need to Know” based privacy is structurally impossible in EVM.

Figure 4: EVM Transparency vs DAML Selective Visibility Model

5.2 DAML’s Selective Visibility Model

DAML takes a fundamentally different approach. In DAML, contract visibility is explicitly defined, and for parties not defined, the contract’s very existence is invisible [4].

template Asset with
    owner: Party
    issuer: Party
    amount: Decimal
  where
    signatory issuer
    observer owner
    
    -- owner can view contract as observer but cannot create 
    -- new contracts without issuer's consent
    -- all other parties cannot even know this contract exists

5.3 Implementation in Canton Network

The Canton network implements DAML’s privacy model in a distributed environment [5]:

• Participant-Local Ledgers: Each participant holds only contracts relevant to them
• No Global State: The concept of “total ledger” itself does not exist
• Selective Synchronization: State synchronizes only between relevant parties
• Encrypted Messages: Transaction contents are decrypted only for relevant parties

5.4 DAML’s Role in Oraclizer

In Oraclizer’s architecture, DAML and EVM play complementary roles:

• Off-chain Financial Contracts: Written in DAML—privacy guaranteed
• On-chain State: Recorded in EVM—only the essential minimum
• OSS Bridges Both Worlds: Provides on-chain verifiability while preserving DAML’s privacy

Crucially, DAML integration is not an “optional feature” but an essential component of regulatory-compliant state synchronization. EVM’s transparency structurally cannot provide the confidentiality financial regulations require.

6. Horizen Protocol Integration Possibilities

6.1 Horizen Protocol v1.0 Overview

Horizen Labs, as a core partner of Oraclizer, provides proof verification infrastructure through zkVerify. Simultaneously, Horizen Protocol offers additional technology stacks for privacy-preserving computation.

Component	Technology	Description
HCCE	TEE (Trusted Execution Environment)	Hardware-based confidential computing
Authority Service	Selective Disclosure Management	Selective disclosure control for regulators
Encrypted State	Encrypted State Management	Off-chain state encryption

6.2 Alignment with RCP Philosophy

Philosophical alignment exists between Horizen’s “Authority Service” and RCP’s “Privacy + Enforceability”:

• Shared Goal: Providing necessary access to regulators while protecting general user privacy
• Selective Disclosure Mechanisms: Allowing different levels of information access based on conditions
• Auditability: Enabling post-hoc tracking of who accessed what information

6.3 TEE and ZKP Complementarity

TEE (Trusted Execution Environment) and ZKP (Zero-Knowledge Proof) exist in a complementary rather than competitive relationship:

Characteristic	ZKP	TEE
Guarantee Type	Mathematical	Hardware-based
Hardware Dependency	None	Required
Computation Speed	Slow (proof generation)	Fast
Trust Model	Trustless	Hardware vendor trust

Combining these technologies enables a “Trust but Verify” pattern:

• Fast computation in TEE
• ZKP verification of TEE output correctness

This approach optimizes the performance-security tradeoff.

6.4 Integration Roadmap (Exploratory)

Note: Integration with Horizen Protocol is a research direction rather than a confirmed plan. Compatibility verification of both architectures is needed, and specific integration timing and scope will be determined based on future research results.

Current status:

• Independent research and partnership discussions ongoing
• zkVerify integration already included in roadmap

Potential extensions:

• Phase 2-3: HCCE-based off-chain computation PoC review
• Core principle: Selective enhancement of privacy stack, not full dependency

7. The Cross-Chain Privacy Downward Leveling Problem

7.1 The Downward Leveling Theorem

In cross-chain environments, privacy is determined by the weakest link:

Privacy_total ≤ min(Privacy_Chain1, Privacy_Chain2, ..., Privacy_ChainN)

The implication is clear: when synchronizing state between a private chain and a public chain, the overall privacy level is leveled down to that of the public chain.

7.2 Problem Scenario

Consider DAML contract (private) → Ethereum (public) synchronization:

1. Contract state changes in DAML (visible only to participants)
2. Synchronizing this state to Ethereum requires recording state information on-chain
3. The moment it’s recorded on Ethereum, that information becomes globally public
4. Information once disclosed cannot be undone

7.3 Solution Approach: Commitment-Based Synchronization

The solution to this problem is recording only commitments rather than actual state on public chains:

Commitment = Hash(state || nonce)

Commitments alone cannot reveal the original state, but those who know the original state can verify its match with the commitment.

When verification is needed:

• ZKP proves “the state I have matches this commitment”
• Original state exists only in private channels (including DA-based confidential storage)
• Public chain records only commitments and ZKPs

7.4 ZK Bridge Protocol Concept

Extending this principle suggests a ZK Bridge protocol:

PrivateChain → ZK Proof Generation → PublicChain
              (hides state, proves only validity)

Core properties:

• State “existence and validity” is proven
• State “contents” are not disclosed
• The proof systems explored in our optimization research play a key role here

The limitation of this approach is that the public chain side cannot know “what was synchronized.” However, in many regulatory compliance scenarios, this is an intended feature—the public chain only needs to know “a valid state transition occurred,” not the specific contents.

8. Challenges and Open Questions

8.1 Performance vs Privacy Tradeoff

Privacy enhancement inevitably incurs performance overhead:

Privacy Mechanism	Overhead	Mitigation Strategy
ZKP Generation	High computation cost	Incremental proofs, batch processing
Selective Synchronization	Complex access control	Caching, pre-computation
Encrypted State	Decryption latency	Hardware acceleration (TEE)
DA-based Confidential Storage	Retrieval overhead	Locality optimization, credential caching

The GKR protocol explored in our state proof optimization research partially mitigates this tradeoff—sumcheck protocol efficiency reduces proof generation costs. However, the fundamental tradeoff persists, requiring application-specific optimization.

8.2 Regulatory Authority Scope Issues

The definition of “as much as needed” varies by jurisdiction:

• Some regulators require real-time access
• Some regulators require only post-hoc audits
• Some regulators’ scopes conflict with others

Technical solutions have limits. Ultimately this is a legal and political issue; technology can only provide flexibility to support various policies.

Regulatory authority abuse potential must also be considered. Even with selective disclosure mechanisms, if authorized entities misuse their authority, privacy guarantees are neutralized. This falls in the realm of governance and legal protection, not cryptography.

8.3 Open Questions

A fundamental question that keeps emerging throughout this research:

“Can perfect privacy and perfect regulatory compliance coexist?”

Theoretical answer: Through selective disclosure, “sufficient” coexistence is possible. If we can precisely control what information is disclosed to whom and when, both privacy and regulatory compliance can be achieved “to the necessary degree.”

Practical answer: Regulatory requirements change. Today’s “sufficient compliance” may become “insufficient” tomorrow. Architecture must embed flexibility to adapt to change.

Philosophical answer: The concept of “perfect” itself may be unrealistic. Neither perfect privacy (no one can know anything) nor perfect regulatory compliance (everything always visible) is actually achievable or desirable. The realistic goal is finding a pragmatic equilibrium.

8.4 Future Research Directions

FHE (Fully Homomorphic Encryption): If computation can be performed directly on encrypted state, the privacy-performance tradeoff fundamentally changes. However, current FHE performance falls short of practical levels.

Horizen Protocol Evolution: Stage 2-3 technological developments should be monitored, with continuous evaluation of synergies with Oraclizer architecture.

RegTech Standardization: For selective disclosure mechanisms to work effectively, standardized interfaces between regulators and technical systems are needed. This is as much a policy challenge as a technical one.

---

Conclusion

Privacy in bidirectional state synchronization poses new problems that existing approaches cannot solve. The paradox “to synchronize you must disclose, and disclosure loses privacy” is not merely a technical limitation but a structural challenge.

The Selective Disclosure philosophy presented in this research provides one framework for this paradox. By redefining privacy not as “what to hide” but as a four-dimensional problem—WHO, WHAT, WHEN, CONDITION—a design space opens where both regulatory compliance and privacy can be pursued simultaneously.

Oraclizer’s four-layer privacy stack—Identity, Contract, State, Audit—implements this philosophy in concrete architecture. Each layer forms an independent defense line while collectively providing a coherent privacy model. DAML’s “Need to Know” model in particular enables contract-level privacy that EVM’s structural transparency cannot provide.

A critical innovation is the DA-based confidential storage architecture at the State Layer. By storing encrypted sensitive data in the Data Availability layer—accessible only to authorized parties with proper credentials—we resolve the apparent conflict between data availability (required for decentralized verification) and data confidentiality (required for regulatory compliance). Transaction counterparties, designated regulators, and authorized auditors can access the information they need, while unauthorized parties see only cryptographic commitments.

Integration possibilities with Horizen Protocol suggest research directions that could further strengthen this architecture. The combination of TEE-based confidential computing and ZKP optimizes the performance-security tradeoff.

Of course, open questions remain. The possibility of perfect privacy and perfect regulatory compliance coexisting, practical levels of performance overhead, regulatory authority scope and abuse prevention—all these demand continued research and experimentation.

Our next research will analyze the security threats and attack vectors this privacy architecture faces. Privacy preservation is inseparably linked to security, and understanding the security model of state synchronization systems is essential for true privacy guarantees.

---

References

[1] Financial Action Task Force (FATF). (2021). Updated Guidance for a Risk-Based Approach for Virtual Assets and Virtual Asset Service Providers. https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-rba-virtual-assets-2021.html

[2] Ramić, Š. B., et al. (2024). BLS-MT-ZKP: A Novel Approach to Selective Disclosure of Claims from Digital Credentials. IEEE Access 12. https://doi.org/10.1109/ACCESS.2024.3518597

[3] W3C. (2024). Verifiable Credentials Data Model v2.0. https://www.w3.org/TR/vc-data-model-2.0/

[4] Digital Asset. (2024). Daml SDK Documentation: Privacy. https://docs.daml.com/concepts/ledger-model/ledger-privacy.html

[5] Canton Network. (2024). Technical Architecture. https://canton-network.info/technology.html

[6] Ethereum.org. (2024). Ethereum Virtual Machine (EVM). https://ethereum.org/developers/docs/evm/

[7] Oraclizer Research. (2025). EIP-RCP: Regulatory Compliance Protocol for Tokenized Assets.

https://research.oraclizer.io/wp-content/uploads/2025/12/EIP_RCP_draft_v1.0.3.pdf

---

Learn More

Related Research from Oraclizer:

• GKR Protocol Deep Dive: The Computational Engine Behind OSS
• Sparse Merkle Trees in Oracle State Synchronization