FAQ

Frequently asked questions about Oraclizer. Questions are grouped by user intent rather than documentation structure, so you can find what you need without knowing the site layout. For deeper coverage of any topic, follow the inline links to the related documentation pages.

Getting Started

How does Oraclizer differ from conventional data oracles?

Conventional data oracles deliver values one-directionally from off-chain sources to on-chain consumers. Oraclizer is an oracle state machine that performs bidirectional state synchronization across on-chain, off-chain, and cross-chain environments. The unit of synchronization is the asset’s full state (ownership, regulatory status, contract terms, lifecycle position), not a single value. See What is Oraclizer for the full distinction.

What development stage is Oraclizer at?

Oraclizer is in active development. The protocol specification (OIP) is in the design phase, with the first public version (v0.5) being prepared for release. Initial proof-of-concept components are under construction, with public testnet planned for a later phase. Documentation describing already-decided architecture and protocol concepts is published as decisions stabilize; sections marked as “under development” indicate components not yet implemented or specifications not yet finalized.

Which blockchains does Oraclizer support?

Oraclizer’s L3 settles on Base L2, which in turn settles on Ethereum L1. Cross-chain support targets EVM-compatible chains, with the protocol designed to extend to additional chains as integration drivers are built. Canton integration provides connectivity to enterprise off-chain ledgers used by financial institutions for regulated assets.

Who are Oraclizer’s key partners?

Oraclizer’s infrastructure leverages several external systems. Horizen Labs provides zkVerify for batch verification of zero-knowledge proofs. Polygon CDK is the L2/L3 framework Oraclizer’s L3 is built on. Canton is the enterprise blockchain network Oraclizer integrates with for off-chain financial ledgers. Identity infrastructure can leverage external solutions such as Privado.ID.

Is Oraclizer open-source?

Yes. Oraclizer follows a tiered open-source strategy:

Academic and formal verification artifacts: BSD-3-Clause (Archive of Formal Proofs compatible)
Core protocol implementations (OSS, OIP specification, CCMI contracts, D-quencer): Apache 2.0
StateSync-GKR proof stack: MIT/Apache 2.0 dual license
External integration layers (Canton Driver, L3 node, RWA Registry): MIT
Documentation: CC BY 4.0

The first publicly available repository is Oraclizer’s GitHub organization, which currently hosts the formal verification artifacts. Additional repositories will be published as their corresponding development phases begin.

Why is Oraclizer being built now?

Three conditions are converging at the same time:

Regulation is solidifying: global regulators are finalizing tokenized-asset frameworks, moving the conversation from “is this allowed” to “how is this enforced”.
Institutional infrastructure is ready: enterprise networks like Canton are now operating real volume from major financial institutions, not running pilots.
Zero-knowledge cost has dropped: zkVerify and the latest GKR-class proof systems make continuous high-frequency state synchronization economically feasible. Two to three years ago, the architecture Oraclizer requires was not affordable.

Without all three, an oracle state machine for regulated assets would be either premature or impractical. The convergence is what makes the project tractable now.

How It Works

What is the difference between state synchronization and a data feed?

A data feed delivers a single value (a price, a number, a boolean) from one source to one or more consumers. State synchronization keeps the full state of an asset consistent across every domain that holds a representation of it. The unit is the asset’s full state (ownership, regulatory status, contract terms, lifecycle position, event history), and the operation is bidirectional and atomic. A data feed cannot represent that an asset has been frozen by a regulator and must reflect that across three chains and an off-chain ledger simultaneously; state synchronization is built for exactly that.

What is bidirectional state synchronization?

State synchronization that flows in both directions between participating domains. A change originating off-chain (a coupon payment, a regulatory order, an ownership transfer recorded in a custodian’s ledger) propagates to on-chain representations, and a change originating on-chain (a transfer in a decentralized application, a smart contract action) propagates back to off-chain ledgers. This is the core capability that distinguishes an oracle state machine from a conventional one-directional oracle. See State Synchronization for the full mechanics.

What is an Oracle Session?

