OIP v0.5 Checkpoint: Three Discoveries and the Big Map

TL;DR

OIP v0.5 is not a stage for adding new features. It is an integration review stage that establishes coherence across cumulative decisions. Through five rounds of prior research, the message format, core data structures, regulatory actions, address system, and routing protocols were each layered in. v0.5 places that entire stack on one table and looks at it together. It is the first specification to establish coherence through twenty-four decision items across five design areas.

Three moments of discovery shaped the design process. First, the realization that there was no slot in the message header to express threshold signature soundness. Second, the recognition that resolving the self-contradiction in the validation framework required redrawing the classification itself, from axes to criteria. Third, the recognition that BVC’s Commit and the COMMIT in staged coordination are not two conflicting patterns but two concepts nested at different abstraction layers.

The checkpoints unfolded into a big map: eight validation criteria, the 3-Group DAG, the atomicity matrix, primary finality as source of truth, RWA Registry self-defense, and a deterministic error-handling matrix. The coupling relationships across the five areas were also mapped. Open issues were classified honestly and assigned to v0.6 and later on a formalization schedule.

The full publication of OIP v0.5 in the OIP section of docs.oraclizer.io is coming soon. This article previews that release and walks through where v0.5 sits, the discovery moments, the big map, cross-area coupling, and what we left open.

---

Standing on Cumulation: Where OIP v0.5 Sits

OIP was never designed in a single pass. Starting from the first message format draft, then layering in core data structures, the state lock framework, regulatory action specifications, the cross-chain address system, and finally seven message types with the routing protocol, OIP grew one layer at a time. Each stage was complete in itself, but every time a new decision was added, small inconsistencies between it and prior decisions were also accumulating. The new decisions themselves were not flawed. The accumulation of small misalignments along the adjacent edges between areas was the real cost.

The work of OIP v0.5 is not to add new features. It is to lay everything we have defined so far on one table and find where the gaps are, where the contradictions are. To borrow an analogy from construction, this is the stage where, after the framing is complete, the inspector compares the drawings with the actual build and verifies that every joint aligns. It is not the stage of putting up new walls. It is the stage of confirming that the walls already up do not lean against each other in the wrong way.

The review was organized into five areas: the criteria and pipeline of state transition validation, the validation rules in the off-chain (CANTON) segment, the boundary between L3 internals and OIP, the semantics of error handling and recovery, and the version negotiation mechanism. Within each area, decision items were identified, totaling twenty-four decision items. None of these were merely picking an option from a list. While reviewing options, conflicts with prior decisions in other areas surfaced repeatedly, and each time we had to redraw the cross-area coupling relationships. Some single decisions propagated changes across two areas. In other cases, narrowing options in one area automatically constrained the decision space in another.

Figure 1. Specifications accumulated over time without co-review. v0.5 was the first synthesis stage, processing them through 24 decisions across 5 areas to yield the four checkpoint commitments.

The volume of v0.5 grew significantly. While prior specifications defined message types and payload structures, v0.5 adds the formalization of validation criteria and pipeline, responsibility allocation for external system interfaces, the action matrix for error codes, and enforcement of the state transition matrix. The wire format will still be finalized as .proto in v0.6, but every semantic decision that two independent implementations must agree on has been made explicit in v0.5.

There was also a methodological decision in how the work was structured. We chose to lay out the formal verification roadmap alongside the specification review, in parallel. Not the order of finishing the specification first and then starting verification, but checking, with every specification decision, how that decision would later be expressed in the verification work. The validity of this approach surfaces most clearly in the first discovery.

Discovery 1: There Was No Slot in the Header

The most striking first finding was not the integration review itself. It came when we placed the formal verification roadmap next to the OIP specification.

Here is the background. In prior research, we defined the signature: string field in OIPMessageHeader as a single signature. The sending node signs the message with its key, and the receiving side verifies that signature. In a single-sender environment, this was a sufficient design.

But guaranteeing cross-chain message integrity requires more than a single signature in some areas. The four safety properties commonly required by the cross-chain bridge literature are:

• Replay resistance: the same message must not be applied twice.
• Source authentication: the receiving chain must not accept a message without source-chain evidence.
• Dual-chain commit atomicity: either both chains reflect the change consistently, or both roll back.
• Relayer threshold soundness: the signatures of f+1 honest relayers must produce authentication, and a Byzantine subset of f or fewer relayers must not be able to produce a forged authentication.

The first three were already expressed naturally in the specification through v0.4: nonce, source chain ID, and 3-Phase coordination. The problem was the fourth. There was no field in the header to express an f+1 threshold signature.

This gap became visible because we examined two adjacent things at the same time. On one side, the OIP specification’s header structure. On the other side, the input requirements for the formal verification work on cross-chain message integrity. The fact that one slot was missing between them would not have been visible if we had not placed those two items adjacent. It is a byproduct of treating formal verification not as a verification stage to be applied later but as a companion document to the current specification review.

