State Synchronization
State synchronization is the mechanism by which Oraclizer keeps the state of a tokenized asset consistent across every domain that holds a representation of it. The previous page introduced this idea at a categorical level. This page describes how synchronization works in practice: the degree of synchronization an asset requires, the three types of synchronization Oraclizer supports, the lifecycle of an Oracle Session, and a worked example that follows a single state change from off-chain origin to cross-chain finality.
What gets synchronized
The unit of synchronization is the asset’s state, not a single value. For a tokenized real-world asset, the state typically includes ownership, regulatory status, contract terms, lifecycle position (active, matured, redeemed), and event history (coupon payments, dividend distributions, regulatory actions taken).
Each of these is a structured piece of information with constraints. Ownership transitions follow legal transfer rules. Regulatory status follows an escalation chain (an asset can move from FREEZE to SEIZE to CONFISCATE, but not arbitrarily back). Contract terms are immutable after issuance. The protocol enforces these constraints during synchronization, rejecting transitions that would violate them.
This is what distinguishes state synchronization from data delivery. A data feed transmits a value and trusts the consumer to interpret it. State synchronization transmits a verified transition with its full context, and the protocol guarantees that every domain applies the same transition under the same rules.
Synchronization degrees
Not every asset needs its state held together with the same strength. A bond that pays a coupon twice a year and a security whose regulatory status can change during the trading day impose different requirements, and applying the strongest guarantee everywhere would make continuous synchronization uneconomical for the assets that do not need it. Oraclizer classifies that requirement as a sync degree, from S0 to S3.
| Degree | Name | What the protocol enforces | Typical requirement |
|---|---|---|---|
S0 | Static | No continuing synchronization after issuance. The asset’s relevant state can remain inside one domain. | An instrument with no post-issuance lifecycle to propagate |
S1 | Observation | One domain reports a fact to another. The receiver remains responsible for deciding and applying what follows. | Reference values published for consumers to act on |
S2 | Causal coupling | On-chain and off-chain transitions become one causal process, though recovery from a partial result may still be eventual. | Scheduled servicing events where eventual repair is acceptable |
S3 | Atomic binding | Every bound domain commits together or rolls back together. A partially applied result is outside the permitted state space. | Regulatory actions, liquidation, and cross-ledger settlement |
The required degree is a property of the asset, not of the request that happens to arrive. It is recorded in the RWA Registry when the asset is registered, and it determines both how a synchronization is routed and how the cycle is metered. A caller cannot obtain a weaker guarantee by sending a cheaper message, and cannot claim a stronger one by asking for it.
The ordering between degrees is proved in both directions in Oraclizer’s machine-checked formal model: a higher degree safely carries an asset that requires a lower one, and a lower degree provably cannot carry an asset that requires a higher one. This is what makes degree-based routing safe to automate. A cycle may be promoted to a stronger degree when other assets in the same session require it, and it can never be silently demoted.
Degree and type are independent axes. The degree says how tightly the participating domains must be held together; the type below says which domains participate. An S3 binding can run on-chain to off-chain, on-chain to on-chain, or across both in the same cycle.
Three types of state synchronization
Oraclizer recognizes three categories of synchronization, distinguished by which domains are involved. Each category uses the same Bind-Verify-Commit semantics, but the participating systems and their interfaces differ.
On-chain to off-chain. The asset has both an on-chain token representation and an off-chain ledger record (typically in a Canton or DAML-based system). State changes originating in either domain must propagate to the other atomically. A coupon payment recorded in the off-chain ledger must update the on-chain token’s accumulated coupon state in the same atomic cycle. A regulatory freeze applied on-chain must reach the off-chain custodian as part of the same commit.
On-chain to on-chain (cross-chain). The asset is represented on multiple EVM-compatible chains. State changes on one chain must propagate to all other chains where the asset exists. Cross-chain synchronization is the most common case for assets that are bridged or held in protocols across multiple ecosystems. Conventional cross-chain bridges transfer tokens between chains as discrete events; Oraclizer instead synchronizes asset state continuously, with the same atomicity guarantee that applies to on-chain to off-chain transitions.
Off-chain to off-chain. The asset is represented across multiple off-chain systems (for example, the issuer’s ledger and the custodian’s ledger). Synchronization between these systems through the same protocol provides a uniform consistency model regardless of whether the change ever touches a chain. This category is on the roadmap and not part of the initial protocol scope.
Oracle Sessions
State synchronization is organized around Oracle Sessions. An Oracle Session is the synchronization contract between a single asset and a single owner over a continuous period of time. It is identified by the triple (Asset ID, Owner Address, Session Start Timestamp).
A session is the unit at which Oraclizer charges, the unit at which state continuity is guaranteed, and the unit through which subsequent synchronizations are amortized. Understanding sessions is the key to understanding how Oraclizer makes continuous synchronization economically and operationally viable.
When a session begins
A session opens in any of the following situations:
A new asset is tokenized and registered with Oraclizer for the first time. The initial owner’s session begins with the issuance event. An existing asset’s ownership transfers on-chain to a new holder. The previous owner’s session closes and a new session opens for the new owner in the same atomic transition. An asset that has existed only off-chain registers its state on-chain for the first time, with the off-chain holder of record as the session owner.
The first synchronization of any session carries higher cost than subsequent ones. Identity verification, regulatory eligibility checks, and the registration of asset-to-owner mappings all happen during the opening Bind-Verify-Commit cycle. Once these are established, the session’s mappings are reused for every later synchronization within the same session.
During a session
Within an open session, state changes are tracked continuously. Each change goes through a Bind-Verify-Commit cycle, but reuses the session’s existing identity and asset bindings. The result is that subsequent synchronizations are materially faster and cheaper than the opening one.
The continuity of state within a session is what enables Oraclizer to track lifecycle events (periodic coupon payments on a bond, recurring dividend distributions on a tokenized fund share, repeated regulatory checks on an asset under restriction) without re-establishing the synchronization contract on each event. The session is the contract; the events are entries within it.
When a session ends
A session closes under any of the following conditions: the asset’s ownership transfers on-chain (the closing of the previous session and the opening of the new owner’s session occur in a single atomic transition), the asset reaches its lifecycle end (maturity, redemption, burn), one of the contract parties explicitly terminates the session, or a regulatory action with terminal effect (CONFISCATE, SEIZE with disposition) is applied.
On closure, the session’s final state is committed to the RWA Registry as the authoritative record of the asset’s state at session end. If a new session follows (in the case of an ownership transfer), the closing record becomes the opening state of the new session.
A worked example
Consider a tokenized corporate bond. The bond exists in three places: an off-chain issuer ledger built on Canton (the system of record for the legal instrument), an on-chain ERC-20 representation on Base (used by DeFi protocols for collateral and trading), and a bridged representation on Arbitrum (used in a yield strategy on a cross-chain protocol). The current owner holds the bond through an open Oracle Session that connects all three representations.
A scheduled coupon payment is processed on the off-chain ledger. The issuer credits the holder’s account with the coupon amount. This creates a state change in the off-chain domain: the bond’s accumulated coupon state has incremented, and the holder’s claim has increased correspondingly.
The Oracle State Synchronizer (OSS) detects the off-chain event and initiates a Bind-Verify-Commit cycle for this transition. Bind: preemptive locks are acquired on the bond across all three domains. Any pending transactions on the bond elsewhere are queued behind these locks. Verify: the protocol checks that the proposed state change is valid given the bond’s contract terms (the coupon amount matches the schedule, the payment date is correct, no regulatory action blocks it). A GKR-based proof of the transition is generated. Commit: the verified transition is propagated atomically to all three domains. The off-chain ledger’s state, the Base ERC-20 token’s state, and the Arbitrum representation’s state all update together. The locks are released.
From the holder’s perspective, the coupon payment appears in every domain in the same atomic step. From a DeFi protocol’s perspective, the bond’s collateral value reflects the new accumulated coupon as soon as the protocol’s chain is updated. From a regulator’s perspective, the audit trail of the payment is consistent across every domain queried.
If any step had failed (a domain unreachable, a verification check rejected, a lock unobtainable), the entire cycle would have rolled back. The off-chain payment would still be recorded in the issuer’s ledger, but the synchronization would be retried until it could complete atomically. No domain is ever left with a partial reflection of the change.
Figure 1: State synchronization flow for a coupon payment event
Why this matters
The example above is concrete, but the underlying property is general. Any state change to a tokenized real-world asset (a coupon payment, a regulatory action, an ownership transfer, a maturity event, a contract amendment) is processed by the same synchronization model: detected in its origin domain, verified against the asset’s contract terms and regulatory state, and committed atomically to every domain where the asset exists.
This is what allows tokenized assets in Oraclizer to behave as single instruments with multiple representations, rather than as separate copies that drift apart over time. The token on Base, the bridged version on Arbitrum, and the off-chain ledger record are not three things being kept loosely in sync. They are three views of the same state, and the protocol guarantees that every view reflects the same transitions.
The mechanisms that make this guarantee operational (the regulatory protocol that defines what a valid transition is, the architecture that implements the synchronization layer, the cryptographic primitives that prove transitions correct) are the subject of the remaining pages. Regulatory Compliance describes the rules that constrain valid transitions. System Architecture describes the components that perform synchronization end to end.