An Oracle Session is the synchronization contract between a single asset and a single owner over a continuous period of time, identified by the triple (Asset ID, Owner Address, Session Start Timestamp). A session opens on issuance, ownership transfer, or first registration, and closes on transfer, lifecycle end, explicit termination, or terminal regulatory action. The 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.

What is Atomic State Binding?

The property that a state transition either succeeds in every domain holding the asset or in none of them. Conventional cross-system data delivery often results in partial updates where one domain reflects a change before another, creating temporary inconsistency. Oraclizer’s protocol guarantees atomic state binding through the Bind-Verify-Commit cycle; no domain is ever left partially updated.

What is the Bind-Verify-Commit (BVC) cycle?

BVC is the three-phase cycle that OSS uses to perform every state synchronization:

Bind: Acquire preemptive locks on the asset across every participating domain.
Verify: Validate the proposed transition against protocol rules and generate a StateSync-GKR proof attesting to the transition’s correctness.
Commit: Propagate the verified transition atomically to all domains.

Failure at any phase rolls back the entire cycle. This is what gives Oraclizer atomic state binding: a transition that cannot be made consistent everywhere is not made anywhere.

What is the Three-Group DAG Pipeline?

The Three-Group DAG Pipeline is how OIP v0.5 organizes message validation, replacing the linear five-stage pipeline of earlier drafts. Validation is split into three groups with distinct cost profiles and failure semantics:

Group 1 (Pre-Lock Verification): cheap, read-only checks that fast-fail before any lock is acquired (header format, signature, replay defense, address resolution, authority verification, first-pass proof verification). Run with maximum parallelism.
Group 2 (State Modification): acquires preemptive locks and applies state transitions sequentially. Includes the Regulatory Compliance Stage, where a STATE_SYNC can be escalated to a REGULATORY_ACTION.
Group 3 (Cross-chain Effects): propagates the committed change to participating chains and verifies postconditions, with automatic rollback on violation.

The DAG structure exposes parallelism within each group and localizes failure semantics across groups. The throughput improvement is substantial, and every safety property the linear pipeline guaranteed is preserved.

What is the difference between PREPARE, COMMIT, and FINALIZE phases?

These are the three phases of the Three-Phase Broadcast pattern OIP uses to deliver state-changing messages across chains:

PREPARE: probes each target chain for applicability and reserves preemptive locks. Failures here are clean — no chain has changed state yet.
COMMIT: applies the actual state change on each target chain. Failures here may require rollback across chains that already committed.
FINALIZE: confirms the change and releases coordination locks. Failures here are conservative — state is already applied; only the confirmation label is missing.

The three-phase structure is what allows OIP to deliver an ALL_OR_NOTHING guarantee across heterogeneous chains. Note that the inner COMMIT round here is one phase inside the outer BVC.Commit envelope; the two share the word “commit” but operate at different layers of the protocol stack.

What is StateSync-GKR and why does it matter?

StateSync-GKR is Oraclizer’s synchronization proof generation stack, built on a modular zero-knowledge proof toolkit. It uses the GKR protocol to produce proofs of state transitions during the Verify phase of every BVC cycle, and wraps them in fflonk for compatibility with the broader verification path.

GKR is not an optimization on top of an otherwise viable design. It is a precondition for the design to exist. Conventional SNARKs carry intermediate-commitment overhead that makes continuous high-frequency state synchronization computationally impractical. GKR removes that overhead by avoiding intermediate commitments altogether, which is what allows Oraclizer to perform cryptographically verified synchronization at the cadence regulated assets require, with deterministic proof generation deadlines.

StateSync-GKR is built specifically for Oraclizer’s workload (sparse Merkle tree verification, deterministic deadlines, batching across many similar circuits). It is being developed as part of Oraclizer’s open-source strategy and will be released under MIT/Apache 2.0 dual license.

What is the difference between OIP and OSS?

OIP (Oracle Interoperability Protocol) is the specification: it defines what a state synchronization message looks like, which transitions are valid, how regulatory actions are encoded, how routing works. OSS (Oracle State Synchronizer) is Oraclizer’s reference implementation of OIP. The two are inseparable in practice (a specification without an implementation is inert, and an implementation without a specification cannot be verified for conformance), but they are distinct artifacts.