Three options were evaluated for closing the gap. The first was to add a separate relayerSignatures: ThresholdSignature[] field to the header. The second was to extend the meaning of the existing signature field to allow either single or threshold, while introducing a new signatureType enum. The third was to leave only single signatures specified in v0.5 and defer threshold to v0.6 or later.

The second option was adopted. The reasoning falls into three points. First, D-quencer already uses BLS signatures in its consensus mechanism, so the threshold signature infrastructure could be reused at no extra cost. There was no need to introduce a new signature scheme. The first option would have invalidated the existing signature field, breaking compatibility. The second option only extends the meaning, which is friendly to compatibility. Implementations that use only SINGLE signatures can keep their existing behavior, while implementations that want THRESHOLD only need to handle the new branch. Finally, creating the slot in the v0.5 specification means that subsequent formal verification work can cite the specification directly. The starting point for the verification work becomes clean.

Figure 2. The header signature field before and after v0.5: the SINGLE/THRESHOLD branch closes the gap on threshold-signature soundness while preserving compatibility.

The result is that the v0.5 header carries a signatureType: SINGLE | THRESHOLD branch. SINGLE refers to a single Ed25519 or ECDSA signature. THRESHOLD refers to a BLS aggregated signature, accompanied by signerSet and threshold fields. The verification rules are also formalized along the branches. For SINGLE, signature verification with a single key. For THRESHOLD, confirming |signerSet| >= threshold and then verifying that the BLS aggregated signature is valid against the combined public key. v0.5-compatible implementations MUST support SINGLE and SHOULD support THRESHOLD. An implementation that does not support THRESHOLD must reject a THRESHOLD message with a deterministic error.

This discovery illustrates the value of running specification work and formal verification work in parallel rather than sequentially. If verification starts after the specification is complete, the verification stage exposes specification gaps and the specification gets patched after the fact. By that time, the wire format may already be frozen, and changing the header structure becomes expensive. Running specification review and verification-input review in parallel means the gap is closed at the specification stage, and verification can begin from a cleaner starting point. A simple difference in working method changed the entire downstream cost structure.

Discovery 2: From Axes to Criteria

The second discovery was a case where we had to redraw the validation classification itself. At first it looked like a small inconsistency in terminology. On closer inspection, it was a self-contradiction in the classification framework.

In prior research, we drew the validation of STATE_SYNC messages as a sequence of stages: stage 1, stage 2, …, stage 5. Each stage was specified to verify certain things, and validation was assumed to flow from top to bottom in order. The sequential-stage model is itself a common pattern. The problem surfaced when v0.5’s integration review placed the decisions of Area 1 (validation), Area 2 (CANTON Driver), and Area 3 (L3/CDK boundary) on the same table.

There were several validations the sequential model did not adequately express. Where should the verification of CANTON Driver Attestation belong? Signature verification and Driver Attestation verification are essentially the same kind of message integrity verification, but in the stage-based classification they were separated. Header format verification, TTL freshness, and version compatibility were all bundled into stage 1, but their meanings were not homogeneous. Meanwhile, state invariant verification could be checked partially before lock acquisition and had to be checked again after lock acquisition, but in the sequential stages, it could only occupy one position.

To resolve this awkwardness, we first tried increasing the number of stages. Five stages became seven, then nine, then thirteen. At that point, the self-contradiction showed itself. Stage arrangements began to appear in which lighter validations could not be placed before heavier ones. For instance, the specification began to allow flows in which zk proof verification was attempted on a message with a broken header format. The fast-fail principle was breaking down.

Looking back, the issue was not the number of stages. It was the classification dimension. “What is being validated” was not a stage dimension. It was a criterion dimension. A stage is the execution moment in the pipeline. A criterion is the logical classification of the validation rule applied at that execution moment. The same criterion can be distributed across multiple stages, and the same stage can apply multiple criteria in parallel. Forcing both into a single dimension distorts one or the other.

We corrected the term from axes to criteria and redrew the classification framework. OIP v0.5 defines eight validation criteria: message integrity, duplicate/replay prevention, authority verification, precondition verification, state invariant, temporal constraint, proof verification, and cross-chain consistency. Of these, message integrity is not a single check but a composite of seven sub-checks: header format verification, single signature verification, threshold signature verification, source authentication, Driver Attestation verification, TTL freshness, and version compatibility. Without explicitly enumerating the sub-checks, an implementation could omit some of them, so they are documented in a table.

The fact that there are eight criteria is not coincidence but the result of review. There were more candidates. Message size validation turned out to be a wire-format-level decision deferred to v0.6, so it was separated out of OIP scope. Quota and rate limiting sit in the OSS implementation domain and are out of specification scope. Protocol version compatibility was absorbed into message integrity. Timestamp freshness was absorbed in the same direction. Asset existence verification was folded into Address Resolution. The remaining candidates were either out of OIP scope or absorbable into existing criteria, so we judged eight to be sufficiently complete.

