TL;DR
Existing oracles’ “bidirectional” data delivery operates through two independent unidirectional channels (two-unidirectional channels), where each direction is processed as an independent event, making half-execution structurally possible. Atomic State Binding is the property guaranteeing that on-chain and off-chain state changes either succeed together or fail together as a causally coupled transition.
This property is formally defined by extending Lamport’s happened-before relation to the state synchronization context. In the independent channel model, a state change in one domain carries no causal guarantee of affecting the other domain. Under atomic binding, state transitions across both domains are bound as a single causal unit.
For financial RWA, this property is not optional; it is an existential condition. Bond interest payments, derivative exercises, and regulatory asset freezes destroy legal and economic integrity if not simultaneously reflected on-chain and off-chain.
Oraclizer’s OSS realizes this property through the combination of preemptive locking, a three-stage pipeline, and zk proof verification, with FV Property 1 (cross-domain state preservation homomorphism) providing the formal basis for its correctness.
1. The Question That Must Precede Security Analysis
In our previous research, we indicated that security analysis of the state synchronization system would follow [5]. However, while preparing that analysis, we encountered a more fundamental question: “What exactly are we protecting?”
Security is the defense of a system’s correctness against threats. But enumerating attack vectors without a formal definition of what “correctness” means for state synchronization is like debating wall heights without knowing what lies inside the castle.
What does it mean for bidirectional state synchronization to “work correctly”? Does it mean that when on-chain state changes, off-chain follows, and vice versa? Then what does “simultaneously” mean precisely? Is it acceptable for one side to change first and the other to follow? What if someone exploits that temporal gap?
These questions converge on a single requirement: we must formally define the atomicity of state synchronization. Only then can we systematically analyze scenarios where this property breaks.
This research formally defines the concept of Atomic State Binding. It is the core property that Oraclizer aims to guarantee, and it serves as the starting point for subsequent security analysis, lock mechanism design, and consistency model selection.
2. Why Bidirectional Delivery Is Not Bidirectional Synchronization
2.1 The Structural Limitation of Independent Unidirectional Channels
Existing oracle systems can deliver data bidirectionally. Chainlink’s Functions allows smart contracts to call external APIs and receive results. Conversely, Automation executes on-chain functions when off-chain conditions are met. On the surface, this is bidirectional.
The problem is that these two directions are independent events. The on-chain-to-off-chain call (request) and the off-chain-to-on-chain response (callback) are separate transactions. A state where the first transaction succeeds and the second fails, i.e. half-execution, is structurally possible.
In the language of distributed systems theory, the two channels are causally decoupled. Between event a in Channel A and event b in Channel B, Lamport’s happened-before relation (→) may not hold. The occurrence of a does not guarantee the occurrence of b.
$$a \in \text{Channel}_A, \quad b \in \text{Channel}_B \quad \Rightarrow \quad a \not\to b \;\; \text{and} \;\; b \not\to a$$Since the two events are not causally connected, they are concurrent from a distributed systems perspective. Concurrent here does not mean temporally simultaneous; it means there is no causal path through which one can influence the other [1].
Figure 1: Independent Channels vs Atomic State Binding
2.2 Concrete Consequences of Half-Execution
This is not an abstract problem. Consider what happens in financial scenarios.
Scenario: Bond Interest Payment
1. Interest payment is confirmed off-chain (CANTON). 2. Channel A: the “interest confirmed” event is delivered on-chain. 3. Interest tokens must be distributed to on-chain token holders. 4. Channel B: the distribution transaction executes.
If step 2 succeeds but step 4 fails (gas shortage, network congestion, contract error), the off-chain ledger records interest as paid while on-chain tokens remain undistributed. The two worlds are desynchronized.
A more dangerous scenario: a regulator orders an asset freeze (FREEZE), and it is applied off-chain but not yet reflected on-chain. During that temporal gap, the asset trades freely through the unfrozen on-chain channel. This is not a technical bug; it is a structural flaw.
2.3 Existing Approaches and Their Limitations
Retry patterns repeatedly attempt failed transactions. But desynchronization exists during the interval between retries, and retries themselves can fail. The result is “succeeds with sufficiently high probability,” not guaranteed atomicity.
Compensating transaction patterns (the Saga pattern) execute compensating transactions to undo previous steps on failure. This provides eventual consistency, but the system remains temporarily desynchronized until compensation executes. In financial regulation, this temporary desynchronization may be unacceptable. A regulatory freeze order that is “pending application” is not legally a frozen state [2].
Two-Phase Commit (2PC) is the classical atomic commit protocol for distributed systems. All participants confirm readiness (prepare) before committing. It theoretically guarantees atomicity, but suffers from coordinator failure causing indefinite participant blocking, and is difficult to apply directly across heterogeneous systems such as blockchains and traditional financial infrastructure [3].
The common reason these approaches fall short is that they all attempt to retroactively coordinate two independent systems. Atomicity is not inherent in the architecture; it is a bolt-on mechanism layered on top.
3. Formal Definition of Atomic State Binding
3.1 State Domains and State Transitions
We establish the basic elements needed for the definition.
A State Domain \(D\) is an independent state space. For example, \(D_{on}\) is the on-chain state of an EVM chain, and \(D_{off}\) is the off-chain state of CANTON. In cross-chain environments, \(D_1, D_2, \ldots, D_n\) represent different chains.
Each domain has a state set \(S_D\), and a state transition function \(\delta_D : S_D \times A_D \rightarrow S_D\) changes state via action \(a \in A_D\).
3.2 Independent Channel Model
In the independent channel model, “bidirectional delivery” between domains \(D_1\) and \(D_2\) is modeled as:
$$\text{Channel}_{1 \to 2} : S_{D_1} \overset{\text{observe}}{\longrightarrow} M \overset{\text{deliver}}{\longrightarrow} S_{D_2}$$ $$\text{Channel}_{2 \to 1} : S_{D_2} \overset{\text{observe}}{\longrightarrow} M’ \overset{\text{deliver}}{\longrightarrow} S_{D_1}$$Where \(M, M’\) are messages. The critical point is that the two channels can fail independently:
$$P(\text{Channel}_{1 \to 2} \text{ succeeds} \mid \text{Channel}_{2 \to 1} \text{ fails}) > 0$$
In this model, state consistency is probabilistic. The probability of both channels succeeding is the product of each channel’s success probability, meaning overall system consistency is always lower than individual channel reliability.
A pen rests beside two circles joined by an equals sign, the first sketch before the formal definition takes shape.
3.3 Atomic State Binding
Atomic State Binding is a synchronization mechanism satisfying the following property.
Definition. An atomic state binding between domains \(D_1\) and \(D_2\) is a function \(\text{sync}\) satisfying:
$$\text{sync} : (S_{D_1} \times S_{D_2}) \times E \rightarrow (S_{D_1}’ \times S_{D_2}’) \cup \{(S_{D_1} \times S_{D_2})\}$$
Where \(E\) is the set of events triggering synchronization. This function permits only two outcomes:
Success: Both domains transition to new states \((S_{D_1}’, S_{D_2}’)\)
Failure: Both domains retain their original states \((S_{D_1}, S_{D_2})\)
Intermediate states where only one domain changes, \((S_{D_1}’, S_{D_2})\) or \((S_{D_1}, S_{D_2}’)\), are unreachable.
3.4 Causal Coupling
We connect this definition to Lamport’s causality framework.
In the independent channel model, state change \(e_1\) in \(D_1\) and state change \(e_2\) in \(D_2\) can be causally decoupled:
$$e_1 \| e_2 \quad \text{(concurrent, no causal link)}$$
Under atomic state binding, \(e_1\) and \(e_2\) are bound as a single causal unit. We denote this \(e_1 \bowtie e_2\) [1]:
$$e_1 \bowtie e_2 \iff \text{sync}(e_1, e_2) \text{ is atomic}$$
This is a stronger condition than \(e_1 \rightarrow e_2\) (happened-before). Happened-before represents unidirectional causation where one event precedes another, whereas \(\bowtie\) represents mutual causal dependency. If one does not occur, neither does the other.
3.5 Extension to N Domains
In cross-chain environments, synchronization can involve more than two domains. Extending to N domains:
$$\text{sync}_N : \prod_{i=1}^{N} S_{D_i} \times E \rightarrow \prod_{i=1}^{N} S_{D_i}’ \cup \left\{\prod_{i=1}^{N} S_{D_i}\right\}$$
Similarly, all domains either transition to new states or all retain original states. Partial transitions are not permitted.
The complexity of this extension grows with domain count. Two domains have 4 possible state combinations (full success, full failure, two partial failures), but N domains have \(2^N\) combinations of which exactly 2 must be permitted. This is the fundamental reason cross-chain atomicity is difficult.
4. Necessity in Financial Scenarios
4.1 Where Atomicity Is Not Optional
Not all state synchronization requires atomic binding. Informational data such as weather or sports results tolerates temporary inconsistency. The difference between a five-minute-old price and the current price is inconvenient but does not destroy the system.
Financial RWA is different. In the following three scenarios, absent atomic binding, legal and economic integrity collapses.
Scenario 1: Derivative Exercise. When an option holder exercises their right, the underlying asset delivery obligation is confirmed off-chain and token exchange must execute on-chain. If obligation is confirmed off-chain but tokens are not exchanged on-chain, a legal dispute arises between counterparties. Conversely, if tokens are exchanged on-chain without the off-chain obligation being confirmed, economic loss occurs.
Scenario 2: Regulatory Asset Freeze. When a regulator orders FREEZE on a suspicious AML transaction, the order must take effect on both on-chain and off-chain simultaneously. If only one side is frozen while the other remains active, assets can move through the unfrozen channel. This constitutes regulatory arbitrage, violating FATF Travel Rule and national AML regulations.
Scenario 3: Bond Maturity Redemption. At maturity, principal redemption is confirmed off-chain, bond tokens are burned on-chain, and redemption tokens are issued. If redemption completes off-chain but tokens are not burned on-chain, already-redeemed bonds continue trading, creating a double-claim problem.
Figure 2: Why Financial RWA Cannot Tolerate Temporal Gaps
4.2 The Cost of Temporal Gaps
What these scenarios share is that the cost of temporal gaps grows non-linearly.
For informational data, a five-minute gap costs proportionally to five minutes. But for a regulatory freeze, a five-minute gap incurs the cost of invalidating every transaction executed during those five minutes. For derivative exercises, the gap produces losses proportional to underlying asset price movement.
This is why eventual consistency suffices for data oracles while atomic consistency is required for state oracles. The cost structure of temporal gaps is fundamentally different.
5. Realizing Atomic Binding in OSS
5.1 Why Standard 2PC Falls Short
Given the definition of atomic binding, 2PC (Two-Phase Commit) appears to be a natural solution. Indeed, 2PC is the standard protocol guaranteeing atomic commits in distributed databases.
However, three factors make direct application of 2PC to oracle state synchronization impractical.
Heterogeneous systems. 2PC assumes all participants implement the same protocol. But EVM chains, CANTON, and external APIs each use different transaction models. EVM guarantees transaction atomicity at the block level but does not natively support cross-block prepare/commit protocols.
Finality heterogeneity. In 2PC’s prepare phase, each participant promises it “can commit.” But on blockchains, this promise depends on finality. When Ethereum’s finality (approximately 12 minutes) and Base’s finality (approximately 2 seconds) differ, one chain’s prepare can expire before another chain reaches finality.
Severity of blocking. In 2PC, coordinator failure causes participants to wait indefinitely [3]. Depending on a single coordinator in a decentralized system introduces a single point of failure (SPOF), contradicting D-quencer’s design philosophy.
5.2 The OSS Approach: Bind-Verify-Commit
OSS borrows the principles of 2PC while accommodating the heterogeneity of blockchain and off-chain systems through a modified protocol we call Bind-Verify-Commit (BVC).
Phase 1: Bind (Preemptive Locking). When a synchronization event occurs, OSS acquires a preemptive lock on the relevant asset across all involved domains. The lock prevents other synchronization requests from modifying the same asset.
Lock duration is the maximum finality time across all involved domains plus a safety margin:
$$T_{lock} = \max(T_{finality}^{D_1}, T_{finality}^{D_2}, \ldots, T_{finality}^{D_n}) + T_{margin}$$
Unlike 2PC’s prepare phase where each domain promises it “can commit,” OSS eliminates the possibility of concurrent modification at the source.
Phase 2: Verify (State Transition Validation). After acquiring locks, OSS validates the state transition. GKR-based proofs are generated at this stage: confirming each domain’s current state matches expectations, verifying the proposed transition complies with OIP rules, and cryptographically guaranteeing transition correctness through zk proofs.
Phase 3: Commit (Atomic Propagation). Upon successful verification, OSS propagates state changes to all domains simultaneously. “Simultaneously” here means logical atomicity, not physical simultaneity. Regardless of which domain updates first, the lock is maintained until all domains confirm their updates, so external observers see all domains as having changed at once.
If any domain’s commit fails, OSS rolls back changes across all domains and releases locks. This is all-or-nothing semantics.
Figure 3: Bind-Verify-Commit (BVC) Protocol
5.3 Comparison with 2PC
The core difference lies in failure modes. In 2PC, coordinator failure places the system in an in-doubt state. In BVC, locks have expiration times, so regardless of what failure occurs, the system reverts to its original state within at most \(T_{lock}\) time.
Other distinctions: 2PC relies on a single coordinator (SPOF) while BVC uses D-quencer consensus-elected nodes. 2PC depends on participant prepare promises while BVC preemptively blocks concurrent access. 2PC assumes homogeneous finality while BVC independently tracks heterogeneous finality across chains. 2PC blocks on coordinator failure while BVC auto-rolls back on lock expiry.
6. Connection to Formal Verification
6.1 FV Property 1: Cross-Domain State Preservation Homomorphism
Formal grounds for the correctness of atomic state binding already exist. FV Property 1 (cross-domain state preservation homomorphism), proven in Isabelle/HOL, provides this foundation.
The key theorems this proof confirms [4]:
regulatory_homomorphism: after sync, all connected domains hold identical regulatory states.
valid_state_preservation: sync preserves the global valid state invariant (inductive invariant).
Translated into the language of atomic state binding: when the \(\text{sync}\) function completes successfully, the resulting state \((S_{D_1}’, S_{D_2}’)\) is necessarily regulatorily consistent. If one domain is FROZEN, the other is FROZEN as well.
6.2 What Formal Verification Does and Does Not Guarantee
It must be understood precisely that FV Property 1 is a model-level proof. It is a conditional guarantee: “if the sync function is correctly implemented, state preservation is guaranteed.”
What FV Property 1 guarantees: 5 regulatory states (ACTIVE, FROZEN, SEIZED, CONFISCATED, RESTRICTED) and 7 actions forming 35 transition rules are deterministic and consistent; state preservation homomorphism is maintained when these rules extend cross-domain; terminal state absorption (CONFISCATED), universal confiscatability, and absence of self-loops.
What FV Property 1 does not guarantee: that OSS’s actual code precisely implements this model (code-level refinement is a future task); full safety against network failures, malicious nodes, or lock contention in real operating environments.
Therefore, the design correctness of atomic state binding is formally verified, but implementation correctness and operational safety require separate verification. This is why subsequent research addresses security analysis and fault recovery.
7. Open Questions and Future Research
This research presented the formal definition of atomic state binding and the direction for its realization in OSS. Several questions remain open.
Lock time optimization. In \(T_{lock} = \max(T_{finality}^{D_i}) + T_{margin}\), what should the safety margin \(T_{margin}\) be? Too long reduces system throughput; too short risks lock expiration before finality. This is addressed in the next research alongside the finality mismatch problem.
Economic cost of lock contention. When multiple synchronization requests compete for locks on the same asset, wait times increase. This waiting cost must be reflected in the Oracle Session economic model, and is addressed in detailed preemptive lock mechanism design.
Hierarchical relaxation of atomicity. Not all state changes may require the same level of atomicity. Regulatory actions (FREEZE, SEIZE, etc.) demand strict atomicity, but routine state updates (e.g., metadata changes) may suit weaker consistency models. This hierarchical relaxation is explored in consistency model research.
Scalability across N domains. Permitting only 2 of \(2^N\) possible state combinations becomes harder as domain count increases. What is the realistic upper bound on the number of domains Oraclizer simultaneously involves? This is concretized in cross-chain bridge design.
Conclusion
Distributed systems theory demonstrates that event ordering can be defined based on causality rather than physical time [1]. Atomic state binding applies this insight to state synchronization. It binds state transitions across two domains into a single causal unit: if one side changes, the other must change; if one side fails, the other must revert.
This definition matters because it clarifies “what we must protect.” The correctness of state synchronization is the preservation of atomic binding. Every scenario that breaks this property is an attack; every mechanism that maintains it is a defense.
For financial RWA, this property is an existential condition, not an optimization target. Derivative exercises, regulatory asset freezes, and bond maturity redemptions all require on-chain and off-chain state to be causally coupled to carry meaning. Independent unidirectional channels, however composed, cannot structurally guarantee this property.
OSS’s Bind-Verify-Commit pattern realizes this property through the combination of preemptive locking, zk proof verification, and atomic propagation. It borrows the principles of 2PC while accommodating the constraints of heterogeneous systems and decentralized environments. FV Property 1 guarantees the state preservation correctness of this design at the model level.
The next research addresses cross-chain finality mismatch, the practical obstacle to realizing atomic binding. How to set \(T_{lock}\) and manage the risks of partially confirmed states in environments where chains have different confirmation times is the bridge connecting atomic binding theory to actual implementation.
References
[1] Lamport, L. (1978). Time, Clocks, and the Ordering of Events in a Distributed System. Communications of the ACM, 21(7), 558-565. https://amturing.acm.org/p558-lamport.pdf
[2] Financial Action Task Force (FATF). (2021). Updated Guidance for a Risk-Based Approach for Virtual Assets and Virtual Asset Service Providers. https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-rba-virtual-assets-2021.html
[3] Fowler, M. (2023). Two-Phase Commit. Patterns of Distributed Systems. https://martinfowler.com/articles/patterns-of-distributed-systems/two-phase-commit.html
[4] Oraclizer Research. (2026). Proving Cross-Domain State Preservation: The Journey. https://research.oraclizer.io/proving-cross-domain-state-preservation/
[5] Oraclizer Research. (2026). The Privacy Paradox of Bidirectional State Synchronization. https://research.oraclizer.io/the-privacy-paradox-of-bidirectional-state-synchronization/
[6] Oraclizer Research. (2025). The End of OEV: Oracle State Synchronization as the Ultimate Solution. https://research.oraclizer.io/the-end-of-oev-oracle-state-synchronization-as-the-ultimate-solution/