How does Oraclizer eliminate Oracle Extractable Value (OEV)?

OEV is value extractable by oracle operators or front-runners from the timing and content of oracle updates. In conventional data oracle architectures, OEV arises from two structural properties: discrete updates create timing gaps between publication and reaction, and update races create competition for ordering when multiple transactions depend on the same value. Oraclizer’s architecture removes both conditions:

Continuous bidirectional synchronization leaves no window between a published update and dependent reaction.
Preemptive locks serialize concurrent transactions on the same asset, so ordering is not decided by fee competition.
Cross-chain atomic updates remove the timing gaps that exist when state is updated on each chain independently.

The result is that the structural conditions that produce OEV are not present: OEV does not need to be auctioned, redistributed, or compensated, because it does not arise. This is a consequence of how state synchronization works rather than a goal of the design.

What is the difference between Validium and zk-Rollup mode?

Validium uses zero-knowledge proofs for execution but stores transaction data off-chain, reducing cost. zk-Rollup stores data on the L1, giving stronger data availability guarantees at higher cost. Oraclizer’s L3 operates in Validium mode by default, with Volition support that lets specific transactions or assets opt into zk-Rollup mode at the per-transaction or per-asset level when stronger guarantees are required.

How does Oraclizer protect privacy while maintaining regulatory traceability?

Privacy and traceability are usually framed as a tradeoff. Oraclizer treats them as four orthogonal concerns, each handled by a separate layer:

Identity (who): zk-basis ID verifies eligibility (residency, accreditation, sanctions clearance) without exposing personal data on-chain.
Contract (when): DAML‘s need-to-know permissioning ensures contract details are visible only to parties with a legitimate interest.
State (what): OSS’s selective synchronization keeps confidential data off public chains, with commitments stored in data availability layers under credential-based access.
Audit (under what conditions): OCID provides conditional identity linkage that authorized auditors and regulators can resolve, with the resolution itself recorded for traceability.

The result: a holder proves they are an accredited investor in the relevant jurisdiction without disclosing who they are, the contract terms remain confidential to non-parties, the asset state is selectively synchronized, and a court order can still resolve identity when the legal threshold is met. Privacy by default, traceability when authorized.

What is the difference between primary and secondary finality?

Oraclizer reaches finality in two steps. Primary finality is the point where the OSS State Root is fixed by GKR proof issuance. The OSS treats this as its source of truth and preserves it permanently, even across lock expiration and reconciliation. Secondary finality is the external settlement finality reached afterward through the fflonk → zkVerify → Base L2 path.

The split is not cosmetic. It lets the protocol commit to a state internally in time to support pre-trading decisions, while the external settlement layer continues its slower verification path independently. When the two paths disagree (rare, but possible during cross-chain propagation failures), the primary finality record is the authoritative reference for reconciliation.

Why does Oraclizer use Two-Tier Finality?

Regulated trading cannot wait. A bond that just changed hands on Canton needs to be tradable on the L3 immediately, not after the L2/L1 settlement path has run its full course. Two-Tier Finality is what lets Oraclizer reconcile this with the safety guarantees regulated assets require:

Primary finality is reached when GKR proof issuance fixes the OSS State Root. From this point, the OSS treats the state as its source of truth: trading authorization, regulatory queries, and downstream synchronizations all rely on it.
Secondary finality is the external settlement finality that observers outside the OSS see, reached through the fflonk → zkVerify → Base L2 path. It runs on its own slower clock without holding up the OSS.

If the two paths disagree (rare, but possible during cross-chain propagation failures), the primary finality record is the authoritative reference for reconciliation. The structure is what lets Oraclizer-tokenized assets behave like regulated financial instruments — fast on the trading layer, conservative on the settlement layer — without sacrificing either property.

Why does OIP define both SINGLE and THRESHOLD signatures?