This discovery was a recognition about the coherence of classification dimensions. When you draw a system with two dimensions and bundle them into a single word, awkwardness accumulates. The right move is to separate the two dimensions. Once that separation is clean, the classification approaches orthogonality and the sequence approaches the fast-fail principle. It is not just that the expression becomes cleaner. It is that each dimension can finally do its proper job.

The non-orthogonality of the criteria is not fully resolved. If authority verification fails, precondition verification becomes unnecessary. If message integrity fails, all subsequent verifications become meaningless. These dependencies are handled not as orthogonality but as priority relationships, and what implements them is the 3-Group DAG, which connects to the next discovery.

Discovery 3: Two Meanings of “Commit”

The third discovery looked like a terminology conflict at first and resolved into a difference of abstraction layers.

Oraclizer defines the lifecycle of an OSS sync job through the BVC (Bind-Verify-Commit) pattern. In the Bind phase, preemptive locks are acquired across all related domains. In the Verify phase, the validity of the state transition is verified and the GKR proof is generated. In the Commit phase, the change is propagated atomically across all domains. This phasing is one of the thicker bones of our system.

The issue began when we were designing the staged coordination of cross-chain message delivery in v0.5. We introduced the PREPARE → COMMIT → FINALIZE three-phase pattern. The PREPARE phase pre-confirms applicability of the message at all target chains and reserves resources. The COMMIT phase applies the actual state change. The FINALIZE phase confirms the change and signals lock release. The pattern itself is a variant of the classical patterns from the distributed transaction literature (the 2-Phase Commit, 3-Phase Commit family).

A conflict appeared. Both patterns contain the word “Commit.” If BVC.Commit and the COMMIT of PREPARE/COMMIT/FINALIZE referred to the same concept, the two patterns would either duplicate or contradict each other. The initial discussion was whether to redefine BVC or rename the stages of the staged coordination. Both options had cost. BVC is a formal term defined at the thesis level, and PREPARE/COMMIT/FINALIZE follows standard naming from the distributed transaction literature.

The recognition that the abstraction layers were different came one step deeper. BVC is the lifecycle of a single OSS node’s sync job. It is the entire flow from start to end of one sync job, and the unit is the job. PREPARE/COMMIT/FINALIZE is the staged coordination of cross-chain message delivery. It defines how a single message is applied step by step as it reaches multiple chains, and the unit is the message round.

The two units are nested. Inside the BVC.Commit phase of a single sync job, OSS performs the PREPARE/COMMIT/FINALIZE three-phase one or more times. BVC.Commit is the outer container, and PREPARE/COMMIT/FINALIZE is the message round inside it. The two “Commits” share a word, but they are neither at the same point in time nor with the same meaning. BVC.Commit is the final state after all PREPARE/COMMIT/FINALIZE rounds complete. The COMMIT in PREPARE/COMMIT/FINALIZE is an intermediate stage of one round.

Figure 3. BVC.Commit and PREPARE/COMMIT/FINALIZE operate at nested abstraction layers: the outer container holds zero or more inner message rounds.

Once this recognition was clear, the specification became clean. The v0.5 specification defines PREPARE/COMMIT/FINALIZE only as normative content, and BVC is mentioned briefly as non-normative in the OSS Implementation Note, with explicit notes about the difference between the two meanings. BVC’s naming is the formal term defined in our thesis, so it was not changed. The OIP specification’s role is to attach explicit comments where naming collisions could be visible.

This is a small case, but it has implications. When designing systems across multiple abstraction layers, the same word often appears at different layers. If we do not explicitly identify whether the two uses conflict, are equal, or are nested, implementers either confuse them or apply one in place of the other. The role of a specification is more than providing precise definitions. It includes attaching explicit annotations at points where naming collisions could be visible. Preventing wrong integration in advance is just as important as constructing precise definitions.

Two diagrams sketched on a subway. The realization that the two “Commit” concepts were nested rather than colliding came in an ordinary moment.

The Big Map 1: Eight Validation Criteria

As a result of the three discoveries above, OIP v0.5 explicitly defines eight validation criteria. Each criterion is the logical classification of what is being validated, and each is an area to be developed in depth in the follow-up series. Here we lay them out at the big-map level.

(1) Message integrity contains seven sub-checks: header format, single signature (SINGLE), threshold signature (THRESHOLD), source authentication, Driver Attestation, TTL freshness, and version compatibility. As stated in Discovery 1, this criterion is the direct input for subsequent formal verification work, and it is documented as a sub-check table.

