Validation

OIP v0.5 defines validation as the structured discipline by which a receiving node decides whether an inbound message is authentic, replay-free, authorized, well-typed against current state, and consistent with cross-chain coherence. This page consolidates the eight validation criteria that any conformant implementation MUST apply, the three-group DAG pipeline that organizes them in execution order, and the per-message-type subset that each of the seven message types runs through. It also specifies the Canton Driver Attestation verification protocol, the RWA Registry self-defense obligations enforced at the contract layer, and the CRITICAL priority authority system that gates network-wide coordination upgrades.

Validation is the boundary at which the conceptual guarantees of the previous chapters become enforceable. The data model defines what is structurally well-formed, the message protocol defines what is sent, routing defines what coordination strategy applies, and state management defines what transitions are legal. Validation is what an implementation actually does with each inbound message at every node before any state change is committed. The keywords MUST, SHOULD, and MAY are used as defined in RFC 2119.

---

Scope and Design Goals

OIP v0.5 validation is engineered around three goals that pull in different directions and must be reconciled at every step.

Fast-fail before commitment. Cheap checks (header format, signature, replay) MUST execute before expensive checks (proof verification) and before any lock acquisition. A message that fails the cheapest check should never reach a stage where it consumes a lock or holds up another asset’s processing. This is why v0.5 replaces the linear five-stage pipeline of earlier OIP drafts with a three-group DAG: each group has a distinct cost profile and a distinct failure recovery semantics.

Single source of truth for safety properties. Every validation criterion in this chapter maps to either a formally verified safety property or an explicit security argument. No state change occurs unless every applicable criterion has passed. Implementations MUST NOT skip a criterion as an optimization; the criteria are the safety budget, and the budget is non-negotiable.

Defense in depth across the OIP boundary. OIP messages cross from Canton-side participants, from external chains, and from Force Inclusion paths that bypass OIP entirely. The pipeline is constructed so that even a malformed or malicious caller upstream cannot cause a state change that violates invariants downstream. RWA Registry self-defense verification at the contract layer enforces a second checkpoint that does not trust OIP, and the same set of authority and invariant checks is required regardless of which path the call arrived through.

The remainder of this page specifies how these goals are realized.

---

The Eight Validation Criteria

OIP v0.5 defines eight validation criteria. A criterion describes what is being checked; it does not by itself specify when in the pipeline the check runs. The same criterion may have sub-checks scheduled in different groups of the pipeline. For example, criterion 7 has both a pre-lock cryptographic verification (in Group 1-C) and a post-lock staleness re-check (in Group 2). The eight criteria are listed below; the rest of this page explains how they are scheduled.

Two criteria are aggregates of finer sub-checks that are individually addressable from the error matrix in the error reference page. Criterion 1 (message integrity) and criterion 2 (replay prevention) decompose into the sub-checks below. Sub-checks matter because each sub-check has its own error code and its own failure mode; treating the criterion as a single check would conflate distinct failure conditions in the error response.

Sub-checks of Criterion 1 (Message Integrity)

Signature verification is the most expensive sub-check in this group and dominates Stage 1-A latency on most hardware. Threshold signature verification is heavier than single because it requires aggregating f+1 signatures and checking the aggregate; the message protocol page records why both are supported. Source authentication is distinct from signature verification: it verifies that the cryptographic identity behind the signature is the same identity declared in the routing metadata, not just that the signature is valid for some key.

Sub-checks of Criterion 2 (Replay Prevention)

Three sub-checks because no single key is sufficient. The third sub-check exists because messageId alone does not prevent an adversary from wrapping the same Canton transaction inside two different messageIds and replaying the underlying state effect. The Canton Driver’s cantonContext.transactionId is the canonical identifier for replay defense at the OIP boundary; messageId is the identifier at the OIP message layer. Both MUST be checked, and a duplicate detection on either side rejects the message.

DEDUPLICATION_DETECTED is the only error in this set that is silently ignored rather than returned to the sender. This is intentional: a sender retrying a message it already sent (a normal recovery from a transient network failure) should not see an error, only the same response as the first attempt. The other two sub-checks return errors because they indicate adversarial behavior, not accidental retry.

