Regulatory Compliance
Tokenized real-world assets exist under financial regulation. Regulatory compliance is not an application-layer concern in Oraclizer; it is built into the synchronization protocol itself. This page introduces the Regulatory Compliance Protocol (RCP), the five principles that define what compliance means at the protocol layer, and the six regulatory actions that the protocol guarantees can be executed atomically across every domain where an asset exists.
Why compliance is a precondition
Most blockchain systems treat regulatory compliance as a feature added after the fact. KYC checks live in a frontend gate, freeze logic lives in a token contract’s modifier, audit trails live in an off-chain database. Each of these is bolted on at the application layer, and each can be bypassed, forgotten, or implemented inconsistently across deployments.
For real-world assets, this approach does not survive contact with actual financial regulation. An asset issued under existing financial law is subject to enforcement at every stage: issuance, trading, custody, and settlement. A regulator who issues a freeze order on a tokenized bond expects the freeze to take effect on every chain where the bond exists, in every protocol that holds it as collateral, and in every off-chain ledger that records its ownership. If the freeze is enforced only on the originating chain, the asset has functionally not been frozen.
This is the structural argument for embedding compliance in the protocol. Without protocol-level compliance, cross-domain interoperability is not actually achieved. Two domains can hold the same asset and call themselves synchronized, but if a regulatory action on one domain does not propagate atomically to the other, the asset’s regulatory state has diverged. The asset is no longer a single instrument; it is two copies under different rules. This breaks both the legal coherence of the asset and the consistency guarantee that state synchronization is supposed to provide.
Oraclizer addresses this by adopting the Regulatory Compliance Protocol as a design principle. RCP systematizes the requirements drawn from fifteen global financial regulators into thirty-one core requirements, organized as a protocol where regulatory enforcement is part of the same atomic cycle that performs state synchronization. Compliance is not a layer above the protocol. It is a constraint inside it.
The five principles
RCP defines five principles that together specify what regulatory compliance must look like at the protocol layer. Each principle answers a different question that financial regulation poses to a tokenized asset, and each maps to concrete mechanisms in the Oraclizer architecture.
Traceability. Every state change to an asset must be attributable to identified parties under defined authorities. Regulators require an audit trail that links transactions to verified identities, not pseudonymous addresses. Oraclizer realizes this through identity primitives that bind transactions to regulated identities while preserving privacy where the law allows it. Traceability is what makes anti-money-laundering and counter-terrorist-financing requirements operational at the protocol level rather than at a frontend layer that can be bypassed.
Privacy. Regulatory compliance does not require all transaction details to be public. It requires the right parties to see the right information at the right time. A regulator must be able to audit, but a competitor must not be able to derive trading positions. A counterparty must be able to verify eligibility, but a counterparty’s address book must not become public knowledge. Privacy in RCP is selective disclosure, not blanket secrecy or blanket transparency.
Enforceability. When a regulator orders an action on an asset, that action must execute. It is not enough for the protocol to log the order or to delegate execution to a contract that may or may not enforce it. Enforceability requires the protocol itself to make regulatory actions binding across every domain where the asset exists, atomically and irrevocably (within the limits set by the action’s own legal scope). The six regulatory actions described below are how RCP operationalizes this principle.
Finality. Financial systems require knowing when a state change is final. Settlement finality, in regulated finance, is a precise concept: it is the point after which a transaction cannot be reversed except by a defined process under defined authority. RCP’s finality principle gives state synchronizations the same property. A committed state change is final under the protocol, and reversal is possible only through governance procedures or regulatory rollback under explicit authority. This is what allows tokenized assets to participate in regulated settlement infrastructure rather than only in speculative trading.
Tokenizability. Not every asset can be represented as a token under existing financial law without losing its legal character. A regulated bond is not a generic ERC-20 with a different name; it has a maturity date, a coupon schedule, an issuer, transfer restrictions, and a regulatory class. Tokenizability is the requirement that a tokenized representation preserves the legal properties of the underlying asset rather than abstracting them away. RCP defines what an asset’s representation must include for it to be tokenizable in a way that financial law recognizes.
Figure 1: The five principles of the Regulatory Compliance Protocol
The six regulatory actions
Enforceability, the third principle, is operationalized through six regulatory actions defined at the protocol level. Each action corresponds to a distinct legal effect that financial regulators routinely impose on assets, and each is executed by Oraclizer as a state transition that is atomically applied across every domain where the asset exists.
The actions are not labels for off-chain processes. They are state transitions with defined preconditions, postconditions, and authority requirements. The protocol guarantees that an authorized action, once initiated, propagates atomically or rolls back entirely.
FREEZE places an asset in a temporarily restricted state. The asset cannot be transferred or used as collateral while frozen. The action is reversible: a subsequent unfreeze restores the asset’s previous state. FREEZE is the lightest enforcement action and is typically the first response to suspected violations under investigation.
SEIZE transfers control of an asset to a designated controller, typically under court order. The original owner loses operational control, but legal ownership is not yet transferred. SEIZE is reversible if the underlying legal action is dismissed, but during the seized state the controller exercises the asset’s rights.
CONFISCATE transfers legal ownership of the asset to a designated recipient (typically a treasury or court-appointed entity), permanently. This is a terminal action: the original owner’s claim is extinguished, and the asset cannot return to that owner without a new transfer. CONFISCATE is the final stage of the escalation chain that begins with FREEZE.
LIQUIDATE forces the asset to be converted into a settlement currency (typically through an integrated venue) and the proceeds distributed to a defined beneficiary. LIQUIDATE is used when the regulatory objective is monetary recovery rather than asset retention, for example to satisfy outstanding debt obligations.
RESTRICT applies conditional limits on the asset’s transferability without freezing it entirely. The asset can still be traded, but only under conditions specified by the restriction (eligible counterparties, eligible venues, transfer size limits). RESTRICT is used when full freezing is disproportionate but unrestricted trading is not acceptable.
RECOVER returns an asset to its original owner after wrongful transfer (theft, fraud, error). The action effectively reverses the wrongful transfer and reinstates the original ownership state. RECOVER requires the same authority as the actions it reverses and operates within statutory limits.
The escalation chain
Three of the six actions form an escalation chain: FREEZE can escalate to SEIZE, and SEIZE can escalate to CONFISCATE. The chain is one-directional. An asset can move forward through the chain but cannot arbitrarily return to a less restrictive state without an explicit reversal under proper authority.
The escalation chain reflects how financial enforcement actually works. A freeze is imposed during investigation. If the investigation finds grounds for action, the asset is seized and a controller takes operational custody. If the legal process concludes against the original owner, the asset is confiscated and ownership transfers permanently. Each escalation requires distinct authority, and the protocol enforces these authority requirements as preconditions on the state transition.
The other three actions (LIQUIDATE, RESTRICT, RECOVER) are not part of the escalation chain. They serve different regulatory objectives and operate independently, with their own authority requirements and reversal rules.
Figure 2: The six regulatory actions and the escalation chain
Compliance and synchronization, together
The five principles and six actions are not separate features added on top of state synchronization. They are the rules that constrain what a valid state transition is. A synchronization that violates a regulatory constraint is not synchronization that succeeded with caveats; it is synchronization that the protocol rejects. Conversely, a regulatory action is not a separate transaction that runs alongside synchronization; it is a state transition that goes through the same Bind-Verify-Commit cycle and propagates atomically across the same domains.
This is what makes Oraclizer’s compliance model qualitatively different from compliance-as-feature designs. Regulatory enforcement is not something the application layer remembers to do correctly. It is a property the protocol guarantees, on every domain, in every cycle, under the same atomicity rules that apply to state itself.
The next page describes the three-layer architecture that implements these principles, including the components that perform identity verification, lock management, regulatory action execution, and cross-domain propagation. System Architecture shows how the conceptual structure introduced here maps to concrete components.