(2) Duplicate/replay prevention covers messageId duplication checks, nonce-based idempotency, and attestation transactionId duplication checks. The last item is one more discovery moment. Single-key idempotency on messageId alone does not block the attack of wrapping the same CANTON transaction in two different messageIds and sending both. We identified this during review and added the CANTON Driver’s cantonContext.transactionId duplication check as a sub-check. A new error code (ATTESTATION_REPLAY_DETECTED) was defined alongside.

(3) Authority verification confirms that the sender has the authority to perform the message or action. For ordinary messages, this is a simple sender authority check, but for regulatory actions or CRITICAL priority messages, hierarchical verification through the Authority Hierarchy applies. This area is treated in depth in the follow-up authority-model article.

(4) Precondition verification confirms that the state is in a transition-applicable form. AVAILABLE allows FREEZE, RESTRICTED allows SEIZE, and so on, as a matrix verification.

(5) State invariant confirms that the pre-transition and post-transition states belong to the State Transition Matrix. The matrix itself is defined as the combination of five PrimaryLockState values and six RegulatoryActionType values.

(6) Temporal constraint confirms satisfaction of TemporalConstraint. Asset maturity, appeal deadline (appealDeadline), grace periods, and similar fields are checked.

(7) Proof verification is the cryptographic validity check of zk proofs and Merkle proofs. This criterion has the unique property of being executed twice in the 3-Group DAG: the first pass in Group 1-C, and a staleness re-check in Group 2. The reason is described in the next section.

(8) Cross-chain consistency checks that the message does not contradict CrossChainCoherence.status. The four states (SYNCED, SYNCING, DIVERGED, ROLLBACK_INCOMPLETE) define which transactions are admitted or rejected as a policy check.

These eight criteria are close to mutually orthogonal but not perfectly orthogonal. If authority verification fails, precondition verification becomes meaningless. If message integrity fails, all subsequent verifications become meaningless. These dependencies are resolved through which stage applies which criterion, which is the subject of the next big-map item.

The Big Map 2: The 3-Group DAG and the Recovery of Fast-Fail

Figure 4. The validation pipeline restructured as a 3-Group DAG: Group 1 read-only pre-lock checks (with three sub-stages), Group 2 atomic state modification, and Group 3 partially asynchronous cross-chain effects.

Organizing the criteria is not the end. The decision of when to apply each criterion is a pipeline-level decision, and v0.5 restructured this into a 3-Group DAG.

The prior sequential-stage model carried two self-contradictions. First, arrangements were possible in which a lighter check could not be placed before a heavier one. Second, whether zk proof verification should run before or after lock acquisition was ambiguous. Running it only after acquisition meant holding a lock while waiting for an expensive zk verification, which directly violated the fast-fail principle. Running it only before acquisition missed cases where the proof became stale during the lock-holding window.

The 3-Group DAG resolves both contradictions at once. Group 1 is Pre-Lock Verification: read-only verification that runs before lock acquisition. It is parallelizable and supports fast-fail. Group 1 is further split into three sub-stages. Stage 1-A is light checks (header format, replay, signature, TTL, version), all of which run in parallel. Stage 1-B is Address Resolution (ERC-3770 format parsing, checksum verification, asset existence), which begins after 1-A clears. Stage 1-C is authority and state checks (Authority, Precondition, State Invariant, Temporal, Proof Verification first pass), again in parallel.

Group 2 is State Modification and runs atomically. It is a transactional unit, and on failure, partial changes are rolled back. The steps are Lock Acquisition → Proof Staleness Re-check → State Transition Apply → Regulatory Compliance Stage. The Proof Staleness Re-check was part of the discovery. zk proofs are first-pass verified in Group 1-C, and Group 2 only performs a staleness re-check. The expensive verification finishes before the lock, while the only case caught after the lock is the brief window in which the proof might have become stale. This split satisfies both fast-fail and correctness.

Group 3 is Cross-chain Effects and runs partially asynchronously. Cross-chain Coherence Check → Dispatch (PREPARE/COMMIT/FINALIZE) → Postcondition Verification. Group 3 failures are handled by atomicity-specific policies.

The fast-fail boundaries between groups are defined explicitly. Group 1 failure is immediate rejection: the lock has not yet been acquired, so there is nothing to roll back. Group 2 failure is rollback through Group 2 plus lock release. Group 3 failure is partial or full rollback depending on atomicity level and phase. A postcondition violation observed on a single chain triggers a single-chain rollback through Group 2. The same violation across multiple chains triggers an ALL_OR_NOTHING COMMIT rollback sequence.

The 3-Group DAG applies different subsets depending on the message type. STATE_SYNC traverses the full Group 1+2+3. LOCK_MANAGEMENT traverses Group 1 and Group 2’s Lock Acquisition only (it does not modify state, so the path is shortened). QUERY traverses Group 1 only. ACK and HEARTBEAT terminate after minimal verification (header + signature + response correlation). Per-message-type shortening reduces unnecessary verification cost while applying the same criterion classification consistently.

