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 Oraclizer’s public Rust GKR and sumcheck engine, built using Plonky3 field, hash and challenger primitives. Its state-synchronization frontend proves sparse Merkle tree membership, non-membership and single-leaf updates. The general layered-circuit engine is also reusable by other arithmetic frontends. Prepared execution reuses the circuit, its full commitment and derived wiring for the same operation kind and configuration. Independent jobs run in parallel and retain one proof per request; encoded-proof verification binds each accepted result to the original request.

The inner GKR proof does not itself provide zero knowledge. A separate succinct ZK wrapper proves the external application relation through a backend-independent interface. The published external route uses a RISC Zero succinct proof and includes zkVerify testnet receipt evidence. The source and developer documentation (opens in a new tab) describe the available component and its integration boundaries. The engine’s design and controlled measurements are documented in the design and evaluation paper (opens in a new tab).

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. zkVerify verifies the external wrapper proof and provides an aggregation receipt. In the system design, a CDK L3 transition consumes the authenticated receipt, and the selected CDK native execution-proof backend settles that L3 state commitment on Base L2. This settlement path has its own deployment requirements; the public proof component does not establish production secondary finality by itself.

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.

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.

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. Published results include cross-domain state preservation and liveness under Byzantine faults, with the combined result published on arXiv (opens in a new tab). Connecting Rust implementation behavior to these verified models is a separate task; model proofs alone do not transfer their guarantees to a running implementation.

This direction applies to every core component developed in-house. StateSync-GKR’s formal verification paper (opens in a new tab) connects SMT semantics, compiler-model correctness and GKR assembly soundness, including the exact degree-four KoalaBear extension. Its Rust connection consists of contracts, tests and a conditional acceptance-to-model result. Whole-program value correspondence, executable challenge distribution and multi-round Fiat-Shamir security remain outside that result. Throughout the documentation, properties that have already been proven are described as such, while properties within ongoing verification are described as design intent. The StateSync-GKR verification record (opens in a new tab) and Oraclizer formal verification repository (opens in a new tab) state the relevant assumptions and boundaries.

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 inner GKR proof for the synchronization. A separate succinct ZK wrapper supplies the external proof for zkVerify verification and an aggregation receipt. The receipt-gated CDK L3 transition and the selected CDK execution-proof backend connect that result to Base L2 settlement. 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.

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.

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.

The Core Concepts section ends here. The remaining sections move from concepts to specifications.