---

The Three-Group DAG Pipeline

OIP v0.5 organizes the eight criteria into a three-group DAG. Earlier OIP drafts used a linear five-stage pipeline; v0.5 restructures execution to expose parallelism within each group and to localize failure semantics across groups. The three groups have distinct cost, concurrency, and rollback profiles, summarized in the diagram below.

Figure 1: Three-Group DAG Validation Pipeline

Group 1: Pre-Lock Verification

Group 1 contains every check that does not modify state and does not require lock acquisition. Failures in this group do not require rollback because no state has changed. The group is divided into three sub-stages with a partial ordering driven by data dependency: Stage 1-A runs in parallel, Stage 1-B depends on 1-A’s header format check, and Stage 1-C runs in parallel after 1-B.

Stage 1-A runs the cheapest checks in parallel: format and header validation, replay check, signature verification (SINGLE or THRESHOLD), TTL freshness, and version compatibility. These are the safety budget for spam and malformed traffic: the vast majority of malicious or accidentally invalid messages MUST be rejected here, before any lookup against RWA Registry or any cryptographic verification of proofs.

A subtle but important constraint applies to deduplication. The cache write for messageId deduplication MUST occur only after signature verification passes, although the cache read can run in parallel with other Stage 1-A checks. Writing an unverified messageId into the cache exposes the system to a cache poisoning attack via signature forgery: an attacker observes a valid messageId in flight, then forges a message with the same messageId and an invalid signature. If that forgery were cached, the legitimate message would later be rejected as a duplicate. Implementations MUST enforce this ordering.

Stage 1-B performs Address Resolution. The work involves parsing the shortName:0xAddress format declared in the data model page, resolving short names against the chain registry, validating EIP-55 checksums, and confirming asset existence by lookup in the RWA Registry. Stage 1-B depends on Stage 1-A because address parsing is meaningful only when the header format is valid; both stages remain read-only.

Stage 1-C runs in parallel: authority verification, precondition check, static state invariant check, temporal constraint check, and a first-pass zk proof verification. The first-pass proof verification is moved to Group 1 deliberately. Deferring zk verification until after lock acquisition would mean holding a lock through an expensive cryptographic check, violating fast-fail. Group 2 only re-checks proof staleness against the most recent state root; the cryptographic validity is already established here, in Group 1-C.

Group 1 failure handling is uniform: immediate rejection, no rollback target. The error code from the error matrix in the error reference page is returned to the sender.

Group 2: State Modification

Group 2 acquires locks and applies state transitions. Each stage runs sequentially within a single transactional unit. Failure at any stage rolls back partial changes and releases the lock. The four stages are summarized below.

The Regulatory Compliance Stage is where dynamic escalation can occur. If, during processing of a STATE_SYNC message, a regulatory pattern is detected (for example, a structuring pattern under AML rules), the message MAY be escalated to REGULATORY_ACTION. The escalation is recorded in the message’s Routing Slip with typeChanged, priorityChanged, atomicityChanged, and scopeExpanded fields, preserving an append-only audit trail across the transition.

The Regulatory Compliance Stage is what makes Group 2 more than a simple state machine: every state-changing message in OIP can, in principle, trigger an authority-level intervention without leaving the pipeline. The same escalation cannot be retroactively undone; it becomes a fact recorded in the slip and forwarded to subsequent processors.

Group 3: Cross-chain Effects

Group 3 propagates the committed local change to other chains and verifies postconditions. Stages here can be partially asynchronous, but a postcondition violation MUST trigger a rollback that unwinds Group 2’s state change as well.

The automatic rollback sequence for postcondition violation depends on scope. Single-chain postcondition violation triggers a single rollback that unwinds Group 2 and releases the lock. Multi-chain postcondition violation under ALL_OR_NOTHING triggers the COMMIT rollback sequence: every chain that received a COMMIT MUST be instructed to revert. If any chain fails to acknowledge the rollback, the asset enters ROLLBACK_INCOMPLETE and governance intervention becomes the recovery path. The state management page provides the full coherence and ROLLBACK_INCOMPLETE semantics.