Message Type	Group 1	Group 2	Group 3	Notes
STATE_SYNC	full (1-A, 1-B, 1-C)	full	full	state-changing; all groups required
LOCK_MANAGEMENT	full (1-A, 1-B, 1-C)	Lock Acquisition only	skipped	no state change beyond lock
QUERY	full (1-A, 1-B, 1-C)	skipped	skipped	read-only
ACK / HEARTBEAT	minimal (header + signature + correlation)	skipped	skipped	minimal verification only

Table 1. Validation pipeline subset applied per message type. The same criterion classification is enforced consistently while unnecessary verification cost is avoided.

The recovery of the fast-fail principle is not just a performance issue. When each verification finishes must be deterministic so that operators can track message progress accurately and so that, on failure, the held resources are clearly bounded. The sequential 13-stage model was losing this determinism, and the 3-Group DAG restores it.

The Big Map 3: Three Atomicity Levels

Figure 5. Atomicity matrix mapping three levels (BEST_EFFORT, GUARANTEED, ALL_OR_NOTHING) against the three coordination phases. CRITICAL priority messages are auto-promoted to ALL_OR_NOTHING with scope forced to ALL_CHAINS.

Cross-chain message delivery behaves differently depending on the atomicity level. v0.5 defines three.

BEST_EFFORT allows partial progress. The PREPARE phase is omitted, COMMIT is sent simultaneously to all targets, and FINALIZE may be replaced by a simple ACK. Partial failure is logged and the message proceeds normally. Applicable cases include HEARTBEAT, ACK, some BEST_EFFORT QUERY messages, and rollback messages themselves. If a rollback message were ALL_OR_NOTHING, infinite recursion would occur (rollback failure triggering rollback of the rollback, and so on), so rollback messages are forced to BEST_EFFORT.

GUARANTEED follows the normal three-phase. PREPARE failure aborts with no resources reserved. Partial COMMIT failure transitions to the DIVERGED state and triggers Reconciliation. FINALIZE failure does not auto-rollback. This decision has explicit reasoning. FINALIZE failure is not “state-change failure” but “confirmation failure.” Reverting an already-committed state on a FINALIZE failure alone carries the larger risk that a temporary network glitch invalidates a valid transaction. Conservative handling is the coherent choice.

ALL_OR_NOTHING uses the same three-phase as GUARANTEED, but with the scope override forced to ALL_CHAINS. PREPARE failure aborts the whole operation immediately. Partial COMMIT failure issues rollback messages to chains that have already committed. The reason ALL_OR_NOTHING’s PREPARE failure is clean is that no chain has yet changed state. No rollback is necessary. Each chain simply discards the PREPARE message and releases the lock.

There is an automatic priority-based promotion rule among the three levels. CRITICAL priority messages are forcibly promoted to ALL_OR_NOTHING, with scope also forced to ALL_CHAINS. Priority maps proportionally to atomicity. This is the OIP-level expression of the RCP principle that regulatory actions must always be applied consistently across all involved chains. Authority to assign CRITICAL is restricted to a separate authority tier, preventing arbitrary senders from forcing ALL_OR_NOTHING.

The Big Map 4: Primary Finality as Source of Truth

In a cross-chain environment, which state is the authoritative state is the heart of dispute. v0.5 organized this under a single principle: primary finality as source of truth.

Primary Finality is the moment of GKR proof issuance. The OSS State Root is established, and the state application of that message is determined deterministically inside OSS. This record is retained permanently and used as the source of truth during Reconciliation. From the trading-effect perspective, trading is allowed from the moment of primary finality (Pre-trading Finality).

Secondary Finality is the moment of external settlement completion through the fflonk → zkVerify → Base L2 path. The externally verifiable proof of primary finality is recorded on Base L2, typically delayed by tens of seconds to several minutes from primary.

Primary/secondary gap handling is formalized as a four-step procedure. First, gap detection is triggered when the syncProgress.lagSeconds field of HEARTBEAT messages exceeds a threshold (default 300 seconds). Second, retry retransmission re-sends incomplete messages from the pending sync queue using messageId-based idempotency. Third, retry before lock expiration attempts retransmission while the lock is still held; after expiration, recovery proceeds through new lock acquisition. Fourth, Reconciliation trigger declares DIVERGED when retransmission failures accumulate and proceeds to forced synchronization based on the primary finality record.

The source-of-truth principle is simple but powerful. If a different state is observed at secondary finality, secondary is treated as wrong and recovery proceeds based on the primary record. This unidirectional priority resolves “which side is right” disputes deterministically.