The two SignatureType variants exist because OIP messages span two trust regimes. SINGLE uses a single-sender signature (Ed25519 or ECDSA) and suits messages from a single trusted node, such as routine state synchronization originating from a Canton domain or a query from a single client. THRESHOLD uses a BLS aggregated signature with a signer set and a quorum, and provides Byzantine-fault-tolerant origin authentication for messages spanning untrusted relayer sets, such as cross-chain delivery where multiple relayers must collectively attest to the message.

Carrying both schemes in a single header field with a discriminator avoids two parallel header formats while preserving the security guarantee for each origin class. Implementations that do not support THRESHOLD must reject incoming THRESHOLD messages explicitly rather than silently downgrading.

Regulation & Compliance

What are the five principles of RCP?

The Regulatory Compliance Protocol organizes regulatory behavior into five principles. Every state transition admitted to synchronization must satisfy all five:

Traceability: Every transition is attributable to a verified party with a recorded rationale.
Privacy: Personal and business-confidential data is handled in compliance with data protection regulations through selective disclosure.
Enforceability: Regulatory actions ordered by competent authorities are executable on the asset within the protocol.
Finality: Committed transitions are irreversible except through equally-committed transitions of equal authority.
Tokenizability: The asset’s representation, contract terms, and lifecycle are expressible in the protocol’s data model.

See Regulatory Compliance for full descriptions.

What are the six regulatory actions?

Oraclizer defines six protocol-level regulatory actions, each with distinct legal meaning:

FREEZE: Temporarily restricts transferability while preserving legal ownership.
SEIZE: Transfers operational control to a designated authority without transferring legal ownership.
CONFISCATE: Permanently transfers legal ownership.
LIQUIDATE: Forced conversion to a settlement currency, proceeds delivered to a designated beneficiary.
RESTRICT: Constrains transferability by specific rules without freezing entirely.
RECOVER: Restores an asset to a prior owner after a wrongful transfer.

FREEZE, SEIZE, and CONFISCATE form an escalation chain. LIQUIDATE, RESTRICT, and RECOVER are independent actions.

What is the Escalation Chain?

The one-directional sequence of regulatory actions FREEZE → SEIZE → CONFISCATE, each progressively stronger in effect. An asset can move forward along the chain as a regulatory situation escalates (a freeze becomes a seizure, a seizure becomes a confiscation), but the protocol does not allow arbitrary backward transitions. Reversing requires a separate counter-action initiated by the same or higher authority.

What is the difference between SEIZE and CONFISCATE?

The two are different in legal effect, not just severity. SEIZE transfers operational control of the asset to a designated authority (typically the regulator or a court-appointed administrator) while the holder’s legal ownership claim remains intact. The asset is held pending the outcome of an investigation or proceeding; if the proceeding resolves in the holder’s favor, the SEIZE can be reversed and the asset returned. CONFISCATE permanently transfers legal ownership from the previous holder to the state, a beneficiary, or another designated party. Once executed, CONFISCATE cannot be reversed by the protocol; only a separate transfer in the other direction can restore the previous state.

The protocol enforces this distinction at message validation time. CONFISCATE is rejected unless the asset is already SEIZED, ensuring that confiscation cannot occur without a prior seizure step that the holder had the opportunity to contest.

Does CONFISCATE require a waiting period before it can be applied?

Yes. Because CONFISCATE permanently transfers legal ownership and cannot be reversed by the protocol, OIP requires that the asset’s appeal period have expired before a CONFISCATE message is accepted. This is enforced as part of Legal Basis Verification, the pre-lock validation step that confirms a regulatory action’s legal documentation is structurally valid, currently in effect, and consistent with the action being requested.

If a CONFISCATE message arrives while the appeal window is still open, it is rejected before any state change is attempted. The same applies if the supporting legal reference is malformed, expired, or premature. The check sits at the pre-lock stage specifically so that a flawed legal basis can never proceed to lock acquisition or proof generation.

What is the relationship between RAI and OCID?

RAI (Regulated Asset Identity) is a generic identity interface intended for proposal as an EIP standard. It defines what regulated identity should look like at the standard level. OCID (Oracle Contract ID) is Oraclizer’s concrete implementation of RAI, adapted to Oraclizer’s specific architecture. The relationship is interface to implementation: RAI is what other token standards could adopt; OCID is what Oraclizer ships.