---

Per-Message-Type Pipeline

Each of the seven message types defined in the message protocol page traverses a distinct subset of the three-group DAG. The full pipeline is required only for messages that change asset state with cross-chain effect; lighter messages run a corresponding subset. The matrix below records the coverage; the notes after the table elaborate on the exceptions.

REGULATORY_ACTION runs the full pipeline with two additions in Group 1-C. The first is an extended authority verification under the RegulatoryContext hierarchy. The second is Legal Basis Verification: the legal documentation referenced by the action MUST be valid, the appealDeadline MUST be set correctly per the action type, and any document expiry MUST be within tolerance. CRITICAL-priority regulatory actions additionally require the Authority Hierarchy and scope check defined in the CRITICAL Priority Authority section below.

LOCK_MANAGEMENT runs Group 1 in full but Group 2 only as far as Lock Acquisition. There is no state transition to apply because the lock message itself is not a state change. The exception is LOCK_ESCALATE, which carries an implicit transition (for example, RESTRICTED → SEIZED); in that case the full Group 2 and Group 3 apply.

QUERY runs Group 1 only, then enters a separate read-only pipeline of Permission Check → State Retrieval → Response. No lock is acquired and no state changes, which is why Group 2 and Group 3 do not apply.

ACK and HEARTBEAT use a minimal validation path. ACK does not trigger another ACK, breaking any potential ack-amplification. HEARTBEAT loss is tolerated with zero retries; the signal it carries is liveness, not state, so a missed heartbeat is just one fewer data point in the next aggregation interval.

GOVERNANCE has three subtypes that map to different pipeline coverage. PROPOSAL runs Group 1 plus a Proposal Validation step before storage. VOTE runs Group 1 plus voter authority verification and vote aggregation. EXECUTE runs Group 1 plus Group 2 and Group 3, but the lock and state transition apply to governance objects (routing tables, Authority Registry entries, protocol parameters), not to assets. The Group 2 Lock Acquisition is on the governance object; the State Transition Apply concerns the governance object’s lifecycle, distinct from the PrimaryLockState matrix in the state management page. Group 3 Cross-chain Effects apply only when the changed governance object must propagate to other domains.

---

Canton Driver Attestation Verification

Messages that originate from the Canton domain enter OIP wrapped in a Driver Attestation. The attestation is a structured claim by the Canton Driver about what was observed on the Canton ledger, signed by the Driver’s registered key. OIP’s validation pipeline does not re-verify Canton-side checks; it verifies the attestation itself. The diagram below summarizes the flow and the responsibility boundary.

Figure 2: Canton Driver Attestation Verification Flow

Driver Attestation Schema

The Canton Driver Attestation has the following structure. The schema is the contract between the Canton Driver and OIP; both sides MUST agree on field names, semantics, and serialization.

interface CantonDriverAttestation {
  driverId: string;                       // Driver instance identifier
  driverVersion: string;

  cantonContext: {
    ledgerOffset: string;                 // Canton Ledger offset
    transactionId: string;                // Canton Transaction ID (replay key)
    workflowId?: string;
  };

  verifiedClaims: {
    partyAuthorization: boolean;          // DAML signatory authority confirmed
    contractActive: boolean;              // Contract is ACTIVE
    observerScope: string[];              // Message disclosure scope
  };

  partyMapping: {
    cantonPartyId: string;                // e.g., "Alice::1220abc..."
    mappedOCID: string;                   // OIP-side OCID
    mappingProof: string;                 // Mapping proof (signature)
  };

  driverSignature: string;                // Signed with Driver key
  timestamp: string;                      // ISO 8601
}

The verifiedClaims field is what OIP trusts after the four sub-checks below pass. The cantonContext.transactionId field is the canonical replay-defense key at the OIP boundary. The partyMapping field connects the Canton-side identity (cantonPartyId) to the OIP-side identity (mappedOCID) and is itself protected by mappingProof, a signature over the mapping that the Driver issues.