The Pending Sync Queue Invariants are an OSS implementation matter, but the OIP specification requires four invariants. Deterministic tracking requires that, after primary finality issuance, it must be deterministically traceable which message was applied to which chain. Idempotency preservation requires messageId-based idempotency on retransmission. Long-term preservation of primary finality requires that the primary finality record remain in a verifiable form even after lock expiration or Reconciliation; operational optimizations such as compression, archiving, and Merkle root reduction are permitted on the condition that verifiability is preserved. Source-of-truth use requires that the primary finality record be used during DIVERGED or ROLLBACK_INCOMPLETE resolution.

The exact data structures, algorithms, and retry scheduling of the queue are outside the OIP specification. This is by design. Specifying only the invariants and leaving implementation to OSS gives the specification stability while preserving implementation flexibility.

The Big Map 5: RWA Registry Self-Defense and Path Unification

One of the most interesting integration patterns in OIP v0.5 is RWA Registry self-defense. This decision binds the OIP path and the Force Inclusion path under a single safety guarantee.

The problem setup is this. The gate by which an OIP message gets applied to L3 is the OSS-issued transaction calling the RWA Registry contract. At this point, the handling of msg.sender must be decided. Three options were evaluated. The first was OSS system caller privilege (trust msg.sender alone), but this weakens audit traceability: original-sender information disappears at the contract level. The second was original sender authority delegation (meta-transaction), but this is complex and burdensome on key management. The third was msg.sender = OSS, OIP context passed separately. The third was adopted.

The core of this option is that the RWA Registry contract does not trust OIP and performs its own verification. The RWA Registry has four verification obligations. Caller verification checks msg.sender == OSS_REGISTERED_ADDRESS. Authority verification checks, via Authority Registry lookup, that the OIP-context authority holds the right to perform that action. Primary Finality Record validity checks that the OSS State Root and GKR proof hash are valid. Escalation Chain compliance checks that the action does not violate the FREEZE → SEIZE → CONFISCATE order.

The integration effect that emerges from self-defense is the key point. The OIP path is OIP verification → OSS attaches OIP context and calls → applies if RWA Registry self-defense passes. The Force Inclusion path is CDK direct call → state with OIP verification bypassed → applies if RWA Registry self-defense passes. Both paths must pass the same self-defense gate for state to change, so the safety guarantee is identical regardless of path.

Primary finality on the Force Inclusion path is also recognized conditional on self-defense passing. External propagation (secondary finality) is held back, and the OSS pending sync queue handles it after D-quencer recovery. Because the OIP path and the Force Inclusion path share the same primary finality semantics, the two paths can be managed in a unified way at the operations level.

This decision combines the L2 force-inclusion mechanism with the RWA Registry contract’s self-verification pattern. Either alone is insufficient. Force Inclusion alone allows authority verification to be bypassed. Self-defense alone leaves the user with no escape path when D-quencer consensus halts. The combination simultaneously satisfies decentralization and safety.

The Big Map 6: A Deterministic Error-Handling Matrix

v0.5 defines thirty-six error codes and maps them deterministically to five handling actions: REJECT, RETRY, ROLLBACK, ESCALATE, and DIVERGE.

The determinism of the matrix matters because of interoperability. The same error must trigger the same action across all implementations. Two independent implementations must not interpret the same error differently, and the consistency must be guaranteed at the specification level. The error codes themselves are sufficiently fine-grained that the handling action follows naturally from the code.

Four new error codes were introduced in v0.5: ATTESTATION_REPLAY_DETECTED (CANTON Driver’s transactionId duplication), ROLLBACK_INCOMPLETE_REJECT (rejection of new transactions on rollback-incomplete assets), UNSUPPORTED_VERSION (version compatibility failure), and INVALID_THRESHOLD_SIGNATURE (THRESHOLD signature verification failure). Each is a byproduct of either a discovery moment or formalization work.

DLQ (Dead Letter Queue) recovery is defined as a four-step protocol: notification (impact-scope identification), analysis (error pattern classification), decision (retryability judgment), and recording (decision-rationale storage). DLQ entry is an abnormal case and is an area where human intervention is required rather than an area for automatic processing. The four-step protocol systematizes this. The DLQ automatic-analysis mechanism itself is in the operations-tooling area and is deferred outside v0.5.

Cross-Area Coupling

The reason v0.5’s integration review is meaningful is not that the decisions themselves are individually good, but that the cross-area coupling relationships are coherent. There are several coupling points where one area’s decision depends on, or is changed by, another area’s decision.

Validation criterion (1) message integrity and Area 2 Driver Attestation are directly coupled. One of the seven sub-checks of message integrity is Driver Attestation verification, applied only to messages originating from CANTON. If the responsibility-allocation matrix of the CANTON Driver changes, the sub-check table changes alongside.

Validation criterion (2) duplicate/replay prevention and Area 2 attestation transactionId are coupled in defense against attestation replay attacks. A decision in either area alone cannot block the attack; both areas must define the sub-check together for deterministic blocking.

