THE ORACLE STATE MACHINE
State should move as one.
An asset's token, its custody record, its contract and its regulatory status usually live in different systems. Oraclizer is built to move them in one step that either happens everywhere or nowhere.
Designed for tokenized securities, institutional ledgers, and cross-domain asset operations.
The affected domains commit together or roll back together. A partially applied result is outside the permitted state space.
WHY STATE SYNCHRONIZATION
A price can be delivered. A financial state has to be coordinated.
A data feed can tell a contract that a price changed. It cannot, by itself, keep a token, a custody record, an off-chain contract, and a regulatory action in the same causal state. Oraclizer treats the transition, its authority, its policy context, and its result as one protocol object.
Data feed
Observe a value. Publish an update. Leave each destination to determine what happens next.
Oracle state machine
Bind the affected domains. Verify the transition and its context. Commit one result, or leave every bound domain unchanged.
MODEL-LEVEL ASSURANCE
Prove the model. Refine the system.
Oraclizer uses machine-checked formal models to establish its declared properties. The assurance program targets core-wide refinement: a traceable correspondence from those formal semantics through protocol and implementation layers. As refinement obligations are discharged, model-level guarantees become system-level guarantees for the exact mapped code and deployment boundary.
Mechanized semantics
State, authority, transition, failure, and preservation properties are stated in Isabelle/HOL so the proof kernel can check the declared model instead of relying on prose alone.
Adversarial examination
Counterexamples, mutation tests, assumption ledgers, and independent recomputation are used to expose vacuous proofs, hidden preconditions, and claims that exceed their evidence.
Core-wide refinement target
Explicit obligations map formal state and transition semantics into protocol behavior, implementation code, compiled execution, and deployment identity. A system-level claim is made only for the boundary whose correspondence has been demonstrated.
THEORY INTO SYSTEMS
From a proved model to an assured system.
The figure maps mechanized semantics, explicit refinement obligations, executable components, and deployment evidence into one assurance path. It distinguishes the model-level properties demonstrated today from the core-wide refinement target.
PRECONDITIONS
Six problems came before the machine.
An oracle state machine begins where a data feed stops. Before one could exist at all, six problems had to be answered, and no two of them belong to the same discipline. Each is a precondition rather than a feature, which is why answering five of them still leaves nothing that runs.
A vocabulary for regulation
A freeze, a seizure, a forced transfer. Before any of these can be synchronized, a machine has to know what they are, who is entitled to order them, and what happens when one fails. No such vocabulary existed. Two years of regulatory research came before the first line of protocol design, and the requirement set it produced became ERC-8319.
Traceable privacy
Regulated assets need two things that normally exclude each other: a history a supervisor can audit, and detail a competitor cannot read. Selective disclosure at the identity layer and transaction data held off the public chain let both hold at once, so confidentiality stops being something you buy by making the record unauditable.
Time that separate chains agree on
Chains disagree about when something is final, and a cross-domain commit that ignores the disagreement is a reorganization waiting to be discovered. The core tracks finality per chain and commits only once every bound domain has settled. That is the difference between a synchronization and a hopeful write.
Sequencing that is neither centralized nor indifferent
A freeze that waits its turn is a freeze that failed, so ordering cannot be indifferent to what it orders. Yet a sequencer that can be told what to order is the thing decentralization was supposed to prevent. Oraclizer separates the layers: operations stay fully decentralized, regulatory intervention stays transparent and bounded, and D-quencer follows a deterministic rule that nobody gets to override.
Proving that keeps a deadline
Continuous synchronization means proving the same sparse-Merkle state again and again, against a clock, and a proof that arrives late is a proof that did not matter. General-purpose proving systems are not tuned for that repetition, which is why the prover for this workload was built in house.
A cost that survives repetition
A synchronization cycle that costs more than the asset it moves never becomes infrastructure. L3 execution, off-chain data availability, external proof verification and incremental state updates are in the design for one reason: to make continuous synchronization something an institution can afford to run continuously.
Where each of these stands today is stated in the section that owns it.
SYSTEM ARCHITECTURE
No layer you have to take on faith.
Protocol meaning, execution, proving, sequencing and external integration are kept apart, so each one can be specified, tested and argued with on its own.
OIP v0.5
The full protocol specification is public: messages, routing, validation, regulatory actions, cross-domain coordination and conformance. Anyone can read what Oraclizer commits to before there is a system to run it against.
Read OIP v0.5 (opens in a new tab)Oracle State Synchronization System
The execution core. It holds one synchronization cycle open across every participating domain, binds them, checks the transition against its authority and policy, then commits everywhere or nowhere. Rollback is a designed path here and not an exception handler, so a refusal anywhere returns every bound domain to its prior state and the design admits no outcome that leaves half of them updated.
Implementation link reservedD-quencer
Sequencing built for synchronization cycles rather than for generic transactions. It orders deterministically under declared Byzantine assumptions and lets a time-critical regulatory action take priority, because a freeze that waits its turn is a freeze that failed.
Architecture in developmentStateSync-GKR
A new GKR engine tuned for high-frequency state synchronization: the same sparse-Merkle state proved over and over, against a clock. SNARK-based provers pay for a trusted setup, polynomial commitments and large FFTs that this workload never needs, and StateSync-GKR pays for none of them. Proof jobs are fully independent, so throughput scales with cores instead of coordination, and verification stays flat at 6 to 10 milliseconds whether the tree is shallow or deep. Testing on AVX-512 hardware reaches 2,000 to 4,200 synchronizations per second.
Repository reserved for public releaseIntegration layer
The RWA Registry, Canton Driver, and cross-chain message-integrity layer connect asset metadata, enterprise ledgers, and external state paths without making one external system the source of every truth.
Review the architecture (opens in a new tab)SUBSCRIPTION GAS
Metered by the session, not by the message.
Ethereum charges per transaction, but a synchronization cycle spans domains, holds state open and completes as one unit. Oraclizer meters the session an asset and its owner hold open, counting only the bound transitions that committed. Every input to a charge lands in the public event log, so anyone holding a bill can recompute it from consensus state.
USE CASES
What becomes possible when the whole asset moves.
About $60 billion of real-world assets are already tokenized, and most of that sits still, because the token can move while the interest, maturity, eligibility and regulatory status behind it do not. Oraclizer's own analysis puts 54 to 68 percent of the tokenized market on the side that needs its state moved rather than reported, bonds highest at 78 percent. On 2030 projections that is $1.1 trillion to $3.4 trillion of assets no oracle was built to serve.
Collateral that can actually be liquidated
A tokenized bond is only collateral if a liquidation can move the token, the custody record and the legal claim in one step. Where it cannot, lenders discount the asset or refuse it outright, which is why real-world collateral sits at the edge of on-chain credit instead of inside it. A price feed can tell a lender what the bond is worth. It cannot move the claim behind it.
Regulatory actions that execute
A freeze, a seizure or a forced transfer arrives as an instruction with authority behind it, not as a request to somebody's back office. Each action carries its own authority, state effect, failure behaviour and receipt, so a regulated asset can trade in a permissionless venue without that venue having to act as the regulator.
State synchronization with Canton's $6 trillion
Institutions put tokenized bonds, funds, repo and mortgages on Canton precisely because those assets will not settle on a public chain. They are worth considerably more the moment they can reach on-chain venues without leaving the compliance perimeter, and that takes a transition which commits on the institutional ledger and the public chain together, or on neither.
Assets that run their own lifecycle
Coupons, maturity, redemption and corporate actions move the token and the contract behind it in the same step, instead of being reconciled afterwards by two teams comparing records. The asset carries its lifecycle rather than waiting for someone to replay it.
These are the workflows the architecture is designed for. Each one is specified in the public protocol and modelled formally, ahead of production.
STANDARDS
A freeze has to mean the same thing everywhere.
Oraclizer's standards work gives regulatory actions, their authority, their outcomes and their receipts a machine-readable identity, so separate ledgers can agree on what actually happened to an asset.
ERC-8319 · Regulatory Compliance Protocol
Six regulatory actions, each with a defined authority, state effect and failure behaviour, and thirty-one requirements drawn from fifteen financial regulators organized under five principles. Assigned number 8319 in the Ethereum ERCs repository. It gives a token standard a common way to state which regulatory obligations it actually enforces and which it leaves to somebody else.
ERC-TRUST · Typed Regulatory Uniformity for Security Tokens
An execution standard for regulatory actions on security tokens. It gives actions, authorization, outcomes, failures and receipts machine-readable identities, so two systems can disagree about policy and still agree about what happened, while identity and deployment structure stay environment-specific.
Execution and conformance work in developmentTyped Regulatory Actions and Execution Receipts for Canton Tokens
A Canton Improvement Proposal for interoperable regulatory actions and typed execution receipts in Canton token implementations, leaving policy and authority models to each implementation. Canton is one of the few institutional ledgers built on a formal ledger model, which is what makes a cross-domain claim about it something to prove rather than something to assert.
Not submittedPUBLISHED RESEARCH
Read the argument before you trust the system.
The requirement frameworks, formal models and design arguments behind Oraclizer are published in full. So are the boundaries of what they cover.
Regulatory Compliance Protocol
A framework for measuring how completely a token standard represents regulatory requirements and enforcement state, applied to the standards already in use. Its requirement set is what ERC-8319 was built from.
View on arXiv (opens in a new tab)The Cross-Domain State Preservation Functor
A machine-checked Isabelle/HOL theory of what it takes to preserve state across systems that do not share a model of it, organized as a functor. When both sides are formally specified, as a public chain and Canton's ledger model are, the connection between them can be proved rather than promised.
View on arXiv (opens in a new tab)Formal Verification
Public machine-checked artifacts cover cross-domain state preservation, synchronization-degree monotonicity, and regulatory-action semantics. The degree result is proved in both directions: a higher degree safely carries a lower-degree asset, and a lower one provably cannot. The repository is run as a maintained public research surface, with reviewed changes, reproducible sessions, released artifacts and a security reporting path.
Explore formal verification (opens in a new tab)Structural OEV Elimination through State Synchronization
OEV exists because an oracle update becomes visible before the position it moves has settled, and extraction lives in that interval. The post shows what happens when both events are bound into one all-or-nothing transition: the set of states an extractor needs is empty, so the window is not narrowed or auctioned off, it stops existing. It also draws the line between what this removes and what no update design can remove.
Read the discussion (opens in a new tab)Research Library
Long-form research across state synchronization, formal methods, protocol design, regulation, real-world assets and tokenized markets. Most of the design decisions in Oraclizer were argued here first.
Browse the library (opens in a new tab)NEXT RESEARCH
Typed Regulatory Execution
An ERC-TRUST security-token case study carrying one standard from machine-checked semantics, through adversarial analysis, to the exact deployment boundary its guarantees cover.
ECOSYSTEM
The work is checked by people we do not employ.
A protocol for regulated assets cannot be validated from inside the project that wrote it. Oraclizer builds alongside a zero-knowledge engineering company, an external proof-verification network, a policy leader co-authoring the standard, and a consensus research group whose interest is in finding where the model breaks.
Horizen Labs
A zero-knowledge engineering company and a co-author of ERC-8319, working with Oraclizer on the standard itself and on the proving and verification path the architecture rests on. The collaboration runs from the regulatory text down to the cryptography that has to carry it.
Visit Horizen Labs (opens in a new tab)zkVerify
Every synchronization cycle ends in a proof, and what it costs to verify those proofs decides whether continuous state synchronization is economically viable at all. zkVerify is where Oraclizer sends that verification: a network built to make proof checking cheap enough to do constantly, and independent enough that the check does not happen inside the system being checked.
Visit zkVerify (opens in a new tab)Blockchain Association
Dan Spuller, Executive Vice President of Industry Affairs at the Blockchain Association, co-authors ERC-8319 in an individual capacity. The Association represents the digital-asset industry before US regulators and lawmakers, and a standard that names regulatory actions reads differently when that vantage point is present from the drafting rather than consulted after it.
Visit Blockchain Association (opens in a new tab)Floating Pragma
A consensus research group Oraclizer takes part in. The current thread is a shared state-preservation benchmark connecting Oraclizer's Isabelle work with Bernhard Müller's Observer-Patch Holography program.
Visit Floating Pragma (opens in a new tab)FREQUENTLY ASKED
Straight answers.
01What is an oracle state machine?
It is an oracle architecture that treats a transition, its authority, its policy context, and its result as coordinated state, rather than as a value delivered to a contract.
Read the core concept (opens in a new tab)02How is S₃ different from ordinary oracle delivery?
At S₃, every bound domain must accept the transition together or return to the prior state together. Ordinary delivery can report a fact without enforcing that shared commit boundary.
Study state synchronization (opens in a new tab)03Does Oraclizer eliminate oracle extractable value?
For any action bound into a single all-or-nothing transition, yes, and by construction rather than by auction. Extraction needs a moment where the update is visible and its consequence is not yet committed, and atomic binding makes that moment unreachable. The atomicity is machine-checked. What this does not touch is what a participant already knows about the underlying fact before the transition begins. No update design closes that one, and we do not claim to.
Read the argument (opens in a new tab)04When is the Oraclizer testnet expected?
The current development target is Q1 2027. Public specifications, research preprints, formal models, and standards work are available now. The testnet target remains subject to completion of the required verification and integration gates.
05Who determines whether an external fact or regulatory action is valid?
The institutions, authorized sources, identity systems, and governing policies connected to an asset define authority and external truth. Oraclizer is designed to verify the declared evidence and policy path, coordinate the accepted transition, and expose its outcome. It does not replace legal judgment or make an external fact true by itself.
06Does Oraclizer replace existing tokens or institutional ledgers?
No. Oraclizer is designed as synchronization and assurance infrastructure around existing token standards, custody systems, institutional ledgers, and connected environments such as Canton. Each system retains its own authority while Oraclizer coordinates the accepted transition across their declared boundaries.
Review the architecture (opens in a new tab)ORACLIZER LABS
One asset should never become two.
Oraclizer Labs is a research and protocol organization building the oracle state machine, so that a regulated asset stays one asset across every system that holds it. The work started in regulation rather than in code. Two years of research across fifteen financial regulators produced the Regulatory Compliance Protocol, and the protocol design followed from what that research found. The team has been designing institutional digital-asset platforms on DAML and Canton since 2019.