Glossary
Definitions of technical terms used throughout the Oraclizer documentation. Terms are listed in alphabetical order.
ACK
One of the seven OIP message types. An acknowledgment message that confirms receipt and processing status of a previous message. Used by participating systems to signal successful delivery, validation result, or processing failure back to the sender.
Active Asserter / Standby Asserter
Roles in D-quencer consensus. The Active Asserter is the node currently elected to sequence transactions for an epoch. Standby Asserters form the validator pool that verifies the Active Asserter’s work and is eligible for selection in subsequent epochs through VRF-based leader election.
Address Resolution
The OIP validation step that parses an ERC-3770 chain-prefixed address, resolves the short name against the ChainRegistry, validates the EIP-55 checksum on mixed-case addresses, and confirms asset existence by lookup in the RWA Registry. Address Resolution runs before authority verification, since an unresolvable address makes downstream authority lookup impossible. Failures produce explicit errors (INVALID_ADDRESS_FORMAT, UNKNOWN_CHAIN_SHORT_NAME, INVALID_ADDRESS_CHECKSUM, CHAIN_NOT_SUPPORTED) rather than silent rejection.
AssetLocationMap
A component of the OIP RoutingContext that maps each asset ID to the set of chains where the asset exists. Used during recipient derivation: when a message targets an asset, the routing layer consults AssetLocationMap to determine which chains the asset currently lives on.
At-Least-Once Delivery
A messaging guarantee where every message is delivered at least once, but possibly more than once. Combined with idempotency at the receiver, at-least-once delivery provides reliable processing without requiring exactly-once semantics at the transport layer.
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.
AtomicityStrategy
An OIP enum that specifies the atomicity guarantee required for a state synchronization. Three values: BEST_EFFORT (parallel execution, may produce partial updates), GUARANTEED (staged execution, strong consistency on participating chains), and ALL_OR_NOTHING (staged execution across all chains, full atomicity required).
Atomicity-Driven Coordination
OIP’s coordination strategy where the chosen AtomicityStrategy determines the execution pattern. BEST_EFFORT maps to parallel execution; GUARANTEED and ALL_OR_NOTHING map to staged execution with progressively stronger atomicity requirements.
Authority Hierarchy
The four-level structured ranking of regulatory authorities recognized by the protocol: Global (FSB, BIS, and other genuinely global bodies), National (sovereign regulators within a jurisdiction), Industry (sector-specific regulators), and Self-Regulatory (industry-organized supervisory bodies). The hierarchy determines which authorities can authorize which regulatory actions, defines permitted scope for each level, and resolves precedence when multiple authorities issue conflicting directives. CRITICAL priority messages require verification against this hierarchy before execution.
AuthorityRegistry
A component of the OIP RoutingContext that records registered regulatory authorities. Each entry holds the authority ID, authority type (Global, National, Industry, Self-Regulatory), jurisdiction, permitted scope, and verification keys. The registry is the prerequisite for CRITICAL priority verification: a message claiming CRITICAL authority is rejected unless its issuing authority is registered here and operating within its permitted scope.
Base L2
A Layer 2 rollup on Ethereum, on which Oraclizer’s L3 settles. Base provides cost-amortized transaction processing and ecosystem integration as the intermediate layer between Oraclizer’s L3 and Ethereum L1.
BFT (Byzantine Fault Tolerance)
A property of consensus systems that maintain correctness even when a fraction of participating nodes behave maliciously or unpredictably. D-quencer consensus is BFT-secure, surviving up to one-third Byzantine nodes in the standard threshold model.
Bidirectional State Synchronization
State synchronization that flows in both directions between participating domains, rather than only from one source to others. A change originating off-chain propagates to on-chain representations, and a change originating on-chain propagates back to off-chain ledgers. This is the core capability that distinguishes an oracle state machine from a conventional data oracle.
Bind-Verify-Commit (BVC)
The three-phase cycle that OSS uses to perform state synchronizations. Bind acquires preemptive locks on the asset across every participating domain, holding them for a duration determined by T_lock = max(T_finality^Di) + T_margin (the maximum finality time across participating domains plus a safety margin). Verify validates the proposed transition against protocol rules and generates a cryptographic proof. Commit propagates the verified transition atomically to all domains. Failure at any phase rolls back the entire cycle; no domain is left partially updated. Note that the BVC.Commit phase wraps the cross-chain Three-Phase Broadcast rounds; the inner COMMIT round is one phase inside the outer BVC.Commit envelope.
BLS (Boneh-Lynn-Shacham) Signature
A cryptographic signature scheme that supports efficient signature aggregation, allowing many signatures to be combined into a single short signature. D-quencer uses BLS signatures for consensus, enabling compact representation of multi-node validator agreement.
CAIP-2 / CAIP-10
Chain Agnostic Improvement Proposals defining standardized identifiers for blockchain networks (CAIP-2) and accounts on those networks (CAIP-10). OIP uses CAIP standards as part of its address resolution scheme to identify participants and assets across multiple chains. See CAIP-2 and CAIP-10.
Canton
An enterprise-grade privacy-enabled blockchain network used by financial institutions for tokenized real-world assets. Canton uses the DAML smart contract language and supports need-to-know data sharing between transacting parties. Oraclizer integrates with Canton through a dedicated driver.
Canton Driver
The Oraclizer driver that connects the L3 to Canton-based off-chain systems. The Canton Driver translates between OIP messages and Canton’s DAML-based contract execution, enabling state synchronization between off-chain financial ledgers and on-chain representations.
CCMI (Cross-Chain Message Integrity)
An internal module of OSS that handles cross-chain message integrity guarantees, including replay resistance, source authentication, dual-chain commit atomicity, and threshold soundness. CCMI is not a stand-alone bridge product; it is the layer that allows the same atomicity guarantees to apply across chains as within a single chain.
ChainRegistry
A component of the OIP RoutingContext that holds information about supported chains: CAIP-2 chain ID, ERC-3770 short name, RPC endpoint, and active status. The routing layer consults ChainRegistry to filter recipient candidates, excluding chains marked inactive or unreachable.
CoherenceState
An OIP enum representing the cross-chain consistency state of an asset. Four values: SYNCED (all domains reflect the same state), SYNCING (a synchronization is in progress), DIVERGED (domains hold inconsistent states, requiring reconciliation), and ROLLBACK_INCOMPLETE (intentional rollback in progress after an ALL_OR_NOTHING failure).
Compliance Contract
The agreement that every state transition admitted to synchronization must satisfy all five principles of the Regulatory Compliance Protocol (Traceability, Privacy, Enforceability, Finality, Tokenizability). The compliance contract is checked at the boundary of the BVC cycle; transitions failing any principle do not commit.
CONFISCATE
A regulatory action that permanently transfers legal ownership of an asset from the previous holder to the state, a beneficiary, or another designated party. CONFISCATE is the terminal step in the FREEZE → SEIZE → CONFISCATE escalation chain. Once executed, it cannot be reversed by the protocol; only a separate transfer in the other direction can restore the previous state.
Content-Based Routing
OIP’s routing strategy where the destination of a message is determined by its content (message type, target asset, regulatory context) rather than a fixed routing table. The routing decision logic examines the message payload at each hop to determine the next destination, enabling flexible routing across heterogeneous domains.
ContractStatus
An OIP enum representing the lifecycle state of a contract. Five values: PENDING, ACTIVE, COMPLETED, CANCELLED, DISPUTED.
Cross-Chain Action Coordinator
A D-quencer component responsible for coordinating regulatory actions and state changes that span multiple chains. The coordinator ensures that cross-chain actions execute with the required atomicity guarantees and rollback semantics.
Cross-Domain Effect
A property of a state change in one domain that affects asset state in another domain. Used as a criterion for promoting a message across domain boundaries: a transition with cross-domain effect must be coordinated through the BVC cycle across every affected domain, not applied locally and propagated as an afterthought.
CrossChainScope
An OIP structure that specifies which chains participate in a cross-chain operation, including their identifiers (CAIP-2), required atomicity level, and ordering constraints. Used by OSS and CCMI to coordinate operations across multiple chains.
DAML
Digital Asset Modeling Language. A smart contract language designed for distributed financial applications. DAML’s permissioning model expresses obligations, rights, and authorities as first-class concepts, making it suitable for representing legally-binding contracts on distributed ledgers. Oraclizer integrates with DAML-based contracts running on Canton.
DAS (Data Availability Sampling)
A mechanism that allows light clients to verify data availability without downloading entire datasets, by sampling random portions and using error-correcting codes. Oraclizer uses a DAS-based approach for data availability, supporting flexible DA provider selection without protocol changes.
Dead Letter Queue (DLQ)
A queue for messages that cannot be successfully processed after retries, allowing them to be inspected and resolved manually rather than blocking the main message flow. OIP specifies DLQ behavior as part of its at-least-once delivery model. The recovery procedure follows the DLQ Recovery Protocol.
Delta Synchronization
A synchronization optimization that transmits only the changes between successive states rather than the full state. Used to reduce bandwidth and processing overhead for high-frequency state updates within a session.
Divergence Detection
The process of detecting when domains holding the same asset have arrived at inconsistent states. OSS performs divergence detection as part of cross-chain coherence monitoring; detected divergences trigger reconciliation procedures.
DIVERGED State
A value of the CoherenceState enum indicating that domains holding the same asset have reached inconsistent states unintentionally, typically because cross-chain propagation succeeded on some chains but failed on others. Distinct from ROLLBACK_INCOMPLETE: DIVERGED reflects discovered inconsistency that needs reconciliation, while ROLLBACK_INCOMPLETE reflects an intentional rollback still in progress. Recovery uses the PrimaryFinalityRecord as the authoritative reference; divergent chains are force-synchronized back to the primary state.
DLQ Recovery Protocol
The four-step procedure OIP specifies for handling messages that have entered the Dead Letter Queue: notify (alert operators with the message ID, failure history, and last error), analyze (classify the failure as transient or permanent and assess impact), decide (choose between retry with a new messageId, abandon, or governance escalation), and record (persist a signed decision record for audit). DLQ entries follow a 30-day default retention; signed decision records are retained indefinitely.
D-quencer
The decentralized sequencer that orders transactions on the Oraclizer L3. D-quencer uses BLS-signature consensus and VRF-based leader election to ensure that no single party controls transaction ordering, enforces regulatory action priority consensually, and provides Stage 1 Rollup security. Operator failure is survivable without user intervention.
D-quencer Consensus
The consensus mechanism used by D-quencer, combining BLS signature aggregation for vote tallying with VRF-based leader election for fairness. Designed to provide regulatory action priority handling and rollback authority that single-sequencer designs cannot.
Driver Attestation
A signed assertion issued by a domain driver (such as the Canton Driver) that conveys domain-internal facts to OIP. Examples include party authorization, contract activation, and observer membership. Driver attestations are how OIP receives reliable evidence about events inside off-chain domains it does not control directly, and are validated as part of the BVC Verify phase.
EIP-55
The Ethereum standard for mixed-case checksum encoding of addresses. EIP-55 uses upper and lower case in hexadecimal address strings to encode a checksum that detects typing errors. OIP follows an “ingress normalize, egress enforce” policy: incoming all-lowercase addresses are normalized to mixed case, mixed-case addresses are checksum-verified on ingress and rejected on failure, and outgoing addresses MUST be serialized in mixed-case form. See EIP-55.
Enforceability
One of the five RCP principles. Requires that regulatory actions, when ordered by competent authorities, be executable on the asset within the protocol. An asset that cannot be frozen, restricted, or seized when legally required is not compliant under RCP.
Epoch
A bounded period of consensus in D-quencer during which a specific Active Asserter is responsible for sequencing. At the end of an epoch, VRF-based selection chooses the Active Asserter for the next epoch.
ERC-1400
A security token standard on Ethereum that introduced concepts like partitioned tokens, transfer restrictions, and document references. RAI and Tokenizability in Oraclizer build on lessons from ERC-1400 while addressing requirements ERC-1400 does not cover. See ERC-1400.
ERC-20 / ERC-721 / ERC-1155
Ethereum token standards. ERC-20 defines fungible tokens; ERC-721 defines non-fungible tokens; ERC-1155 defines multi-token contracts that can hold both fungible and non-fungible balances. Oraclizer’s tokenized assets are compatible with these standards while extending them with regulatory primitives.
ERC-3643
The T-REX token standard for permissioned tokenization of regulated assets. Notable for its identity registry approach to compliance. RAI draws on ideas from ERC-3643 while generalizing the identity layer beyond a single token standard. See ERC-3643.
ERC-3770
The Ethereum standard for chain-specific addresses, prefixing addresses with a chain identifier (e.g., eth:0x...). OIP uses ERC-3770 alongside CAIP-2 for unambiguous cross-chain address resolution. See ERC-3770.
ERC-TRUST
Total Regulatory Unified Security Token. A token standard under design by the Oraclizer team to unify regulatory primitives (identity, authority, transfer restrictions, regulatory actions) into a single Ethereum standard. Builds on lessons from ERC-1400 and ERC-3643.
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, and the protocol enforces the order at message validation time: SEIZE requires a prior FREEZE, CONFISCATE requires a prior SEIZE. Reversal proceeds in the same graduated fashion: a CONFISCATE rollback restores the asset to SEIZED, a SEIZE rollback restores it to RESTRICTED, and a FREEZE rollback restores it to AVAILABLE.
fflonk
A SNARK construction used in Oraclizer’s proof verification path. StateSync-GKR generates GKR-based proofs that are wrapped in fflonk for compatibility with the zkVerify batch verification layer.
Finality
One of the five RCP principles. Requires that committed state transitions be irreversible except through equally-committed transitions of equal authority. Finality applies uniformly across every domain holding the asset; partial finality (committed in one domain, pending in another) is not a state the protocol allows to persist.
Force Inclusion
The path that allows users to submit transactions directly through Base L2 to reach Oraclizer’s L3 when D-quencer or OIP processing is unavailable, bypassing the OIP path entirely. Force Inclusion is the self-sovereign exit guarantee that makes Oraclizer a Stage 1 Rollup: the network does not depend on any single operator remaining online for users to interact with the L3. Safety equivalence with the OIP path is maintained by RWA Registry self-defense, which performs the same authority and state-invariant checks regardless of which path delivered the transaction. External propagation of force-included transactions is deferred until D-quencer recovers, with the OSS pending sync queue picking up the deferred work.
FREEZE
A regulatory action that temporarily restricts the transferability of an asset while preserving the holder’s legal ownership. The first step in the FREEZE → SEIZE → CONFISCATE escalation chain. Freezes are typically reversible; the same authority that imposed the freeze can lift it.
GKR Protocol
A zero-knowledge proof protocol (named after Goldwasser, Kalai, and Rothblum) optimized for layered arithmetic circuits. GKR provides low-overhead proof generation for high-frequency, structured workloads. StateSync-GKR uses the GKR protocol as the basis for synchronization proof generation in Oraclizer.
GOVERNANCE
One of the seven OIP message types. Carries protocol-level governance proposals, votes, and parameter changes. Distinguished from regulatory actions by the source of authority: governance messages come from the network’s collective decision-making, not from external regulatory authorities.
Handling Action
The five protocol-defined recovery paths that every OIP error code maps to: REJECT (immediate rejection before any side effect), RETRY (transient failure, sender expects redelivery), ROLLBACK (a side effect was committed but is now invalidated, reverse the transition), ESCALATE (reroute the message under a higher priority or different type), and DIVERGE (cross-chain inconsistency detected, declare the asset DIVERGED and pause new transactions until reconciliation completes). The mapping from error code to handling action is part of the protocol contract: a sender can rely on receiving a deterministic response class for any given code.
HEARTBEAT
One of the seven OIP message types. Used for liveness checks and connection maintenance between participating systems. Heartbeats carry no business payload but signal that a participant is operational and reachable.
Hierarchical Lock Status
The composite lock state of an asset, structured into five layers: primary (the authoritative PrimaryLockState), secondary (an optional supplementary SecondaryLockState), regulatoryContext (issuing authority and legal basis when a regulatory action is in effect), temporalConstraints (time-bound conditions such as auto-expiry), and crossChainCoherence (cross-chain synchronization state). The hierarchical structure lets a receiver use whichever layers it understands while ignoring the rest, separating authoritative state from supplementary information.
Horizen Labs
The team behind zkVerify, Oraclizer’s proof verification infrastructure partner. Horizen Labs provides batch verification of zero-knowledge proofs, allowing Oraclizer to offload verification cost from Ethereum L1.
Idempotency
A property where repeated application of an operation produces the same result as a single application. OIP message handlers are required to be idempotent so that at-least-once delivery can be combined with safe retry behavior.
Incremental State Proof
A proof that attests to a state change relative to a previously-proved state, rather than to the full state from scratch. Incremental state proofs reduce proof generation cost for high-frequency synchronizations and are part of Oraclizer’s cost optimization strategy.
Insurance Pool
A reserve fund within Oraclizer’s economic model that compensates affected parties in cases of protocol failure or extraordinary loss not covered by individual node staking. Capitalized through a portion of protocol fees and slashed stakes.
Isabelle/HOL
An interactive theorem prover used by Oraclizer to formally verify protocol properties at the model level. Core protocol theorems (state preservation, lock correctness, rollback soundness, and others) are specified and proved in Isabelle/HOL, with the Rust implementation maintaining a refinement relation against the verified models.
L3 zk-Rollup
The third layer in Oraclizer’s blockchain stack. The L3 settles on Base (L2), which in turn settles on Ethereum (L1). The L3 architecture amortizes settlement cost across many synchronizations, making continuous high-frequency state synchronization economically feasible. Oraclizer’s L3 operates in Validium mode by default with Volition support for selective zk-Rollup mode.
Legal Basis Verification
The OIP validation step that confirms a regulatory action’s legal documentation is structurally valid, currently in effect (not expired or premature), and consistent with the action being requested. For CONFISCATE messages specifically, this step also verifies that the asset’s appeal period has expired before the irreversible action can proceed. Legal Basis Verification runs as part of pre-lock authority verification, so a flawed legal basis is rejected before any state change is attempted.
Legal Reference
An OIP structure attached to regulatory actions, citing the specific statute, court order, or administrative ruling that authorizes the action. Legal references support the Traceability principle by ensuring every regulatory action has a recorded legal basis.
LIQUIDATE
A regulatory action of forced conversion. The asset is converted to a settlement currency (typically a stablecoin) and the proceeds are delivered to the designated beneficiary. Applies in cases such as bankruptcy proceedings, court-ordered asset sales, or regulatory mandates requiring asset disposition. Independent of the FREEZE-SEIZE-CONFISCATE chain.
LOCK_MANAGEMENT
One of the seven OIP message types. Carries lock acquisition, release, and status query operations as part of the preemptive locking protocol used in BVC cycles.
Lock TTL Alignment
The MUST requirement that any preemptive lock acquired for a cross-chain message remain held throughout that message’s retry window. The protocol formalizes the relationship as Lock TTL ≥ message TTL + (max_retries × max_backoff). Without this alignment, a retry attempt could complete after the original lock expired, allowing a competing transaction to slip in during the gap and break atomicity. Implementations that configure shorter lock TTLs are non-conformant.
NodeRegistry
A component of the OIP RoutingContext that records OIP node identities. Each entry holds the node ID, public key, supported message types, and supported atomicity levels. The routing layer uses NodeRegistry for capability checks and recipient eligibility.
OCID (Oracle Contract ID)
Oraclizer’s concrete implementation of the RAI interface. OCID adapts the generic RAI standard to Oraclizer’s specific architecture, integrating with zk-basis ID for proof generation, with the RWA Registry for asset binding, and with OSS for cross-domain identity propagation.
OEV (Oracle Extractable Value)
The value extractable by oracle operators or front-runners from the timing and content of oracle updates, analogous to MEV in the broader transaction ordering context. Oraclizer eliminates OEV structurally through bidirectional state synchronization and preemptive locks, removing the asymmetric information windows that OEV depends on.
OIP (Oracle Interoperability Protocol)
The protocol specification that defines what a state synchronization message looks like, which state transitions are valid, how regulatory actions are encoded, how routing works, and how cross-chain coordination is achieved. OIP is the protocol document that implementations must conform to in order to interoperate. OSS is Oraclizer’s reference implementation of OIP.
OIP Domain
A unit system that an OIP message can reach. Each EVM chain, each Canton instance, and the L3 itself are distinct OIP Domains. The domain is the scope at which preemptive locks are acquired, atomicity guarantees apply, and Driver Attestations are issued. A state transition with cross-domain effect must coordinate across multiple OIP Domains through the BVC cycle.
OIPMessageType
An OIP enum with seven values defining the kind of message being transmitted: STATE_SYNC, REGULATORY_ACTION, LOCK_MANAGEMENT, QUERY, ACK, HEARTBEAT, GOVERNANCE. The message type determines the processing pipeline, validation rules, and routing behavior applied to the message.
Oracle Session
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; 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.
Oracle State Machine
A specialized state machine that performs bidirectional state synchronization across on-chain, off-chain, and cross-chain environments. Distinguished from conventional data oracles, which deliver values one-directionally without coordinating state across domains. Oraclizer is an oracle state machine.
OracleMint
Oraclizer’s tokenization platform. OracleMint is where real-world assets (bonds, equity, structured products, real estate, commodities) are issued as tokens with the legal properties required for regulated finance, including contract terms, regulatory class, lifecycle parameters, and transfer restrictions.
OSS (Oracle State Synchronizer)
Oraclizer’s reference implementation of OIP. OSS is the component that actually performs synchronizations: detecting state changes in their origin domain, running them through the BVC cycle, generating proofs, and committing them across every domain where the asset exists. OSS organizes synchronizations around Oracle Sessions.
OZ Token
Oraclizer’s native protocol token. Used for staking, fee payment, and governance. Detailed economic parameters are described in the dedicated economy documentation.
Pay-per-sync
Oraclizer’s billing model where the unit of charge is a state synchronization (a completed BVC cycle), not a transaction or a time window. The first synchronization of an Oracle Session carries higher cost than subsequent ones because identity and asset bindings are established once per session.
Pending Sync Queue
An OSS-internal queue tracking messages whose primary finality has been issued but whose external propagation (settlement finality) has not yet completed. OIP specifies four invariants that any compliant implementation must satisfy: deterministic tracking, idempotency preservation, long-term primary finality preservation, and source-of-truth usage during reconciliation. The concrete data structure and scheduling algorithm are implementation choices outside the OIP normative scope.
Postcondition Verification
The OIP validation step that confirms cross-chain state changes satisfy their postconditions on every participating chain after the COMMIT phase has dispatched. A postcondition violation under ALL_OR_NOTHING atomicity triggers an automatic rollback sequence: every chain that successfully committed receives an explicit rollback message, restoring the system to the pre-commit state. Single-chain postcondition failures roll back only the affected chain. Postcondition Verification is what closes the gap between “the message was dispatched” and “the message took effect consistently”.
Preemptive Lock
A locking mechanism applied to an asset across every participating domain at the start of a state synchronization, before validation or proof generation. Preemptive locks prevent concurrent transactions on the same asset from interleaving and creating inconsistent states. Acquired during the Bind phase of the BVC cycle and released on commit or rollback. Every preemptive lock is guaranteed to release within a bounded time even if the holding node crashes, through automatic TTL expiry; this finite-lifetime property is one of the safety guarantees verified in Oraclizer’s formal verification work.
Primary Finality
The point at which the OSS State Root is fixed by GKR proof issuance. OSS treats primary finality as its source of truth and preserves it permanently across lock expiration, reconciliation, and the boundary between pre-trading and settlement finality. Distinguished from secondary finality, which is the external settlement finality reached through the fflonk → zkVerify → Base L2 path.
PrimaryFinalityProof
An OIP structure that records evidence of primary finality for a state. Contains the OSS State Root, the GKR proof hash, the issuance timestamp, and the OSS epoch. Used as the authoritative reference during reconciliation: when chains diverge, the PrimaryFinalityProof determines the canonical state to which they must be force-synchronized.
PrimaryFinalityRecord
The persistent record of primary finality for a synchronized state, stored in OSS as the source-of-truth artifact. Where PrimaryFinalityProof is the evidence object inside an OIP message, the PrimaryFinalityRecord is the OSS-internal canonical record that survives lock expiration, reconciliation, and divergence resolution. Recovery procedures (gap recovery, DIVERGED reconciliation, Force Inclusion settlement) all converge on the PrimaryFinalityRecord as the authoritative reference. Conformant implementations MUST persist this record in verifiable form for the long term.
PrimaryLockState
An OIP enum representing the top-level lock state of an asset. Five values: AVAILABLE, RESERVED, RESTRICTED, SEIZED, TERMINATED. Used in combination with SecondaryLockState to form the hierarchical lock status.
Priority
An OIP enum specifying the urgency of a message. Five values: CRITICAL, REGULATORY, HIGH, NORMAL, LOW. Higher priority messages are sequenced ahead of lower priority ones; REGULATORY ensures regulatory actions take precedence over ordinary state synchronizations.
Priority-Based Atomicity Escalation
An OIP rule where higher-priority messages automatically receive stronger atomicity guarantees. A CRITICAL or REGULATORY message defaults to ALL_OR_NOTHING atomicity even if a weaker level was requested, ensuring that high-stakes operations cannot be partially applied.
Privacy
One of the five RCP principles. Requires that personal data, business-confidential information, and sensitive transaction details be handled in compliance with data protection regulations. Implemented through selective disclosure using zero-knowledge proofs.
Privado.ID
A decentralized identity infrastructure that zk-basis ID can leverage for the underlying identity primitives. Privado.ID is one of the external identity solutions Oraclizer’s identity component is designed to integrate with.
QUERY
One of the seven OIP message types. Used to retrieve asset state, lock status, regulatory state, or other read-only information from a participating system without modifying state.
RAI (Regulated Asset Identity)
A generic identity interface intended for proposal as an EIP standard. RAI defines what regulated identity should look like at the standard level: how to bind transactions to verified parties, how to express authority, how to support selective disclosure. OCID is Oraclizer’s concrete implementation of RAI.
RCP (Regulatory Compliance Protocol)
The framework that organizes Oraclizer’s regulatory behavior into five principles (Traceability, Privacy, Enforceability, Finality, Tokenizability) and six regulatory actions (FREEZE, SEIZE, CONFISCATE, LIQUIDATE, RESTRICT, RECOVER). RCP consolidates regulatory requirements drawn from multiple jurisdictions and financial regulators into operational principles that any compliant state transition must satisfy.
RECOVER
A regulatory action that restores an asset to a prior owner after a wrongful transfer. Applies in cases such as fraud-recovery proceedings, legally-mandated reversals of unlawful transactions, or court-ordered restitution. Treated as a regulatory action rather than a normal transfer because it overrides standard ownership-transfer constraints.
REGULATORY_ACTION
One of the seven OIP message types. Carries one of the six regulatory actions (FREEZE, SEIZE, CONFISCATE, LIQUIDATE, RESTRICT, RECOVER) along with the legal reference and authorizing party. Subject to priority-based atomicity escalation.
Regulatory Action
A protocol-level state transition initiated by an authorized party (regulator, court, or designated authority). Oraclizer defines six: FREEZE, SEIZE, CONFISCATE, LIQUIDATE, RESTRICT, RECOVER. Each is processed through the same BVC cycle as ordinary state transitions and propagated atomically across every domain holding the asset.
Regulatory Authority
A body that holds protocol-recognized power to issue regulatory actions. Each authority is registered in the AuthorityRegistry with its level (Global, National, Industry, or Self-Regulatory in the Authority Hierarchy), jurisdictional scope, and verification keys. The registration determines which scopes the authority may target and which authorities take precedence in conflicts.
Regulatory Context
An OIP structure carrying jurisdiction, applicable rules, and authority information attached to a state transition or regulatory action. The regulatory context determines which rules the protocol must enforce for that particular operation.
Regulatory Priority Matrix
A protocol-defined matrix that resolves precedence when multiple regulatory authorities issue conflicting actions on the same asset. The matrix incorporates jurisdictional hierarchy, action severity, and temporal ordering to determine which directive takes effect.
RegulatoryPayload
The common envelope structure that every REGULATORY_ACTION message uses, regardless of which of the six regulatory actions it carries. RegulatoryPayload identifies the action type, the target asset, the issuing authority and its claim, the action-specific parameters (FREEZE scope, SEIZE custody address, CONFISCATE finality proof, etc.), and the supporting evidence (legal documents, hashes, witness signatures). This common shape lets validation, routing, and audit handle the six actions through a single processing path even though each action carries different action-specific parameters.
Restricted DSL
A constrained domain-specific language used in OIP for expressing conditions such as the preconditions of a temporal constraint or the activation rule of a scheduled regulatory action. The grammar is restricted to a defined set of primitives and does not allow arbitrary code execution. The restriction makes condition evaluation deterministic across nodes and bounded in resource usage.
RESTRICT
A regulatory action of conditional limitation. The asset’s transferability is constrained by specific rules (transfers only to whitelisted addresses, transfers only within a jurisdictional boundary, transfers only above or below a threshold) without freezing it entirely. Used when authorities require continued asset usage under controlled conditions.
RFC 2119
An IETF document defining the meaning of normative keywords (MUST, SHOULD, MAY, etc.) used in protocol specifications. OIP and other Oraclizer specification documents follow RFC 2119 conventions for unambiguous requirement statements. See RFC 2119.
ROLLBACK_INCOMPLETE
A value of the CoherenceState enum, added in OIP v0.5. Indicates that an intentional rollback is in progress after an ALL_OR_NOTHING atomicity message succeeded on some chains but failed on others. Distinct from DIVERGED, which is unintentional inconsistency. 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.
Rollback Message
The OIP message that explicitly reverses a committed state change on chains that already applied it, dispatched when an ALL_OR_NOTHING atomicity operation succeeds on some chains but fails on others. Rollback Messages are themselves dispatched with BEST_EFFORT atomicity, intentionally: if rollback dispatch were ALL_OR_NOTHING, a rollback failure would require a “rollback of the rollback”, leading to unbounded recursion. When a Rollback Message fails to converge across all affected chains within the rollback window, the asset transitions to ROLLBACK_INCOMPLETE and governance resolution takes over.
RoutingContext
The local context held by each OIP routing node, used to make routing decisions. RoutingContext consists of four components: ChainRegistry (supported chains), AssetLocationMap (asset-to-chain mapping), AuthorityRegistry (registered regulatory authorities), and NodeRegistry (OIP node identities). All four are updated through GOVERNANCE messages, ensuring routing-critical state changes are auditable and consensus-driven.
RoutingMetadata
An OIP structure carrying routing information for a message: source, intended targets, intermediate hops, and routing constraints. Used by content-based routing to determine the next destination at each hop.
RoutingMutations
An OIP structure that records the field-level changes a routing stage applied to a message. Captured as a delta on a RoutingSlipEntry: type escalation, priority change, atomicity adjustment, scope expansion or narrowing. Mutations are recorded forward only; earlier entries are never rewritten.
RoutingSlipEntry
One entry in the OIP routing slip. Records the pipeline stage, the deciding node ID, the timestamp, the routing decision, and any RoutingMutations the stage applied. Entries are appended as the message traverses the pipeline, building the audit trail used by downstream stages and external auditors.
Routing Slip
A messaging pattern (originally from Enterprise Integration Patterns) where a message carries its own routing list, visiting each destination in sequence. OIP uses routing slip mechanics for multi-hop operations such as cross-chain regulatory action propagation. Each visited stage adds a RoutingSlipEntry; the slip is append-only, preserving an audit trail of routing decisions.
RWA Registry
The smart contract layer that records asset state on Oraclizer’s L3. The system of record for which assets exist, who owns them, what their regulatory state is, and what their lifecycle position is. Other contracts (protocols using assets as collateral, custodians querying ownership) read from the RWA Registry.
Scheduled Regulatory Action
A regulatory action scheduled to execute at a specific future time or upon a specific condition. Used for time-bounded freezes, automatic releases at the end of a sanction period, or condition-triggered restrictions.
Secondary Finality
The external settlement finality reached through the fflonk → zkVerify → Base L2 path. Secondary finality is what observers outside the OSS see as final settlement on the L2/L1 path. Distinguished from primary finality, which is OSS’s internal source of truth and is established earlier in the synchronization cycle.
SecondaryLockState
An OIP enum representing the secondary, finer-grained lock state of an asset. Five values: PENDING_VERIFICATION, UNDER_REVIEW, AWAITING_CLEARANCE, PROCESSING_TRANSFER, COOLING_DOWN. Used in combination with PrimaryLockState to form the hierarchical lock status.
SEIZE
A regulatory action that transfers operational control of an asset to a designated authority (often the regulator or a court-appointed administrator) without yet transferring legal ownership. The intermediate step in the FREEZE → SEIZE → CONFISCATE escalation chain. The holder’s legal claim remains intact pending the outcome.
Selective Disclosure
The technique of proving a specific property (for example, that a holder is an accredited investor in a particular jurisdiction) without revealing the underlying personal or business-confidential data. Oraclizer applies selective disclosure through zero-knowledge proofs to satisfy the Privacy principle of RCP.
Self-Defense (RWA Registry)
The principle that an RWA Registry contract performs its own authority, state, and proof checks rather than trusting OIP unconditionally. Self-defense ensures that the OIP path and the Force Inclusion path (transactions submitted directly through Base L2 when OIP is unavailable) arrive at the same safety guarantees: a Registry contract running self-defense rejects an invalid transition regardless of which path delivered it.
SignatureType
An OIP enum, added in v0.5, that identifies the signature scheme used in the message header. Two values: SINGLE for a single-sender signature (Ed25519 or ECDSA), and THRESHOLD for a BLS aggregated signature with a signer set and a quorum. SINGLE suits messages from a single trusted node; THRESHOLD provides Byzantine-fault-tolerant origin authentication for messages spanning untrusted relayer sets.
Slashing
The economic penalty applied to staked nodes that violate protocol rules (double-signing, censoring transactions, failing to participate in consensus). Slashed stake is partially burned and partially redirected to the insurance pool.
SSOT (Single Source of Truth)
The architectural principle that a piece of information has exactly one authoritative source, with all other representations derived from it. The RWA Registry serves as the SSOT for asset state on Oraclizer’s L3.
Stage 1 Rollup
A recognized benchmark for rollup decentralization that ensures users retain self-sovereign exit paths even under adverse operator behavior. D-quencer is what gives Oraclizer Stage 1 Rollup security: no single party controls transaction ordering, regulatory action priority is enforced consensually, and the network can survive operator failure without requiring user intervention.
Staking
The mechanism by which network participants lock up OZ tokens as economic security for operating nodes. Stakers earn rewards from protocol fees and risk slashing for protocol violations. Staking can be solo, delegated, or pooled.
STATE_SYNC
One of the seven OIP message types. Carries a state synchronization request: the asset whose state is changing, the proposed new state, the originating domain, and the target domains. The most common message type in normal operation.
State Reconciliation
The process of restoring consistency between domains that have diverged. State reconciliation determines the canonical state, applies necessary corrections to inconsistent domains, and resumes normal synchronization. Introduced in OIP v0.2.
State Synchronization
The process by which an asset’s state is kept consistent across every domain that holds a representation of it. The unit of synchronization is the asset’s full state (ownership, regulatory status, contract terms, lifecycle position, event history), not a single value. State synchronization in Oraclizer is bidirectional and atomic, processed through the BVC cycle.
StateDelta
An OIP structure that represents the difference between two successive states of an asset. Contains the changed field paths, the previous values, and the new values. Used in INCREMENTAL_SYNC messages so that a receiver can verify continuity from a prior state without retransmitting the full asset.
StateSync-GKR
Oraclizer’s synchronization proof generation stack, built on a modular zero-knowledge proof toolkit. StateSync-GKR fits the specific workload of state synchronization: high-frequency, low-latency, sparse Merkle tree verification with deterministic deadlines. Uses the GKR protocol for proof generation and wraps proofs in fflonk for compatibility with the broader verification path.
StateSync-GKR Module 3 Batching
The batching module within StateSync-GKR that aggregates multiple proof generations into a single batched proof, amortizing the fixed overhead and significantly increasing throughput at acceptable latency. Module 3 is one of the four modules that compose the StateSync-GKR proof stack.
Sync Unit
The unit of measurement for billing in Oraclizer. One sync unit corresponds to one completed state synchronization (one full BVC cycle). The cost per sync unit varies by atomicity level, target domain count, and message priority.
SyncType
An OIP enum that identifies the kind of state synchronization carried by a STATE_SYNC message. Three values: INITIAL_SYNC (the first state registration when an Oracle Session opens), INCREMENTAL_SYNC (routine in-session updates with a StateDelta against a prior state), and FULL_RESYNC (full state retransmission after a fork or restart).
TargetScope
An OIP structure specifying the target domains for a message: which chains, which off-chain systems, which specific contracts or accounts. TargetScope works with CrossChainScope to fully describe the destinations of a multi-domain operation.
Three-Group DAG Pipeline
The validation structure introduced in OIP v0.5, replacing the linear five-stage pipeline of earlier OIP drafts. Validation is organized into three groups with distinct cost profiles and failure semantics: Group 1 (Pre-Lock Verification) runs cheap read-only checks (header format, signature, replay defense, address resolution, authority verification, first-pass proof verification) with maximum parallelism, fast-failing before any lock is acquired; Group 2 (State Modification) acquires preemptive locks and applies state transitions sequentially, including the Regulatory Compliance Stage where a STATE_SYNC may be escalated to 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, dramatically improving throughput while preserving every safety property the linear pipeline guaranteed.
Three-Phase Broadcast
The cross-chain coordination pattern OIP uses to deliver state-changing messages across two or more chains: PREPARE probes each target chain for applicability and reserves preemptive locks; COMMIT applies the actual state change on each target; FINALIZE confirms the change and releases coordination locks. Each phase has distinct failure semantics: PREPARE failures are clean (no chain has changed state yet), COMMIT failures may require rollback across chains that already committed, and FINALIZE failures 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 is one phase inside the outer BVC.Commit envelope; the two share the word “commit” but operate at different layers.
Threshold Signature
A BLS-based aggregated signature where a quorum of participants (typically f+1 out of n with up to f Byzantine signers) is required to produce a valid signature. Up to f Byzantine signers cannot forge a valid threshold signature on their own. OIP uses threshold signatures via the THRESHOLD SignatureType for messages whose origin authentication requires Byzantine-fault tolerance, such as cross-chain messages spanning untrusted relayer sets.
Tokenizability
One of the five RCP principles. Requires that an asset’s representation, contract terms, and lifecycle be expressible in the protocol’s data model. An asset whose terms cannot be represented (for example, an instrument with off-protocol contingencies that affect on-chain behavior) is not eligible for synchronization under RCP.
Traceability
One of the five RCP principles. Requires that every state transition be attributable to a verified party with a recorded rationale. Anonymous or unattributed transitions are not admitted. Includes proof of authority for the initiating party and an audit-trail entry that survives the transition’s commit.
TTL (Time-To-Live)
The freshness window of an OIP message. The receiver computes the final TTL as max(sender_ttl, asset_min_ttl): the sender provides a recommended TTL, and the OSS holds an asset-class minimum TTL that acts as a floor. A message whose header.timestamp + final_ttl falls before the current time is rejected with MESSAGE_TTL_EXPIRED; expired messages are not partially processed or forwarded.
TVO (Total Value Oraclized)
An Oraclizer-specific metric measuring the total value of real-world assets actively synchronized through the protocol. TVO counts assets under continuous synchronization, distinguishing it from metrics that count merely deposited liquidity.
Two-Tier Finality
The two-step finality structure OIP uses for cross-chain state synchronization: primary finality is reached at GKR proof issuance inside OSS and is OSS’s source-of-truth for trading authorization; secondary finality is the external settlement reached afterward through fflonk → zkVerify → Base L2. The split lets the protocol commit to a state internally in time to support pre-trading decisions, while the slower external settlement path continues independently. When the two paths disagree, the primary finality record is authoritative. This is the structural reason trading on Oraclizer-tokenized assets does not have to wait for L2/L1 settlement latency.
Unified Message Header
The common header structure attached to every OIP message regardless of type. Contains message ID, timestamp, sender, message type, priority, and routing metadata. The unified header allows OIP to apply common processing (deduplication, ordering, retry) before dispatching to type-specific handlers.
Validium
A rollup configuration that uses zero-knowledge proofs for execution but stores transaction data off-chain, reducing costs and increasing throughput. Oraclizer’s L3 operates in Validium mode by default, with Volition support that lets specific transactions or assets opt into zk-Rollup mode when stronger guarantees are required.
Volition
The capability to switch between Validium mode (data availability outside the chain) and zk-Rollup mode (data on the L1) at the level of individual transactions or assets. Volition lets users choose between cost optimization and stronger data availability guarantees on a per-asset or per-transaction basis.
VRF (Verifiable Random Function)
A cryptographic function that produces a random output along with a proof that the output was generated correctly. D-quencer uses VRF for leader election, ensuring that the next Active Asserter is selected unpredictably and verifiably without requiring trust in any single party.
zk-basis ID
Oraclizer’s identity component. Performs identity verification using zero-knowledge proofs, allowing parties to prove eligibility (residence, accreditation, sanctions clearance) without revealing the underlying personal data. Can leverage external identity infrastructure such as Privado.ID for the underlying primitives.
zkVerify
A proof verification system integrated through Horizen Labs. Oraclizer uses zkVerify to offload zero-knowledge proof verification from Ethereum L1, where verification gas would dominate cost. zkVerify performs batch verification of proofs generated by StateSync-GKR and other sources, making Oraclizer’s cost structure tractable.