How does Oraclizer prevent regulatory authority abuse?

Several mechanisms protect against authority abuse:

Authority hierarchy: Authorities are recognized by jurisdiction (global, national, industry-specific) with codified precedence rules. An authority cannot exceed its jurisdictional scope.
Legal reference required: Every regulatory action must cite the specific statute, court order, or administrative ruling that authorizes it. The Traceability principle prevents unattributed actions.
D-quencer consensus: Regulatory action priority is enforced consensually across the validator set, not by a single sequencer that could be coerced.
Rollback authority separation: Regulatory rollbacks and governance rollbacks have distinct authorization paths.

What role does DAML play in Oraclizer?

DAML (Digital Asset Modeling Language) is the smart contract language used by Canton-based off-chain ledgers. Many regulated financial assets (bonds, equities, structured products) live on DAML contracts on Canton networks operated by financial institutions. Oraclizer integrates with DAML-based contracts through its Canton Driver, allowing state changes in DAML contracts to propagate to on-chain representations and vice versa, all under the same atomicity and compliance guarantees.

How does Oraclizer integrate with Canton?

Through a dedicated Canton Driver that translates between OIP messages and Canton’s DAML-based contract execution. The driver lets a state change recorded on a Canton ledger trigger a corresponding state change on Oraclizer’s L3 (and any other chains where the asset exists), and vice versa. This means a custodian’s DAML contract recording a coupon payment can update on-chain token balances atomically, with the entire transition either succeeding everywhere or rolling back.

What types of assets can be tokenized on Oraclizer?

Oraclizer is designed for regulated real-world assets where compliance and lifecycle management are non-optional. Target asset classes include:

Financial instruments: bonds, equities, structured products, derivatives
Real estate: tokenized property rights, fractional ownership
Intellectual property: licensing rights, royalty streams
Commodities: precious metals, agricultural products with custody arrangements
Other regulated instruments where ownership, regulatory status, and lifecycle must be tracked across multiple domains

The Tokenizability principle requires that the asset’s terms and lifecycle be expressible in the protocol’s data model.

How is regulatory compliance enforced?

Compliance is enforced at the protocol level, not as an overlay. Every state transition admitted to synchronization passes through a compliance contract check at the boundary of the BVC cycle. Transitions failing any of the five RCP principles do not commit. This means a transfer to a sanctioned address, a transaction missing required identity verification, or a regulatory action lacking legal reference cannot be executed regardless of which client submitted it.

How does OIP prevent unbounded escalation in regulatory actions?

The Escalation Chain is enforced at the protocol level: every regulatory action message validates the asset’s current state before applying. SEIZE is rejected unless the asset is already RESTRICTED from a prior FREEZE; CONFISCATE is rejected unless the asset is already SEIZED. Skipping ahead is not possible. Attempts produce explicit errors (FREEZE_REQUIRED_BEFORE_SEIZE, SEIZE_REQUIRED_BEFORE_CONFISCATE) rather than silent acceptance.

The same graduated structure applies to rollback: a CONFISCATE rollback restores the asset to SEIZED, not directly to AVAILABLE. A regulator who confiscates a wrongly-frozen asset by mistake cannot reverse the action in one step; the rollback follows the same one-step-at-a-time path as the escalation. This is what makes the rollback hierarchy soundly verifiable.

What is the four-level Authority Hierarchy?

The Authority Hierarchy recognizes four levels of regulatory authority, from broadest jurisdictional scope to narrowest:

Global: Genuinely global bodies (FSB, BIS) whose decisions apply across jurisdictions.
National: Sovereign regulators within a jurisdiction (national securities regulators, central banks).
Industry: Sector-specific regulators with authority over a particular asset class or market segment.
Self-Regulatory: Industry-organized supervisory bodies that exercise delegated regulatory authority.