Area 1 Group 2/3 failure handling and Area 4 atomicity matrix are coupled in determining which handling action a failure triggers. The error code that a Group 2 failed verification raises, and the action that error code maps to, is determined differently depending on the atomicity level.

Area 3 (msg.sender option c) and Area 4 authority error codes are coupled in expressing self-defense verification failures as deterministic errors. Each of the four self-defense obligations carries its own error code.

Area 3 (Force Inclusion) and Area 4 (pending sync queue) are coupled in handling Force Inclusion’s secondary-finality holdback and pending sync queue processing. The Force Inclusion mechanism itself is outside the OIP specification (in the CDK/Base L2 area), but its handling pattern is guaranteed by the combination of OIP self-defense and queue invariants.

Area 4 UNSUPPORTED_VERSION matrix and Area 5 version-rejection mechanism are coupled in the rejection branch of the version-negotiation logic. Area 5 deferred the negotiation logic itself to v0.6, but only the rejection mechanism was kept in v0.5. If what happens when nodes of two different versions meet is not specified, the system becomes non-deterministic.

These coupling relationships secure the coherence of the v0.5 specification. A decision in one area does not contradict decisions in others, and the flow runs naturally from validation criteria to pipeline to external interfaces to error handling to version compatibility. The coupling-relationship graph itself is part of the specification, making it traceable how a change to a single-area decision propagates. This traceability defines the boundary of what can be changed in subsequent specification work.

What We Left Open: The Value of Honesty

v0.5 is not a specification that resolves everything. Explicitly classifying the items left open and recording the resolution timing for each is itself part of the v0.5 work. The list will appear unchanged in the docs.oraclizer.io public version, and the classification framework carries intent.

There are three classes. Deferred means intentionally not handled in v0.5 and assigned to a specific later stage. Pending Definition means the v0.5 specification holds only a skeleton, and detailed formalization is performed in subsequent work. Future Research means additional research or external standards work is required.

Two items remain in the CANTON Driver integration area. Multi-Signatory authority field handling is Pending Definition. v0.5 explicitly supports only a single Signatory, and the multi-Signatory case uses a temporary workaround in which the Driver selects the highest-authority Signatory. Authority priority among multiple Signatories and partial-consent case handling are formalized at v0.6 entry. CANTON Driver key rotation and bootstrap is Future Research. Periodic or breach-driven key rotation procedures, new instance bootstrap, immediate revocation of compromised Drivers, and in-flight message handling during rotation are unformalized. This is Phase 4-5 work and will be formalized alongside the Driver slashing mechanism.

Two items remain in the RWA Registry interface area. RWA Registry Solidity signatures is Deferred. v0.5 defines an abstract skeleton, but the exact Solidity event signatures (indexing topics, event data formats) and function signatures are formalized at v0.6 entry, alongside RWA Registry contract deployment. Authority Registry integration mechanism is Pending Definition. The recommended option (verification proof attached to OIP context) is set, but the exact format of the verification proof (signature? Merkle proof?), stale handling on Authority Registry update, and similar details are v0.6 work items.

Three items remain in the operational mechanism area. Message size limit and fragmentation is Deferred. The problem that a STATE_SYNC message for a large asset portfolio in JSON serialization can grow without bound was identified, but as a wire-format-level decision, it is moved to the v0.6 .proto refinement step. Network propagation mechanism will be covered in a follow-up article on a GossipSub-based design. Dynamic routing-table update mechanism is Deferred. v0.5 defines only an explicit GOVERNANCE-message-based procedure. Automatic node discovery (mDNS, Kademlia DHT, etc.), Gossip-based routing-table propagation, and automatic faulty-node isolation are pushed to the Phase 6 Mainnet Beta time frame.

Three items remain at the operations level. Long-term storage strategy for primary finality is Future Research plus operations. Hot/Cold tiering criteria, compression algorithm determinism, archiving infrastructure suitability (AWS S3 Glacier, IPFS, Arweave, etc.), Merkle-root-reduction timing, distributed-storage quorum, and storage cost prediction models are unformalized. This is treated during the Phase 5 Public Testnet operations experience and Phase 6 Mainnet Beta introduction. DLQ automatic analysis is Deferred to the operations-tooling area. Driver slashing mechanism is Future Research and is formalized in Phase 4-5 alongside D-quencer Staking.

Two items remain on the security side. Quantum-resistant signatures is Future Research and is reviewed after the NIST quantum-resistant standards are finalized, post v1.0. Time-skew attack defense is Pending Definition. v0.5 simply allows 5 seconds of NTP skew. The exact clockSkewTolerance value and time-synchronization verification mechanism are formalized at the Phase 4 D-quencer integration moment.

