Skip links
Oraclizer
Oraclizer

    Introduction

    Oraclizer is the first regulatory-compliant oracle state machine that achieves bidirectional state synchronization between on-chain and off-chain systems.

    Conventional oracles are data feeds that deliver external data to the blockchain. Some can transmit data in both directions, but this amounts to two independent unidirectional channels operating separately, not an atomic binding of state across both sides. Because each direction is processed independently, timing gaps emerge between on-chain and off-chain, and inconsistencies arise when only one side succeeds.

    For tokenized real-world assets (RWAs), this inconsistency is critical. The next stage of asset tokenization moves beyond representing a value on-chain toward reflecting the full lifecycle of an asset that exists in regulated, off-chain financial systems. Events such as coupon payments on bond tokens, regulatory asset freeze orders, and derivative exercise actions must either succeed or fail simultaneously on both on-chain and off-chain systems. If only one side reflects the change, asset state integrity breaks down.

    Oraclizer is designed to solve this problem. It atomically binds bidirectional state changes so that the complete state of tokenized assets (ownership, regulatory status, contract terms, maturity, coupon payments, and more) remains consistent across on-chain, off-chain, and cross-chain environments. The core of this design, cross-domain state preservation homomorphism, has been formally verified using Isabelle/HOL and published on arXiv, providing a mathematical proof that regulatory state synchronization across chains is correct.

    Why regulatory compliance comes first

    Tokenized real-world assets are subject to financial regulation at every stage: issuance, trading, and custody. Unless regulatory requirements such as AML/KYC verification, asset freezing, and forced liquidation are guaranteed at the protocol level, traditional financial institutions cannot accept on-chain assets. This is not a matter of preference but a structural precondition: interoperability without regulatory compliance does not hold in the RWA domain.

    Oraclizer adopts the Regulatory Compliance Protocol (RCP) as its design principle. RCP systematizes 31 core requirements from 15 global financial regulators into a protocol where regulatory compliance is embedded within the state synchronization layer itself.

    RCP defines five principles that give regulatory compliance concrete meaning at the protocol layer: Traceability, Privacy, Enforceability, Finality, and Tokenizability. Each principle maps to specific mechanisms in the Oraclizer architecture. Enforceability is realized through the six regulatory actions of ERC-TRUST and the priority sequencing of D-quencer; finality is realized through a two-tier structure combining GKR-based pre-trading finality with fflonk and zkVerify settlement finality.

    RCP is the result of regulatory research that began in the second half of 2023, before any code was written, distilling the requirements of fifteen global financial regulators into a single design specification. Conducting this work first matters because a state synchronization protocol that handles regulatory state on equal footing with ownership state cannot be retrofitted to satisfy regulatory rules later. The interfaces, the reachable states, and the actions a sequencer must prioritize are all consequences of decisions made during that earlier research. Compliance is therefore built in at the architectural level, in a manner similar to how DAML embeds compliance into its language and ledger model. Oraclizer extends this regulatory built-in approach from the off-chain DAML world into the on-chain world, allowing the two sides to be connected through a shared regulatory model rather than reconciled through application-layer translation.

    Formal verification at the center of the design

    An oracle state machine that binds state across regulated, heterogeneous domains is not a familiar object in the blockchain field. There is no precedent that can be relied on to confirm that the design is correct. Testing alone cannot establish correctness for a system whose central guarantee is atomicity across domains: tests demonstrate that observed cases work, while the property the system needs to provide is that no reachable case violates atomicity. For a system whose primitives are new, this gap has to be closed by other means.

    Oraclizer is therefore designed with formal verification at its center rather than as an after-the-fact assurance step. The state synchronization model, the regulatory state preservation property, the consensus liveness conditions, and the rollback hierarchy are formalized in Isabelle/HOL and proven against explicit assumptions. The first two properties have already been formally verified and published on arXiv: cross-domain state preservation establishes that regulatory state is preserved exactly under cross-domain transitions, and liveness under Byzantine faults proves deterministic resolution, deadlock freedom, and starvation freedom under the standard f < n/3 threshold. Further properties are being proven as the protocol takes shape, and the implementation will track these proofs through Rust verification tools so that the running system stays connected to the model that was proven.

    The reason for this approach is straightforward: introducing a new primitive into financial infrastructure requires more than functional correctness in observed cases. It requires a precise statement of what is being claimed and a proof that the claim holds. Throughout the documentation, references to formally verified properties point to specific theorems in the Oraclizer formal verification work; statements that have not yet been proven are described as design intent rather than guarantees.

    Key capabilities

    Bidirectional state synchronization. Conventional oracles stop at unidirectional delivery, writing external data on-chain. Oraclizer’s Oracle State Synchronizer (OSS) synchronizes asset state bidirectionally across on-chain, off-chain, and cross-chain environments. An off-chain coupon payment event is automatically reflected in the on-chain token state, and an on-chain regulatory action is immediately propagated to off-chain systems. After the initial Oracle Contract, state changes are tracked continuously without per-event oracle requests.

    Atomic state binding through Bind-Verify-Commit. State synchronization is performed through the Bind-Verify-Commit (BVC) pattern: preemptive locks are acquired across all relevant domains (Bind), the validity of the state transition is verified with a GKR-based proof (Verify), and the result is propagated atomically to every domain (Commit). Failure at any step releases all locks and rolls back the entire cycle. D-quencer, the decentralized sequencer, guarantees the sequencing integrity of each BVC cycle through BLS-signature consensus and VRF-based leader election, satisfying the Stage 1 Rollup security model. Each Oracle Session, defined as the state synchronization contract between a single asset-owner pair, begins with one BVC cycle and benefits from lower latency for subsequent syncs within the session. One consequence of this design is that the structural conditions for Oracle Extractable Value (OEV), namely timing gaps and update races, do not arise; preemptive locks serialize concurrent transactions rather than letting them compete through fee ordering.

    Protocol-native regulatory compliance. Most blockchain systems handle regulatory compliance retroactively at the application layer. Oraclizer defines six regulatory actions at the protocol level (FREEZE, SEIZE, CONFISCATE, LIQUIDATE, RESTRICT, RECOVER), and regulatory requests are executed atomically across every chain where the asset exists. An asset freeze order issued on Chain A is simultaneously enforced on every chain where the same asset has been bridged.

    Privacy-preserving regulatory traceability. Privacy and regulatory traceability are usually treated as opposing requirements. Oraclizer combines them through selective disclosure: zk-basis ID proves identity attributes (residency, accreditation, sanctions clearance) without revealing the underlying personal data, while authorized regulators retain auditable visibility into asset state under defined conditions. The L3 additionally operates in Validium mode by default, keeping transaction details off the public chain while preserving cryptographic verifiability. The result is a system where compliance and confidentiality coexist by construction rather than by application-layer compromise.

    Economic feasibility of continuous synchronization. Bidirectional state synchronization involves numerous sub-transactions internally. Under the per-call pricing structure of conventional oracles, this cost would exceed the value gained from synchronization, making continuous synchronization economically unviable. Oraclizer addresses this through two complementary mechanisms. First, the GKR-based proof system removes intermediate commitment overhead that prior SNARK constructions impose, which is what makes high-frequency state synchronization computationally tractable in the first place. Second, a five-stage cost structure (L3 architecture, Validium, zkVerify offloading, incremental state processing, and SMT optimization) brings per-sync cost into the range required for production use. Together these enable a billing model that does not exist on per-call oracles: state subscription per Oracle Session rather than pay-per-gas on each event. Once a session is established, continuous synchronization within it is amortized across the session, not charged per state change.

    Figure 1: Documentation reading paths by audience

    Documentation guide

    This documentation site serves as a technical reference for developers, partners, and operators looking to participate in the Oraclizer ecosystem. Choose the path that matches your objective.

    DeFi protocol developers: Start with System Architecture to understand the three-layer architecture, then review the OIP specification in Protocol Specification, and follow the RWA Registry integration guide in DeFi Integration.

    RWA tokenization partners: Begin with What is Oraclizer to understand the oracle state machine concept, then review RCP principles and the regulatory action framework in Regulatory Compliance, and explore bidirectional synchronization mechanics in State Synchronization.

    Node operators: Start with System Architecture to understand the infrastructure layer (L3, D-quencer, zkVerify), then review node architecture and consensus mechanisms in Network Operation.

    Evaluators and partners: Start with What is Oraclizer to see how Oraclizer differs from conventional data oracles, then read State Synchronization and System Architecture in order for a quick overview of the full system.

    Technical research and development updates are available through the following channels.

    Table of Contents