The hierarchy determines which authorities can authorize which regulatory actions, defines the permitted scope at each level, and resolves precedence when multiple authorities issue conflicting directives. CRITICAL priority messages must be verified against this hierarchy: a message claiming CRITICAL authority is rejected unless its issuing authority is registered in the AuthorityRegistry and operating within its permitted scope.

Integrations

Why is Oraclizer built as an L3 on Base L2?

Continuous high-frequency state synchronization is economically infeasible if every synchronization carries L1 settlement cost. Building as an L3 amortizes settlement cost across many synchronizations:

Oraclizer L3 processes individual synchronizations
Base L2 aggregates L3 batches
Ethereum L1 provides final settlement

Each layer amortizes the cost of the layer above. Combined with Validium mode for off-chain data availability and zkVerify for batch proof verification, the per-synchronization cost becomes tractable for the synchronization frequencies regulated assets require.

Are Oraclizer tokens compatible with ERC-20, ERC-721, and ERC-1155?

Yes. Oraclizer’s tokenized assets maintain compatibility with the standard ERC interfaces (ERC-20 fungible, ERC-721 non-fungible, ERC-1155 multi-token), so they can interact with existing wallets, exchanges, and on-chain protocols. The regulatory primitives are added as additional interfaces (planned to be standardized as ERC-TRUST), not as breaking changes to ERC-20. This means a compliant token still behaves as an ERC-20 token from the perspective of unrelated contracts, while regulated operations (FREEZE, SEIZE, etc.) extend the surface area.

Network & Operations

What are the staking requirements for node operators?

Node staking parameters:

Minimum stake per node: 10,000,000 OZ
Maximum stake per node: 50,000,000 OZ
Unbonding period: 21 days

The cap on maximum stake prevents single-node concentration of voting power. The unbonding period gives the network time to detect and slash misbehavior before stake can be withdrawn. Detailed node operation requirements will be published with the Network Operation documentation.

How many nodes does the network support?

Network capacity scales across phases:

Phase 1: 20 nodes target
Phase 2: 50 nodes
Phase 3+: 100 nodes

Decentralization progresses across phases as well: Phase 1 has 55% of nodes operated by the team, Phase 2 reduces this to 40%, and Phase 3 brings team operation to no more than 33% of the network. This guarantees that no single party can compromise consensus once the network reaches Phase 3.

Is delegated staking supported?

Yes. Three staking modes are planned:

Solo staking: Operating a node directly with your own stake.
Delegated staking: Delegating your stake to an existing node operator without running infrastructure yourself.
Pool staking: Joining a staking pool that aggregates stake across multiple participants.

Solo staking earns the full reward minus protocol fees; delegated and pool staking share rewards with the operator according to delegation terms.

How does D-quencer consensus work?

D-quencer uses two cryptographic primitives:

BLS signatures for vote aggregation, allowing many validators’ votes to be combined into a single short signature.
VRF (Verifiable Random Function) for leader election, producing unpredictable but verifiable selection of the Active Asserter for each epoch.

The Active Asserter sequences transactions for one epoch; Standby Asserters verify the work and become eligible for the next selection. This combination provides Stage 1 Rollup security without requiring trust in any single sequencer.

What is slashing and when does it apply?

Slashing is the economic penalty applied to staked nodes that violate protocol rules. Slashable behavior includes:

Double-signing (signing conflicting blocks at the same height)
Censoring transactions, particularly regulatory actions
Failing to participate in consensus over an extended period
Producing invalid state transitions

Slashed stake is partially burned and partially redirected to the insurance pool, which compensates affected parties in cases of protocol-level loss. Detailed slashing parameters will be published with the Network Operation documentation.

What throughput does Oraclizer target?

Oraclizer measures throughput in SPS (Syncs Per Second). One Sync Unit is one completed state synchronization (one full BVC cycle). TPS is not used because Oraclizer’s synchronization workload is not directly comparable to a chain transaction.

Phase-by-phase targets for a single OSS instance:

Phase 1: ~500 SPS (StateSync-GKR v0.1, single-path, batching not yet enabled)
Phase 2: ~2,000 SPS (StateSync-GKR v0.2 with deadline-aware batching plus pipeline parallelism)
Phase 3+: per-industry-section OSS instance separation. Each industry section runs its own OSS instance, so total network throughput scales with the number of sections × per-instance SPS.