Exposing these open items unchanged in the public release is an intentional decision. Institutional partners, standards reviewers, and academic readers trust a specification that names its open issues more than one that does not. Recording the location of the gap, the temporary handling, and the resolution timing is a much stronger signal of trust than hiding the gap. Honesty builds trust. Not pretending to be complete, but instead the transparent record of what is open. This principle carries the weight of the specification.

---

What’s Next

Two flows proceed in parallel after v0.5.

First, the full publication of OIP v0.5 in the OIP section of docs.oraclizer.io is coming soon. This is also the moment OIP is registered in docs as the first official public version. Versions v0.1 through v0.4 lived only in research articles; v0.5 becomes the first official public version of the OIP section in docs. The purpose of this article is to preview that release and to lay out the position of v0.5 and the discovery moments first.

Second, the follow-up research series develops the major decisions of v0.5 area by area in depth. The orthogonality and dependencies of the eight validation criteria, the 3-Group DAG and the fast-fail principle, the formal structure of the State Transition Matrix and the Escalation Chain, the meaning split of ROLLBACK_INCOMPLETE and its governance resolution, primary finality as source of truth and the pending-sync-queue invariants, long-term preservation strategy for primary finality, the CANTON Driver option C hybrid model, the L3/CDK boundary and RWA Registry self-defense, Authority Registry integration option comparison, the atomicity matrix and integrated error handling, and signatureType introduction and cross-chain message integrity are the topics ahead. Each article picks one item from this big map and goes deep. The series proceeds in parallel with the docs refinement releases. This article is the entry point; the follow-up articles are the depth axis.

After that, v0.6 entry awaits. v0.6 is not just the work of moving a markdown specification to .proto. It is the stage of formalizing the open items deferred from v0.5. CANTON Driver multi-Signatory and key rotation, RWA Registry Solidity signatures, and Authority Registry integration mechanism are the major work items of v0.6. This proceeds at the same time as Phase 2 OSS Alpha, and the wire format is finalized alongside the initial public release of the oraclizer/oip-spec repository. v0.6 is not only a wire-format change. It is also the formalization stage for v0.5 open issues.

v0.7 and v0.8 are stages that reflect the operational experience of Phase 2 OSS Alpha and the entry into Phase 3 L3 Testnet. v0.9 and v1.0 are separate redesign zones following Phase 5 Public Testnet operational experience. SemVer-standard compatibility rules are strictly applied after v1.0 is reached, so careful decisions matter. These stages depend on operational experience more than on advance design.

---

Closing Thoughts

Looking back after v0.5, the most striking thing was not the discoveries but the working method that made the discoveries findable. If we had not laid the cumulative decisions on one table in a single pass, the missing slot in the header, the nested relationship of the two Commits, and the lack of orthogonality among validation criteria would not have been visible. If we had not laid the formal verification roadmap in parallel with the specification review, the threshold signature gap would have surfaced only at the verification stage, by which time the v0.6 wire format would already have been frozen. A simple difference in working method changed the entire downstream cost structure.

v0.5 is not a perfect specification. There are open items, some of which will be formalized in v0.6, while others wait for Phase 5 operational experience. But v0.5 is the first specification in which every semantic decision that two independent implementations must agree on is made explicit. We have reached the point where two implementations can read the same specification and behave the same way. This is the precondition for entering the implementation stage.

The next stage is the transition to wire format. There we will face a different kind of work: moving semantics into syntax, decisions into field numbers, and cross-area coupling into the type system. We expect that work to proceed in a manner similar to v0.5. More time will be spent moving already-decided things into a coherent form together than inventing new things. And in that work, new discoveries will surface again. Some slot, invisible at the previous stage, will reveal itself.

As explorers, the most interesting question is where to make room for the next discovery.

---

References

1. Cohn, P., & Mainkar, S. (2017). EIP-55: Mixed-case checksum address encoding. Ethereum Improvement Proposals. https://eips.ethereum.org/EIPS/eip-55
2. Williams, S., et al. (2021). ERC-3770: Chain-specific addresses. Ethereum Improvement Proposals. https://eips.ethereum.org/EIPS/eip-3770
3. Roberts, P., et al. (2020). CAIP-2: Blockchain ID specification. Chain Agnostic Improvement Proposals. https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/caip-2.md
4. Bradner, S. (1997). RFC 2119: Key words for use in RFCs to indicate requirement levels. IETF. https://www.rfc-editor.org/rfc/rfc2119
5. Leiba, B. (2017). RFC 8174: Ambiguity of uppercase vs lowercase in RFC 2119 key words. IETF. https://www.rfc-editor.org/rfc/rfc8174
6. Hohpe, G., & Woolf, B. (2003). Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley. https://www.enterpriseintegrationpatterns.com/
7. Kim, J. (2026). Safety and Liveness of Cross-Domain State Preservation under Byzantine Faults: A Mechanized Proof in Isabelle/HOL. arXiv:2604.03844. https://arxiv.org/abs/2604.03844