OIP-side Verification Checks

OIP’s validation responsibilities for a Canton-originated message are narrowly scoped. The pipeline performs four distinct checks; any failure rejects the message.

1. Driver signature: driverSignature MUST be produced by a Driver key registered in the Authority Registry. Failure returns DRIVER_NOT_REGISTERED or INVALID_DRIVER_ATTESTATION.
2. Timestamp freshness: attestation.timestamp MUST be fresh under the TTL policy. Failure returns MESSAGE_TTL_EXPIRED.
3. Party mapping proof: partyMapping.mappingProof MUST be consistent with the claimed mappedOCID. Failure returns PARTY_OCID_MAPPING_INVALID.
4. Canton transaction replay: cantonContext.transactionId MUST NOT have been seen before. Failure returns ATTESTATION_REPLAY_DETECTED.

Once these four checks pass, OIP trusts the verifiedClaims payload and does not re-verify Canton-side facts. This is by design: re-verifying Canton-side claims would require OIP to maintain a parallel implementation of DAML semantics, which would be both expensive and a divergence risk between OIP and Canton.

Division of Labor

The Canton Driver, in its own domain, retains full responsibility for DAML signatory and observer authority, Canton Party identity verification, Canton Ledger signature verification, need-to-know privacy enforcement, and the bidirectional Party-ID-to-OCID mapping. This division of labor is what makes the Driver Attestation a meaningful authentication primitive: it is a signed claim by an entity that is itself accountable for the correctness of those claims, with separate slashing and governance mechanisms when accountability is breached.

Driver registration in v0.5 uses a trusted whitelist managed via D-quencer governance. New Drivers are registered through GOVERNANCE messages and must pass community review before their signatures are accepted. Driver slashing (the mechanism by which a Driver loses stake for a falsified attestation) is deferred to Phase 4–5; the open issues page records this explicitly. Until slashing is in place, governance retains the right to deregister a Driver immediately on evidence of misbehavior.

---

RWA Registry Self-Defense

OIP messages eventually trigger calls into RWA Registry contracts to apply state changes on chain. The RWA Registry contract MUST NOT trust OIP. It performs self-defense verification that re-checks authority and invariants against its own state. This is what makes the OIP path and the Force Inclusion path equivalently safe: even if a malicious actor bypasses OIP entirely, the contract still enforces the same set of safety properties.

Figure 3: RWA Registry Self-Defense as a Common Gate

Self-Defense Checks

The interface skeleton below records the contract-side check structure. Final form will be defined when RWA Registry is deployed in Phase 3; the open issues page tracks the integration details.

// Interface skeleton. Final form will be defined when RWA Registry is
// deployed in Phase 3. See Open Issues for the integration details.

struct OIPContext {
    bytes32 messageId;
    string sourceChainId;
    AuthorityClaim authority;
    bytes routingSlip;
    PrimaryFinalityProof primaryFinalityRecord;
}

interface IRWARegistrySelfDefense {
    function applyOIPDispatch(
        bytes calldata functionData,
        OIPContext calldata oipContext
    ) external;
}

The contract MUST perform four independent checks on every dispatch:

1. Caller identity: msg.sender MUST equal the registered OSS address. Calls from any other origin MUST be rejected.
2. Authority verification: oipContext.authority MUST hold the right to perform the requested action, verified against the Authority Registry. The recommended verification path is for OSS to attach the authority’s verification proof to oipContext.authority, allowing the RWA Registry to verify the proof in the contract without an external call. This option pairs naturally with the self-defense principle and reduces gas cost. The exact integration is specified in the RWA Registry Open Issue.
3. Primary Finality Record validity: oipContext.primaryFinalityRecord MUST contain a valid OSS State Root and zk proof hash. This anchors the dispatch to the first-stage finality issued by OSS.
4. Escalation Chain compliance: the requested action MUST NOT violate the FREEZE → SEIZE → CONFISCATE escalation order. A SEIZE on an asset that has not been frozen is rejected here just as it would be rejected by OIP validation upstream.