These figures are theoretical projections based on simulation, not measured benchmarks. Actual numbers will be confirmed in the StateSync-GKR v0.1 benchmark report and updated here as they are validated. The figures assume modern x86 (AVX-512) or ARM (NEON) hardware.

What happens when retries are exhausted?

OIP combines at-least-once delivery with bounded retry: a sender retries a failed message until the configured retry budget is exhausted, with exponential backoff between attempts. When retries are exhausted, the message is moved to the Dead Letter Queue rather than dropped or silently retried indefinitely. From there, the DLQ Recovery Protocol takes over:

Notify: operators are alerted with the message ID, failure history, and last error.
Analyze: the failure is classified as transient or permanent, and impact is assessed.
Decide: the operator chooses between retry with a new messageId, abandon, or governance escalation.
Record: a signed decision record is persisted for audit.

DLQ entries follow a 30-day default retention; signed decision records are retained indefinitely. The structure ensures that a stuck message never silently disappears and never silently retries forever — every outcome is decided explicitly and recorded for audit.

Security & Trust

How are zero-knowledge proofs verified?

Oraclizer uses a layered proof verification path:

StateSync-GKR generates synchronization proofs for individual state transitions using the GKR protocol, which keeps proof generation fast enough to meet the cadence regulated assets require.
Proofs are wrapped in fflonk for compatibility with the broader verification path.
zkVerify, operated by Horizen Labs, performs batch verification of proofs.
Final settlement on Base L2 → Ethereum L1.

Batch verification at the zkVerify layer is what makes per-synchronization verification cost tractable for high-frequency synchronization workloads.

Why is Oraclizer built around formal verification?

An oracle state machine that binds state across regulated, heterogeneous domains is a new primitive for blockchain infrastructure. There is no precedent that can be relied on to confirm that the design is correct, and testing alone cannot establish the central guarantee: tests demonstrate observed cases, while the property the system needs to provide is that no reachable case violates atomicity. For a system whose primitives are new, this gap has to be closed by mathematical proof.

Oraclizer is therefore designed with formal verification at the center of its architecture, not as a downstream review activity. Core protocol properties are formalized as theorems in Isabelle/HOL and proved against explicit assumptions, with the Rust implementation maintaining a refinement relation against the verified models. The first two properties have already been formally verified and published on arXiv:

Cross-domain state preservation: regulatory state is preserved exactly under cross-domain transitions.
Liveness under Byzantine faults: deterministic resolution, deadlock freedom, and starvation freedom under the standard f < n/3 threshold.

Further properties are being proven as the protocol takes shape. Throughout the documentation, properties that have been proven are described as such, while properties still in progress are described as design intent rather than as guarantees. Completed verification artifacts are published in the oraclizer/formal-verification repository.

How does Oraclizer protect against cross-chain attacks?

Cross-chain message integrity is handled by CCMI, an internal module of OSS, not a separate bridge product. CCMI provides four safety guarantees:

Replay resistance: nonce-based uniqueness ensures the same message cannot execute twice.
Source authentication: receiving chain does not accept a message without source-chain proof.
Dual-chain commit atomicity: the message reflects consistently on both chains or rolls back on both.
Relayer threshold soundness: f+1 honest relayer signatures are required; f or fewer Byzantine relayers cannot forge a message.

These guarantees are formally verified as part of Oraclizer’s Isabelle/HOL proof corpus. The cross-domain state preservation property underlying CCMI’s atomicity guarantees has been mechanically proven and published on arXiv; CCMI-specific properties (replay resistance, source authentication, threshold soundness) are within the scope of Oraclizer’s ongoing formal verification program.

What does Stage 1 Rollup security mean for Oraclizer?

Stage 1 Rollup is a recognized benchmark for rollup decentralization. For Oraclizer, it means:

