1. This document is not submitted while any placeholder-marked item in or in is unresolved. No such item is open. The last one, deployment availability, is resolved not by settling the question universally but by replacing an unmeasured assumption with a measurement whose scope is stated in full: now reports what was measured on 2026-08-14, and names the three things that measurement does not establish — including that it never exercised a funded settlement. Exactly one unresolved item remains anywhere in this document — the registry request awaiting working-group direction in — and this condition does not cover it.
2. No claimed defence is submitted without a conformance vector that enforces it. A stated requirement on an unimplemented interface is a request, not a control, until a conformance vector enforces it. The corpus that enforces the checks in is the Copenhagen vectors, the cross-language conformance corpus published with the reference implementation; names its location and its contents.

• D1 — the derivation inputs are the mandate's, never the artifact's. chainId, token and payer MUST be taken from the Parameter Pre-image after it has been verified against the Parameter Commitment, and from nowhere else — never from the artifact's own reported coordinates, and never from the Authorization Record's chain identifier, which names a record chain and not a ledger. A verifier that lifts them from the artifact accepts a uniformly self-consistent testnet settlement as a mainnet one, because it has compared attacker-chosen values against an event whose location the attacker chose.
• D2 — the seed is the grant's nonce, and there is no seed member. The signed, single-use Execution Grant is the pre-dispatch seed commitment: one grant yields exactly one derivable Correlation Value, and that singularity is a property of the derivation rather than a rule an implementation is asked to keep. The artifact MUST NOT carry the seed and MUST NOT carry a seed commitment; a value the verifier is handed is a value an attacker can choose.
• D3 — a short seed is a refusal, never a padding. The seed MUST be at least 32 octets and a derivation given fewer MUST fail rather than pad. A short seed is the one input whose weakness is invisible in the output: the value still looks like 32 random octets while being searchable.
• D4 — the width is set by the derivation, not by the digest. SHA-256 output is exactly the 32 octets the identifier field takes, with no truncation or padding step to get wrong.
• D5 — the Relying Party recomputes; it never accepts. The artifact carries the Correlation Value so that a reader can see it, not so that a verifier can use it: the verifier derives the value from the bundle's own documents and compares byte-exactly, lowercased, against both the artifact's member and the ledger event's identifier topic. Item 6 of states this mechanically.
• D6 — the one-stage form MUST be refused, not normalized. A correlation member carrying the Action Digest's sha256: string form is structurally invalid under this document. A verifier that accepts it and re-encodes it has accepted the construction this one replaced.

• tenant and chain are reject-only. Both are compared against the verifier's own expected values and are never lifted from the bundle. chain names a record chain, not a ledger, and is never a derivation input (D1 of ).
• The two reference hashes use two different rules, and they must not be interchanged. authorizationReceiptHash is the receipt-reference rule: sha256: over the canonical bytes of the record without its own chain hash and without its signature value — which is exactly the record's own committed chain hash. executionGrantHash is the side-artifact rule: sha256: over the canonical bytes of the whole signed grant, signature included.
• correlation is recomputed, never accepted (item 6 of ). A value written in the Action Digest's sha256: string form is a structural refusal (D6), and uppercase hex is a refusal rather than something to normalize. There is deliberately no actionDigest member and no seed member: the digest is a derivation input the verifier reconstructs, and the seed is the grant's.
• railFamily fails closed. It is the Observer's reported family, checked against the closed set the verifier ships; an unknown family MUST refuse, because different rails bind the identifier with different strength. It is not a derivation input.
• chainWitness carries the reported ledger facts — nine always-present members, the last five nullable. network and asset carry the chain and token coordinates; payee and amount are the recipient and the value. They are nullable on the wire, but a SETTLED status forbids payee or amount being null, because without them cannot bound the recipient or the amount. amount is a decimal string, never a JSON number — canonical-JSON hardening () rejects non-safe integers and uint256 exceeds them, so a numeric amount would make ordinary payments uncanonicalizable. status has three values, never two: we did not look and we looked and saw nothing yet are different statements — and there is deliberately no FAILED, because a ledger can witness a non-consumption-so-far, never a failure. Every one of these fields is reject-only: they are compared against the verified Parameter Pre-image and can only ever cause a refusal. An implementation that derives from them has replaced the mandate's commitment with the artifact's self-declaration — see . A confirmation count is deliberately absent: it would be the Observer's count of a moving quantity, and item 9 of requires the Relying Party to compute depth against its own head.
• railReceipt is structurally non-load-bearing. No verifier validates its signature, parses it for a load-bearing fact, or lets its presence, absence, content or format move any verdict. See on counterparty evidence.
• observedAt is the instant the Observer looked; a NOT_SETTLED conclusion is time-qualified against it (). observerKid and sig are covered by — the signature is not the evidence.