OIP Dispatch Context

The OIP path supplies a fully populated oipContext; the dispatch context is passed alongside the function arguments. The structure below records the full payload OSS sends to RWA Registry.

interface OIPDispatchCall {
  // Function arguments specific to the RWA Registry method
  functionName: string;
  functionArgs: unknown[];

  // OIP context carried alongside
  oipContext: {
    messageId: string;
    sourceChainId: string;
    authority: AuthorityClaim;
    routingSlip: RoutingSlipEntry[];
    primaryFinalityRecord: PrimaryFinalityProof;
  };
}

The msg.sender = OSS, context separately pattern was chosen against two alternatives. Granting OSS a system-caller privilege would weaken audit traceability because the original requester is invisible. Using meta-transactions to forward the original sender’s authority would add key-management complexity without adding safety. The current pattern preserves auditability, anchors first-stage finality to the OSS state root, and aligns the OIP and Force Inclusion paths under a single contract-side check.

Force Inclusion Path Equivalence

The Force Inclusion path supplies only what the user provided. The RWA Registry treats it identically to the OIP path: a dispatch that fails any of the four checks is rejected. Force Inclusion’s first-stage finality is recognized only when self-defense passes; the second-stage finality (cross-chain propagation) is deferred until D-quencer recovers and processes the entry from the OSS pending sync queue. Pending sync queue invariants are specified in the state management page.

The equivalence is architecturally important. Without it, a Force Inclusion path would be a backdoor that could be exploited to bypass authority checks. Because the contract performs the same set of checks regardless of the entry path, the safety budget is preserved end-to-end: any path that reaches the contract is subject to the same gate.

---

CRITICAL Priority Authority

CRITICAL priority triggers automatic upgrade to ALL_OR_NOTHING atomicity and ALL_CHAINS scope, as described in the routing page. Because this upgrade affects every chain in the network, the right to grant CRITICAL priority MUST be tightly constrained. OIP v0.5 enforces this through a four-level Authority Hierarchy combined with scope restrictions. The diagram below summarizes the levels and what each level may grant.

Figure 4: Authority Hierarchy with CRITICAL Grant Scope

Authority Hierarchy

The hierarchy mirrors the regulatory authority landscape in the real world. Global bodies at Level 1 have unrestricted CRITICAL grant scope. National regulators at Level 2 may grant CRITICAL only within their national jurisdiction. Industry self-regulatory bodies at Level 3 may grant CRITICAL only on assets explicitly registered with them. Exchange-level self-regulatory authorities at Level 4 may not grant CRITICAL at all; the maximum priority they may declare is REGULATORY.

The scope restriction is what prevents lower-level authorities from issuing rollbacks that would invert the hierarchy. A national regulator cannot issue a CRITICAL action on assets outside its jurisdiction; an industry body cannot issue CRITICAL on unregistered assets. The four-level structure is also aligned with the rollback hierarchy soundness work in the formal verification track, which proves that the hierarchy is preserved across rollback chains.

Five-Step Verification

When a node receives a CRITICAL message, the Group 1-C authority verification MUST run a five-step check:

1. Confirm header.routing.priority == CRITICAL.
2. Resolve payload.authority.authorityId against the Authority Registry.
3. Read the registered hierarchy level (1, 2, 3, or 4).
4. Verify that targetScope.targetChains is a subset of the authority’s permitted chains and targetScope.targetAssets is a subset of permitted assets.
5. Reject with CRITICAL_PRIORITY_NOT_AUTHORIZED on any mismatch.

Authority Registry entries are managed through GOVERNANCE messages, specifically the AUTHORITY_REGISTRATION subtype. Each registration records the level, the scope restrictions, and the verification keys, and any change requires a governance vote. The registry is itself a versioned object; changes are append-only and indexed by registration epoch, so the verification step always reads against a deterministic snapshot.

Operational Defenses

