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.
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
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:
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
privatevariables 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.
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:
- Contract state changes in DAML (visible only to participants)
- Synchronizing this state to Ethereum requires recording state information on-chain
- The moment it’s recorded on Ethereum, that information becomes globally public
- 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] Bećirović Ramić, Š., 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 Info. (2025). 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.