• validate the artifact against its own schema — root and every nested object closed (additionalProperties:false), every required member present, correlation lowercase 0x + 64 hex, chainWitness well-formed. A member the schema does not define is a refusal, not a tolerance;
• verify the Observer's Ed25519 signature (sig.value, base64) against a key the Relying Party resolves through its own keyring — never a key named only by the artifact. The signed octets are exactly:

1. verify the Authorization Record and Execution Grant and their mutual bindings (), including its non-optional signature checks, through the authenticating entry point — the one that verifies the record chain and checks the grant's signature against a keyring the Relying Party holds independently. A bare digest builder verifies no signature and will compute a perfectly well-formed digest over a fully forged pair;
2. recompute the Action Digest from those verified documents, and verify the Parameter Pre-image against the Authorization Record's Parameter Commitment. Both are inputs to item 6, not values compared against anything the artifact supplies: the artifact carries neither, so there is nothing here for an attacker to substitute. If the Pre-image is absent, or if the Parameter Commitment is a keyed hash the Relying Party cannot reproduce, the Correlation Value cannot be derived at all and the verifier MUST return SETTLEMENT_BOUNDS_UNCHECKABLE () — a non-positive, non-failure result: never a positive verdict, and never a positive verdict qualified by a warning;
3. check railFamily is a member of the set this verifier ships, and fail closed on an unknown family;
4. check that the resolved event is of the expected type on the chain named by chainWitness.network (CAIP-2) at the token contract named by chainWitness.asset (CAIP-19), and that the chain and token contract are values the mandate committed to — the network and the asset are derived from the verified Parameter Pre-image's own networkCaip2 and assetCaip19 and compared, never lifted from chainWitness — see ;
5. check that the event's authorizer topic equals chainWitness.payer, and that chainWitness.payer is the payer the mandate committed to — see ;
6. recompute the Correlation Value per — from the Action Digest of item 2, the Execution Grant's nonce as the seed, and the chain identifier, token contract and payer address taken only from the verified Parameter Pre-image — and check that it equals both the event's identifier topic and the artifact's correlation member, comparing the 64 hex characters lowercased on both sides. A supplied Correlation Value MUST NOT be trusted, and a Correlation Value in the Action Digest's sha256: form MUST be refused rather than re-encoded (D5, D6);
7. check that exactly one such event exists for (authorizer, identifier) on that contract, and that its transaction status is success;
8. recover the transfer and bound it. Decode the settling transaction's calldata, or take the token Transfer(from,to,value) log emitted in the same transaction — the log MUST be emitted by the token contract named in the mandate-committed asset, its from MUST equal chainWitness.payer, and there MUST be exactly one such log (more than one -> not reconfirmed, never a pick). Then check the recovered to equals chainWitness.payee, the recovered value equals chainWitness.amount, and both lie within the bounds the mandate committed to;
9. compute confirmation depth against its own ledger head and apply its own finality threshold;
10. on any mismatch, return a distinct machine-readable code from the closed registry of , never a generic invalid.

• SETTLEMENT_CORRELATED_UNRECONFIRMED — correlated, but the ledger facts did not (or could not) confirm it: no chain facts supplied, or the caller's own depth/freshness thresholds unmet. This is the code for "not final";
• SETTLEMENT_NOT_OBSERVED — the Observer did not look;
• SETTLEMENT_NOT_SETTLED_AT_OBSERVATION — the Observer looked and saw no consumption yet;
• SETTLEMENT_BOUNDS_UNCHECKABLE — the Parameter Pre-image is absent, mismatched, or carries a keyed commitment the Relying Party cannot reproduce, so neither the bounds nor the derivation can run (item 2 of );
• SETTLEMENT_CORRELATION_BURNED — the correlation was consumed by a successful cancellation. Terminal, and specifically not "not yet" (, availability).

• Availability / denial of service. A party holding the payer key can consume the correlation without paying, by issuing a cancellation for the same (authorizer, nonce). The identifier is burned permanently and the approved payment can never settle under it. A verifier sees no consumption event and reports "not settled yet" for something that will never settle; 's absence rule must therefore distinguish not yet from burned, and a profile MUST carry the cancellation event in its fact set.
• Front-running. The target rail uses a transfer function whose own security considerations warn that a signed authorization can be extracted from the mempool and executed by a third party first. The payment happens; the facilitator re-verifies, sees a consumed identifier, and reports failure without locating the transaction that consumed it. An implementation MUST reconcile consumed identifiers or it will report failure for payments that actually settled.
• Privacy leakage. See .

