System Architecture
The previous pages introduced what Oraclizer does: bidirectional state synchronization for tokenized real-world assets, with regulatory compliance built into the protocol. This page describes the components that make those properties operational, organized into a three-layer architecture: the application layer where assets and identities are managed, the protocol layer where synchronization rules are defined and executed, and the infrastructure layer where the system runs.
Each component covered here has a dedicated page or section elsewhere in the documentation that goes deeper. The goal of this page is to give a single map of how the components fit together.
The three layers
Oraclizer is organized into three layers that correspond to three distinct concerns: what is being synchronized (application), how synchronization is defined and enforced (protocol), and where it actually runs (infrastructure). The layering is not just a presentation device; each layer has different upgrade cadence, different stakeholders, and different points of integration.
Application layer
The application layer is where regulated assets and identities live. Two primary components occupy this layer.
OracleMint is the tokenization platform. It is where real-world assets (bonds, equity, structured products, real estate, commodities) are issued as tokens with the legal properties required for regulated finance. OracleMint defines the token’s contract terms, regulatory class, lifecycle parameters (maturity, coupon schedule), and transfer restrictions. Once issued, the asset’s state is maintained through the protocol layer.
zk-basis ID is the identity component. It performs KYC and identity verification using zero-knowledge proofs, allowing parties to prove eligibility (residence, accreditation, sanctions clearance) without revealing the underlying personal data. zk-basis ID can leverage external identity infrastructure such as Privado.ID for the underlying primitives, and integrates with the protocol layer through a defined interface.
Protocol layer
The protocol layer is where the rules of state synchronization are defined and where individual synchronizations are executed. Two components occupy this layer, and they have a specific relationship that is worth understanding.
OIP (Oracle Interoperability Protocol) is the specification. It defines what a state synchronization message looks like, which state transitions are valid, how regulatory actions are encoded, how routing works, and how cross-chain coordination is achieved. OIP is the protocol document; it is what implementations must conform to in order to interoperate. OIP is published in versioned releases under Protocol Specification.
OSS (Oracle State Synchronizer) is the implementation. It is the component that actually performs synchronizations: detecting state changes in their origin domain, running them through the Bind-Verify-Commit cycle, generating proofs, and committing them across every domain where the asset exists. OSS organizes synchronizations around Oracle Sessions, the per-asset, per-owner contracts that maintain state continuity over time. OSS implements OIP, and any other system that implements OIP correctly can interoperate with Oraclizer’s OSS.
This separation matters because it is what makes Oraclizer a protocol rather than a closed system. The OIP specification is intended to be implemented by other parties as well, with OSS serving as the reference implementation.
OIP and OSS are presented together as the protocol layer because they jointly define how synchronization operates at the protocol level. A specification without an implementation is inert; an implementation without a specification cannot be verified for conformance. The two are inseparable in practice, even though they are distinct artifacts.
Infrastructure layer
The infrastructure layer is where the protocol runs. It includes the chain Oraclizer is deployed on, the consensus mechanism, the proof systems, the registry that records asset state, the cross-chain message integrity layer, and the drivers that connect to off-chain systems.
L3 zk-Rollup / Validium. Oraclizer runs as an L3 built on Polygon CDK, settling on Base (L2), which in turn settles on Ethereum (L1). The L3 architecture is what makes high-frequency state synchronization economically feasible: by amortizing settlement cost across many synchronizations and offloading proof verification, Oraclizer brings continuous synchronization within a viable cost range. The L3 operates in Validium mode by default (data availability outside the chain), with Volition support that lets specific transactions or assets opt into zk-Rollup mode (data on the L1) when stronger guarantees are required.
D-quencer is the decentralized sequencer. It selects which transactions are processed in which order using BLS-signature consensus and VRF-based leader election. D-quencer is what gives Oraclizer Stage 1 Rollup security: no single party controls transaction ordering, regulatory action priority is enforced consensually rather than by a central operator, and the network can survive operator failure without requiring user intervention. The Stage 1 standard is a recognized benchmark for rollup decentralization that ensures users retain self-sovereign exit paths even under adverse operator behavior.
StateSync-GKR is the synchronization proof generation stack. Built on a modular zero-knowledge proof toolkit, StateSync-GKR is being developed in-house to fit the specific workload of state synchronization: high-frequency, low-latency, sparse Merkle tree verification with deterministic deadlines. It uses the GKR protocol for low-overhead proof generation, with fflonk wrapping for compatibility with the broader proof verification path. Where zkVerify handles batch verification of proofs, StateSync-GKR is what generates them on the L3 in the first place.
zkVerify is the proof verification system, integrated through Horizen Labs. Oraclizer uses zkVerify to offload proof verification from Ethereum L1, where verification gas would dominate cost. The combination of GKR-based proofs from StateSync-GKR, fflonk wrapping, and zkVerify batch verification is what makes the cost structure tractable.
RWA Registry is the smart contract layer that records asset state on the L3. It is the system of record for which assets exist, who owns them, what their regulatory state is, and what their lifecycle position is. Other contracts (DeFi protocols using assets as collateral, custodians querying ownership) read from the RWA Registry. The RWA Registry is described in detail in DeFi Integration.
CCMI (Cross-Chain Message Integrity) is the cross-chain layer. CCMI is not a stand-alone bridge product; it is an internal module of OSS that handles message integrity guarantees (replay resistance, source authentication, dual-chain commit atomicity, threshold soundness) when state synchronizations cross from one chain to another. Treating cross-chain integrity as part of the synchronization protocol, rather than as a separate bridge, is what allows the same atomicity guarantees to apply across chains as within a single chain.
External system Drivers connect the L3 to off-chain systems. The Canton Driver is the primary driver in this category, providing integration with the Canton network where many regulated assets are issued and held under DAML-based contracts. Other drivers connect to additional off-chain systems as integration is needed.
For data availability, Oraclizer uses a DAS-based (Data Availability Sampling) approach. The current deployment uses a single DA provider; the architecture supports multiple DA providers and can switch between them without protocol changes. Specific DA provider choices are operational decisions and are addressed in Network Operation.
Formal verification as an architecture principle
One property cuts across the infrastructure layer rather than belonging to a single component: Oraclizer treats formal verification as an architecture principle, not a downstream review activity. Core protocol properties are specified as theorems in Isabelle/HOL and proved at the model level. Two properties have already been proven in this program, cross-domain state preservation and liveness under Byzantine faults, with the combined result published on arXiv. The Rust implementations of OSS, D-quencer, StateSync-GKR, and other core modules are written to maintain a refinement relation against these verified models, so that the implementation inherits the model’s correctness guarantees rather than re-deriving them from tests.
This direction applies to every core component developed in-house, including the StateSync-GKR proof stack, where the long-term goal is to extend refinement proofs from the protocol logic down to the prover implementation. The intent is not to claim verification of every line of code, but to ensure that the properties Oraclizer relies on (regulatory state preservation across domains, lock correctness, rollback soundness, and others) are backed by mathematical proof rather than by engineering judgment alone. Throughout the documentation, properties that have already been proven are described as such, while properties that are within the scope of ongoing verification are described as design intent that the formal verification work is responsible for establishing. Completed verification artifacts are published in the oraclizer/formal-verification repository.
Figure 1: The three-layer architecture
Identity in the architecture: OCID and RAI
One identity-related concept is worth clarifying separately because it crosses layers and is easy to confuse. Oraclizer uses two related identifiers, OCID and RAI, that operate at different levels of abstraction.
RAI (Regulated Asset Identity) is a generic interface intended for proposal as an EIP standard. RAI defines what regulated identity should look like at the standard level: how to bind transactions to verified parties, how to express authority, how to support selective disclosure. RAI is designed so that any compliant token system can adopt it, regardless of which oracle or synchronization protocol it uses.
OCID (Oracle Contract ID) is Oraclizer’s concrete implementation of RAI. OCID adapts the RAI interface to Oraclizer’s specific architecture: it integrates with zk-basis ID for proof generation, with the RWA Registry for asset binding, and with OSS for cross-domain identity propagation. OCID is to RAI what an OSS is to OIP: a specific implementation of a more general standard.
The distinction is intentional. Oraclizer needs identity primitives that work concretely in its architecture (OCID), but it also wants the broader Ethereum ecosystem to converge on a regulatory identity standard that is not Oraclizer-specific (RAI). Treating them as the same thing would either lock the standard to Oraclizer’s implementation choices or force Oraclizer to delay its own development until external standardization completes. Treating them as separate keeps both efforts moving without entangling them.
How a request flows through the system
The static layout in Figure 1 shows where components are. The dynamic flow shows how they work together. The path a typical state synchronization takes through the architecture connects the layers in a defined order, with each layer contributing a specific kind of work.
A state change originates somewhere: in an off-chain ledger via a Canton Driver, in a smart contract on the L3, or on an external chain via CCMI. The originating event is detected and submitted to OSS, which validates the proposed transition against OIP rules, checks regulatory constraints, and runs the Bind-Verify-Commit cycle. D-quencer determines the ordering of the cycle’s transactions in the L3, ensuring regulatory actions take priority where required. StateSync-GKR generates the GKR-based proof for the synchronization, with fflonk wrapping for the verification path. zkVerify performs batch verification of these proofs, offloading verification cost from L1. The RWA Registry records the final state, and the change is propagated to every domain where the asset exists, atomically.
The flow below summarizes this path. It is a simplification: real synchronizations involve concurrent locks, partial failures, and retries, all described in detail in the protocol specification. But the high-level shape is what most architectural decisions in Oraclizer optimize for.
Figure 2: How a state synchronization flows through the architecture
Where the L3 sits
One detail of the infrastructure layer is worth showing explicitly because it determines both economic feasibility and security posture: the position of the Oraclizer L3 in the broader Ethereum stack. Oraclizer is built as an L3 on top of Base, which is itself an L2 on Ethereum.
This three-tier positioning is deliberate. Ethereum L1 provides settlement finality: every Oraclizer state transition ultimately inherits Ethereum’s security through the proof chain. Base L2 provides a cost-amortized layer with established tooling and ecosystem integration. Oraclizer L3 provides the application-specific environment where state synchronization can run at the frequency RWAs require, with regulatory action priority enforced at the sequencer level. External EVM chains (Arbitrum, Optimism, and others) connect through CCMI, with their own settlement paths to L1.
Figure 3: The Oraclizer L3 in the Ethereum stack, with CCMI connections to external chains
Where to go from here
This page is a map. Each component covered here has a dedicated section that goes deeper.
For the protocol layer, Protocol Specification describes OIP in detail: the message types, state transition rules, routing logic, and cross-chain coordination. For DeFi developers integrating with Oraclizer, DeFi Integration walks through how to interact with the RWA Registry and respond to state synchronization events. For node operators and partners running infrastructure, Network Operation describes the L3 deployment, D-quencer node setup, and operational parameters.
The Core Concepts section ends here. The remaining sections move from concepts to specifications, integration, and operations.