No single party controls transaction ordering (D-quencer’s distributed consensus replaces a single sequencer).
Regulatory action priority is enforced consensually across the validator set, not by a single party.
Users retain self-sovereign exit paths even under adverse operator behavior, including a Force Inclusion path through Base L2.
The network can survive operator failure without requiring user intervention.

This is the level of decentralization users and regulators can rely on without the protocol becoming dependent on any single operator.

How do preemptive locks prevent double-spending?

A preemptive lock is acquired on the asset across every participating domain at the start of a synchronization, before validation or proof generation. While the lock is held, no other transaction can move the same asset on any of those domains. If two transfers of the same asset are submitted simultaneously, only one acquires the lock; the other waits or fails. Combined with cross-chain atomic commit semantics, this prevents an asset from being spent on chain A while a parallel transfer is still in progress on chain B.

What is the role of RWA Registry self-defense?

Self-defense is the principle that an RWA Registry contract performs its own authority, state, and proof checks rather than trusting OIP unconditionally. The contract validates the issuing authority, the current asset state, and the proof of the proposed transition before applying any change.

Self-defense matters because Oraclizer supports a Force Inclusion path: when D-quencer or OIP processing is unavailable, users can submit transactions directly through Base L2 to reach the L3, bypassing the OIP path entirely. Without self-defense, the two paths could end up with different safety guarantees. With self-defense, the Registry rejects an invalid transition the same way regardless of which path delivered it. The OIP path and the Force Inclusion path therefore share equivalent safety guarantees, which is what allows Force Inclusion to exist as a fallback rather than a vulnerability.

What guarantees does the Preemptive Lock provide?

The preemptive lock mechanism provides four invariants that any compliant lock manager must satisfy:

Deadlock freedom: lock request cycles do not occur, achieved by acquiring locks in a deterministic order (typically asset ID lexicographic ordering).
Lock timeout safety: every lock is released in finite time, enforced by the T_lock = max(T_finality^Di) + T_margin TTL.
No lost updates: concurrent updates against a held lock are blocked, not silently overwritten.
Lock granularity correctness: asset-level locking prevents partial-update conflicts on the same asset.

Together, these invariants are what allow the Bind-Verify-Commit cycle to behave as if it were atomic across heterogeneous domains. Their joint soundness is established through formal verification rather than assumed by convention.

What is the difference between DIVERGED and ROLLBACK_INCOMPLETE states?

Both are values of the CoherenceState enum that indicate cross-chain inconsistency, but the cause and the remedy are different.

DIVERGED is unintentional inconsistency. It happens when cross-chain propagation succeeded on some chains but failed on others without an explicit rollback being initiated. Recovery uses the PrimaryFinalityRecord as the authoritative reference: divergent chains are force-synchronized back to the primary state.
ROLLBACK_INCOMPLETE is an intentional rollback in progress. It happens when an ALL_OR_NOTHING message succeeded on some chains but failed on others, and the protocol issued Rollback Messages that have not yet converged across all chains. Resolution requires governance: the rollback can be forced to completion, the partial state can be recognized as a new synced baseline, or all chains can be force-synchronized to the primary finality record.

The distinction matters because operational responses differ. DIVERGED is recovered automatically through reconciliation; ROLLBACK_INCOMPLETE requires explicit governance decision-making.

What is the difference between FAILED and REJECTED ACKs?

Both indicate that a message did not succeed, but they tell the sender different things about how to respond. REJECTED means the message was refused before any side effect was produced — typically due to a validation failure such as a malformed signature, a TTL violation, an unknown chain, or an authority check failure. The sender knows nothing changed and can reformulate without worrying about partial state.

FAILED means processing started and produced a side effect that is now invalidated. This happens during cross-chain operations where a state change committed on one chain but a postcondition failed on another, or during a BVC cycle where a downstream domain rejected the proof after upstream domains had already locked. FAILED ACKs are typically followed by a Rollback Message that explicitly reverses the partial commit.

This distinction maps directly to the Handling Action the receiver expects from the sender: REJECTED maps to retry-or-reformulate, FAILED maps to wait-for-rollback. Conflating the two is what leads to double-application bugs in less rigorous protocols.

FAQ