• the artifact MUST carry chainWitness.network, chainWitness.asset and chainWitness.payer ();
• the verifier MUST check the event's authorizer topic equals chainWitness.payer (item 5 of );
• the mandate MUST commit to the network, the token contract AND the payer before dispatch. Otherwise those are attacker-chosen values compared against an event whose location the attacker chose, and the checks are circular. Committing the payer alone applies a correct circularity argument to one of three fields and leaves the other two open — which is attack (b) of .

1. By the mandate's Parameter Commitment. For a payment action class whose Parameter Pre-image carries payer, payee, asset, network, a maximum amount and the resource identifier, the Commitment covers all three bindings — and the same commitment is what item 8 of bounds the transfer against.
2. Inside the Correlation Value itself. The chain identifier, the token contract and the payer are derivation inputs (), so changing any one of them changes the 32 octets. This is the binding the one-stage construction could not have: it makes the three coordinates non-substitutable in the recomputation. A verifier can no longer be handed a value that "belongs" to some other triple, and the artifact's own chainWitness coordinates drop to reject-only.

(i) Verification is fail-closed on the Parameter Pre-image, and there is no partial tier. A Relying Party that does not hold the Pre-image cannot derive the Correlation Value, therefore cannot run item 6, and MUST return SETTLEMENT_BOUNDS_UNCHECKABLE () rather than a weaker positive. This is deliberate — a positive verdict over coordinates nothing bound was the defect the earlier construction carried — and it is also a real cost: no minimized, commitment-only presentation of this artifact exists in this version. Recompute-and-compare verification makes the Parameter Pre-image and the grant's nonce load-bearing, so disclosing the evidence discloses the mandate's payment parameters and its single-use nonce. A minimized presentation is a schema change, not a profile option. (ii) Money can move without a positive verdict, and this document does not claim otherwise. A party holding the payer key can derive a different 32 octets from a different seed, settle them for real, and produce a genuine consumption event on the ledger. Recomputation from the bundle's own documents yields exactly one value, so that settlement can never earn a positive verdict — but the transfer still happened and the funds are still gone. What this mechanism bounds is which settlements a Relying Party will accept as correlated, never which transfers a compromised payer key can cause. The honest ceiling is at most one settlement correlatable to this grant, never exactly one settlement per mandate.

1. No identifier-content policy was applied at or before the stage all three reached. A derived identifier reached the same processing stage as a freshly random one, and the structured control was not distinguished from either. An intermediary policing identifier shape or provenance at verification time would have separated (C) from (B) at minimum. This is a statement about the stages the three requests actually traversed; it is not a statement about stages none of them reached.
2. The refusal came from beyond signature verification. The simulated call reverted inside the token contract's balance check, which sits after the contract's own recovery of the signer from the EIP-712 digest — the digest that commits to the identifier. A derived identifier is therefore signature-valid at the contract, not merely accepted at the wire.

• The settlement path was not exercised. The requests were refused for want of funds, so no authorization was ever broadcast. A policy applied at settlement time — on the funded path, at broadcast, or by a settlement endpoint that verification does not share — is not excluded by this measurement.
• Nothing is established about stages beyond the refusal. The three requests are comparable only up to the point where all three stopped for the same unrelated reason.
• One deployment is not every deployment. An implementation SHOULD repeat this three-way comparison against the intermediary it intends to use before publishing an availability claim for that deployment; a divergence between (A) and (B) is the signal that the mechanism is unavailable there.

1. The Action Digest is not on the ledger. It is a dispatch-time input; what becomes permanently public is the derivation's output. An observer holding the ledger value alone cannot recover the digest from it and cannot test a guessed mandate against it, because the pre-image contains a seed the observer does not hold. The confirm-by-guess channel that a bare public digest would open on a permanent ledger is therefore closed against an outside observer. That is the whole reason the second stage exists, and it is the only privacy claim this document makes for it.
2. It is not closed against a bundle holder, and that is not the smaller problem. The seed is the Execution Grant's nonce and the grant travels inside the evidence bundle. Anyone handed the bundle can recompute the Correlation Value, locate the settlement on the ledger, and read the payer wallet from it — permanently, before or after settlement, with no way to withdraw the capability once granted. The mandate documents alone carry no wallet identity; the bundle creates that link. Disclosing an evidence bundle is a durable capability grant, not a one-time view, and 's residual (i) says why this version offers no minimized alternative.
3. Payer-level correlation was already available to any ledger observer via the authorizer topic, so a per-approval-unique, unguessable identifier adds no new linkage at that level. A low-entropy identifier would have added a new enumerable channel where none existed; the seed is what keeps that from happening, and the seed's entropy is a producer property that no verifier and no conformance vector can check (P4 of ).