What is Oraclizer
Oraclizer is an oracle state machine: a specialized state machine that performs bidirectional state synchronization across on-chain, off-chain, and cross-chain environments. This page introduces what an oracle state machine is, why it differs categorically from conventional data oracles, and how this difference reframes the classical oracle problem when the system has to carry tokenized real-world assets.
Data oracles and their limits
A data oracle is a system that delivers external data to a blockchain. Price feeds, weather data, sports scores, and verifiable randomness all fit this pattern. The oracle observes an event in an external source, attests to its value, and writes that value to a smart contract. The blockchain then reads it.
This pattern is fundamentally unidirectional. Data flows from the external world to the chain. Some oracle systems also support a return path, writing on-chain events back to off-chain consumers, but this amounts to two independent unidirectional channels operating in parallel. There is no causal binding between the two directions. If the on-chain side updates and the off-chain side fails, or vice versa, both sides simply continue with divergent views of reality.
For applications that consume external data as a reference (a DeFi protocol reading the price of ETH, for example), this design is sufficient. The protocol uses the latest price and proceeds. Stale or missing data degrades quality but rarely breaks correctness in a structural sense.
For applications that represent real-world assets, this design breaks down. A tokenized bond is not a price reference. It is a contractual instrument whose state (ownership, regulatory status, coupon schedule, maturity, collateral terms) must remain consistent across the on-chain token, the off-chain ledger, and any chain the asset has been bridged to. When a coupon is paid off-chain, the on-chain token must reflect it. When a regulator freezes the asset on-chain, the off-chain custodian must enforce it. Half-success is not acceptable.
From data oracle to oracle state machine
An oracle state machine is a different category of system. Rather than delivering values, it synchronizes state. A state synchronization is not a one-shot data delivery. It is a transition that must succeed atomically across every domain where the asset exists, or fail across every domain together.
This shift changes three things at once.
State, not data. The unit of synchronization is the asset’s complete state, not a single value. Ownership, regulatory flags, contract terms, and lifecycle events are all part of what gets synchronized. The state has structure, and that structure is preserved across domains by the protocol.
Atomicity, not best-effort. A state transition either commits on every relevant domain or rolls back everywhere. There is no intermediate state in which on-chain reflects the change but off-chain does not. Oraclizer realizes this through the Bind-Verify-Commit pattern: preemptive locks are acquired on every relevant domain, the state transition is verified with a GKR-based proof, and the result is propagated to all domains as a single atomic commit. Failure at any step releases all locks and rolls back the cycle in full.
Continuous synchronization, not periodic polling. Once a synchronization contract (an Oracle Session) is established between an asset and its owner, state changes are tracked continuously. There is no per-event oracle request or per-update settlement gap. The session is the unit of synchronization, not the individual update.
Together, these properties define what it means for Oraclizer to be a state machine rather than a data feed. The state of every asset under management evolves through well-defined transitions, each of which is verified, sequenced, and committed under the same rules across every domain it touches.
Figure 1: Data oracle versus oracle state machine
The oracle problem, redefined
The classical formulation of the oracle problem asks how a blockchain can rely on data it cannot natively verify. The proposed answers, decentralized oracle networks, multi-signature attestations, cryptoeconomic incentives, focus on making the delivered value trustworthy. The implicit assumption is that delivery itself is the hard part; what comes after is the application’s concern.
For real-world assets, the question is different. The hard part is not whether the value is trustworthy at the moment of delivery, but whether the resulting state remains consistent across every domain that holds a representation of the asset. A correctly delivered value that updates only one domain leaves the system in an inconsistent state, and an inconsistent state in financial infrastructure is not a degraded outcome but a structural failure.
Oraclizer reframes the oracle problem as a state synchronization problem. The question becomes: how can the state of an asset evolve through transitions that are atomically reflected across every domain in which the asset exists, while preserving regulatory and contractual constraints throughout? Trust in delivered values is a subproblem of this larger question, addressed inside the synchronization protocol rather than left to applications.
This reframing is what makes an oracle state machine necessary. State synchronization with atomic guarantees cannot be retrofitted onto a unidirectional data feed. It requires a different category of system, one whose primitives are state transitions, locks, and atomic commits rather than data updates.
One consequence of this reframing reaches a problem that is otherwise difficult to address. Oracle Extractable Value (OEV) is the value extractable by acting on knowledge of an oracle update before dependent contracts react. In conventional data oracle architectures, OEV arises from two structural properties of the update model: discrete updates create timing gaps between publication and reaction, and update races create competition for ordering when multiple transactions depend on the same value. Both properties are intrinsic to discrete, per-call data delivery rather than to any particular oracle implementation.
An oracle state machine does not address these conditions through mitigation. Continuous synchronization within an Oracle Session leaves no window between a published update and dependent reaction, and preemptive locks serialize concurrent transactions targeting the same asset rather than letting them compete through fee ordering. The structural conditions for OEV do not arise in the first place. This is a consequence of how state synchronization works, not a goal of the design, but it explains why approaches that treat OEV as inevitable (auction-based redistribution, post-hoc compensation) and approaches that change the underlying update model differ categorically rather than quantitatively.
A single architecture for ten interlocking problems
Reframing the oracle problem as state synchronization, and the change in OEV conditions that follows from it, are two effects of a single architectural choice. Building an oracle state machine that can carry tokenized real-world assets exposes a broader set of long-standing problems in the field, problems that have typically been studied and addressed in isolation. The table below lists ten such problems alongside the parts of the Oraclizer design that take each one as a constraint to satisfy.
Two cautions are in order. First, the entries below do not claim that each problem is fully solved by the corresponding mechanism; some are addressed directly, others are mitigated, and others follow as consequences of design decisions made for different reasons. Second, the value of the table lies less in any single row than in the requirement that all ten be considered together: in the RWA context, leaving one of them unresolved tends to undermine the others.
Several of the entries reference Oraclizer’s formal verification program in Isabelle/HOL. Where a property has been proven, the table notes this; where the work is ongoing, the entry describes the property as design intent that the formal verification work is responsible for establishing. This is the same convention used elsewhere in the documentation: proven properties are described as such, and unproven properties are not.
Figure 2: Ten long-standing problems and how the Oraclizer design addresses each one
The reason these problems are treated together is that several of them are coupled in the RWA context. Decentralization without a way to prioritize regulatory actions cannot serve regulated assets, because a freeze order has to take precedence over ordinary transactions and an unstructured sequencer cannot guarantee this. Privacy without traceability cannot satisfy regulators, because asset state must be auditable to authorized parties under defined conditions. Continuous synchronization without an economic model that fits its cost structure does not run in production, because per-call pricing makes the model itself a liability. Several entries in the table are easier to satisfy because the others are also being satisfied; few of them are independent.
Two of the entries above carry implications that extend beyond the row in which they appear. The regulatory framework underlying the architecture 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 specification. This work cannot be retrofitted later; it shapes which interfaces exist, which states are reachable, and which actions a sequencer must prioritize. The other implication is the regulatory built-in approach that Oraclizer inherits from DAML and extends to the on-chain world. DAML embeds compliance into its language and ledger model rather than relying on application-layer guards. Oraclizer was designed under the same principle, which is what allows the off-chain DAML world and the on-chain world to be connected through a shared regulatory model rather than reconciled through application-layer translation.
What an oracle state machine is for
The capabilities described above are not abstract design choices. They exist because tokenized real-world assets require them. A bond token whose coupon payments are not atomically reflected on-chain and off-chain is not a usable financial instrument. A regulated asset whose freeze order can take hold on one chain but not another cannot be issued under existing financial regulation.
Oraclizer’s design is shaped by this requirement set. The bidirectional state synchronization, the atomic commit semantics, the preemptive lock protocol, the protocol-native regulatory actions, and the formally verified cross-domain state preservation all serve the same goal: making it possible for assets that exist in regulated, off-chain financial systems to also exist on-chain without losing the consistency and enforceability that those systems depend on.
The remaining pages in Core Concepts develop each of these properties in more depth. State Synchronization describes the bidirectional synchronization model and Oracle Sessions. Regulatory Compliance introduces the Regulatory Compliance Protocol and the six regulatory actions defined at the protocol level. System Architecture connects these concepts to the three-layer architecture that implements them.