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 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.
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.