Beyond the protocol-level checks above, operational defenses against malicious CRITICAL grants sit outside the OIP specification but are made auditable by the Routing Slip data that OIP guarantees. Common operational practices include the following.

• Anomaly detection on grant frequency. A registered authority that suddenly issues CRITICAL grants at an unusual rate triggers governance review.
• Governance-level intervention. Governance can deregister an authority on evidence of misuse, taking effect at the next epoch.
• Slashing, when economic stake is bound to the authority. Phase 4–5 timing; Open Issues records the design status.

These defenses are deliberately outside the validation pipeline. Validation rejects malformed or unauthorized CRITICAL messages immediately; operational defenses address slow-burn abuse where every individual message is technically valid but the aggregate pattern is suspect. The two work together because the validation pipeline cannot reason about long-term behavior, only about individual messages in isolation.

---

Implementation Notes

A few engineering points are worth flagging for implementors building OIP nodes against this specification.

Group 1-A parallelism is real, not aspirational. Format checks, signature verification, replay reads, and TTL checks have no data dependency on each other and SHOULD run concurrently. The cache-write ordering for messageId is the only synchronization point. On modest hardware, well-optimized Stage 1-A throughput is typically signature-bound; threshold signature verification is more expensive than single, which is one reason the message protocol allows both.

Group 1-C parallelism includes proof verification. The first-pass zk verification can run concurrently with authority and precondition checks because it does not depend on them. This is a deliberate departure from earlier OIP drafts that placed proof verification in the post-lock stage; the change matters because proof verification is the most expensive single check, and holding a lock through it would cripple throughput under load.

Group 2 is a transaction boundary, not a code block. Implementations are free to use any concurrency strategy as long as the four stages have transactional semantics. Common patterns include a single critical section per asset or a per-asset actor model. What matters is that a Group 2 failure unwinds every effect produced inside it before returning.

Group 3 dispatch is inherently asynchronous, but postcondition verification is not. A common implementation mistake is to treat postcondition verification as a best-effort background check. Under ALL_OR_NOTHING it is a blocking check: the message is not considered complete until postconditions on every target chain are confirmed, and a failure here triggers the COMMIT rollback sequence rather than a quiet log entry.

The dedup cache is durable, not in-memory. A node that crashes and rebuilds its dedup cache from scratch effectively allows replay attacks against any messages it had already processed. Implementations SHOULD persist the dedup cache and restore it on restart, with a TTL window matched to the longest expected message TTL plus a safety margin.

Authority Registry reads should be cached carefully. Group 1-C reads the Authority Registry on every CRITICAL message. Caching is desirable for latency, but the cache MUST invalidate on the GOVERNANCE message that changes the registry. A simple approach is to key the cache by registration epoch and treat any epoch change as a full invalidation.

---

Related Pages

• Data Model defines OIPAddress, HierarchicalLockStatus, RegulatoryContext, CrossChainCoherence, and the type system that validation operates on.
• Message Protocol defines the seven message types and the signatureType enum referenced by criterion 1.
• Routing covers Atomicity-Driven Coordination and the priority upgrade rules that CRITICAL messages trigger.
• State Management defines the State Transition Matrix that criterion 5 enforces, the Preemptive Lock Protocol that Group 2 uses, and the ROLLBACK_INCOMPLETE recovery semantics.
• Regulatory Actions details parameter structures for each of the six regulatory actions, including appealDeadline referenced by Legal Basis Verification.
• Cross-chain Protocol details PREPARE, COMMIT, and FINALIZE for staged execution in Group 3.
• Error Reference enumerates the error matrix referenced throughout this page.
• Conformance aggregates the MUST/SHOULD/MAY requirements that validation implementations must satisfy.
• Open Issues records v0.5 deferred items referenced from this page (RWA Registry self-defense interface, Driver slashing, CRITICAL anomaly detection thresholds).

---

References

• RFC 2119: Key words for use in RFCs to Indicate Requirement Levels
• ERC-3770: Chain-specific addresses
• EIP-55: Mixed-case checksum address encoding
• CAIP-2: Blockchain ID Specification