Cedulon: An Audit Layer for Agent-to-Agent Commerce

3.1. Policy Decision Point

The PDP evaluates structured fields only (MUST-T1-1): amount, currency, payee, tool identifier, nonce, optional manifest hash, and evaluation time. It applies limit, velocity, and scope checks (MUST-T2-1, MUST-T2-2). If the PDP is unreachable, uninitialized, or throws, the result is deny (MUST-T2-3). Denied attempts do not increment success counters (MUST-T2-4).¶

An allow produces a Decision Token whose requestHash covers six fields: amount, currency, payee, tool, nonce, and manifestHash (MUST-T3-4, MUST-T6-1). The token is a COSE_Sign1 object (MUST-T6-4), is single-use (MUST-T6-2), and MAY be carried to the adapter that performs settlement.¶

3.2. Receipt Issuer

After the adapter attempts settlement (success or a recorded deny that still needs an audit trail for an allowed-then-aborted path), the Receipt Issuer signs a Spend Receipt over the deterministic CBOR encoding of its claims (MUST-T4-1). Verifiers reject bad signatures and byte mismatch (MUST-T4-2).¶

3.3. Anchor / SCITT

Parties MAY register the signed receipt (or a privacy-preserving hash encoding) as a SCITT Signed Statement [RFC9943] and attach the COSE receipt (MAY-T4-6). This document does not operate a Transparency Service.¶

5.1. Optional payee countersignature

A payee MAY attach a countersignature over the issuer's signed Spend Receipt (MAY-T8-10). The profile uses a detached COSE_Sign1 [RFC9052] whose payload is a CBOR map with private-use labels:¶

The countersignature uses the header profile in Section 6 and content type application/cedulon-countersign+cbor.¶

This is a second Sign1 object, not RFC 9052 Countersignature0 (unprotected-header label 11). Countersignature0 would write into the issuer object and change receiptHash after issue, breaking the receipt chain. A detached Sign1 keeps the issuer bytes stable, reuses kid and content-type, and is absent by simply omitting the sibling object.¶

Absence of a countersignature MUST NOT invalidate the issuer receipt (MAY-T8-10). A countersignature travels beside the issuer signature without being covered by it, so anyone holding an honest receipt can append one of their own. Attribution is therefore the gate: a countersignature that cannot be attributed to the pinned payee key - the signature fails, kid or content type does not match, label -70401 is not the issuer COSE bytes (MUST-T8-8), or the signature is valid under some other key - MUST be rejected as approval evidence. What is rejected is the countersignature, not the receipt: the verdict on the untouched issuer receipt MUST NOT change because an unattributable object was attached. An appendable object the issuer signature does not cover must not be able to manufacture a negative result; this is the lesson MUST-T8-9 already encodes for the manifest comparison, applied one object over. The identifiers countersign-bad (unverifiable) and countersign-key-mismatch (verifiable under another key) name the discarded object as warnings, and where the verifier pinned a payee key and no attributable countersignature remains, the countersign-missing warning still applies: a discarded forgery is the absence of the payee's word, not a substitute for it.¶

The optional deliveredHash claim binds delivery to the receipt under the payee's key. A payee who countersigns MAY include the SHA-256 of the exact bytes it received in the same signed payload as the issuer receipt bytes. When an attributable countersignature carries deliveredHash and the verifier also holds the Trade Manifest, the two digests are compared as exact octets: deliveredHash against acceptanceCriteriaHash. A mismatch is delivery-mismatch, and it is a finding rather than a warning, because both ends of the comparison are signed. A deliveredHash carried by an unattributable countersignature is discarded with it. A countersigner MUST refuse to sign a deliveredHash that is not 32 octets; a verifier that meets one anyway treats the countersignature as carrying no deliveredHash, so the delivery question narrows as it does when the claim is absent, and the signature verdict does not move. A countersignature without the claim is valid exactly as before -05, which introduced it.¶

A Dispute Evidence Bundle that includes a verified countersignature has stronger evidence that the payee accepted those bytes; the bundle is still not an award (MUST-T8-4).¶

6.1. Claim labels

Registered CWT claims [RFC8392] are not required by this profile. Cedulon uses CWT private-use integer labels less than -65536 so that the profile does not occupy the 100-110 registry range.¶

Every claim the tables below annotate as hash carries a SHA-256 digest rendered as exactly 64 lowercase hexadecimal characters ([0-9a-f]{64}). A signer MUST refuse to sign, and a validator MUST reject, a value that does not match that grammar, naming the claim in the refusal. A decoder that preserves unknown or foreign claims is a separate layer and keeps them unchanged; the grammar binds what a party signs and what a validator accepts, not what a decoder can carry. -04 stated the rendering in prose while its own Appendix A vector violated it, which taught decoders to be lenient; the grammar is enforced and the vector was regenerated in -05.¶

Receipt labels (MUST-T4-3, MUST-T4-4, MUST-T4-7):¶

Checkpoint labels (MUST-T11-1):¶

Manifest labels (MUST-T8-1):¶

Decision Token labels (MUST-T6-4):¶

6.2. COSE_Sign1 headers

The protected header MUST be a deterministic CBOR map containing (MUST-T4-1, MUST-T4-8):¶

• 1 (alg) = -19 (Ed25519, [RFC9864]; the generic EdDSA value -8 from [RFC9053] is deprecated for this profile)¶

• 3 (content type) = a tstr that distinguishes the payload: application/cedulon-receipt+cbor, application/cedulon-checkpoint+cbor, application/cedulon-manifest+cbor, application/cedulon-decision+cbor, application/cedulon-countersign+cbor, or application/cedulon-inclusion+cbor¶

• 4 (kid) = bstr, mandatory. The profile computes kid as the first eight bytes of SHA-256 over the issuer's SubjectPublicKeyInfo DER, in the Ed25519 SubjectPublicKeyInfo encoding of [RFC8410]. A verifier MUST obtain the public key from an authenticated channel (preconfigured issuer set, directory, or transparency statement) and MUST reject a message whose kid does not match that key.¶

The unprotected header MUST be empty, and a decoder MUST refuse a message whose unprotected header is not an empty map, by the name cose-sign1-unprotected, rather than verify the signature and ignore the header (MUST-T4-21). The reason is in Section 7.1: every digest over a signed object in this profile is computed over the COSE_Sign1 octets, which include the unprotected header, while the signature does not cover it. A decoder that ignored a stuffed header would verify the signature and compute a receiptHash the issuer never produced, so one honestly signed receipt could carry as many digests as a stranger cared to give it, and a chain built on prevReceiptHash would follow whichever copy it was handed. The posted -05 stated the header empty and said nothing about the decoder; the companion decoder ignored the header until the question of what the digest covers was measured. The payload MUST be the CBOR encoding of the claim map. The signature is Ed25519 [RFC8032] over the COSE Sig_structure ["Signature1", protected, h'', payload].¶

6.3. How a signed object is presented

The signed octets above are what this profile defines and what every digest in Section 7.1 is taken over. An object handed to a verifier travels with a little more than that, and the previous revisions used one of those members - the key an object carries - without ever saying where it came from.¶

A presented Spend Receipt, epoch checkpoint, Trade Manifest, or Decision Token carries, beside the signed octets, its claim set or body in decoded form and the signer's public key as a SubjectPublicKeyInfo PEM; a countersigned receipt carries the payee's key the same way, and an object presented in the JSON encoding of Section 7 repeats its signature there as base64. None of these is inside the signed octets, which is the whole point of naming them here: the signature covers the COSE message and nothing else, so every one of these members is a surface anyone holding the object can rewrite. This is the same shape the Rail Extract states in Section 9, and it is stated once here for the COSE objects rather than left to be inferred from an implementation.¶

A carried key is not an identity source and MUST NOT be used as one (MUST-T4-11). Under a pin it has exactly one effect: an object that verifies under the pinned key while carrying a different key is reported as carried-key-mismatch, a warning, and stays attested (Section 10.1). With no pin held it is the only key present, so the signature check that runs against it says the object is internally consistent and says nothing about who signed it; two issuers cannot be told apart in that state.¶

7.1. Which octets are hashed

Every hash-valued field in this document is SHA-256 [RFC6234] of the input named below. All but three are rendered as lowercase hexadecimal. kid differs only in its rendering: the digest is computed over the same stated input and then truncated to its first 8 bytes, carried as a byte string rather than as hex (Section 6 states the same rule where the header is defined). ap2MandateHash differs in whose digest it is: AP2 defines the mandate and its octets, and this document carries the result opaquely rather than restating a rule it does not own. deliveredHash differs in its carrier: it is a claim in a CBOR map and is carried as the raw 32 digest bytes (bstr), not as hex; comparisons against acceptanceCriteriaHash are made over the digest value. -03 named the digest for some of these fields and not for others; the omissions were not a deliberate degree of freedom.¶

Wherever this table, or any other sentence in this document, says "the signed COSE_Sign1 octets", those are the octets of the untagged four-element COSE_Sign1 array of [RFC9052]. This profile never wraps a message in CBOR tag 18, and the vectors in Appendix A carry the untagged form. A verifier that hashed a tagged copy would compute a different digest for every object in this profile, so the choice is stated here once rather than left to be inferred from the vectors.¶

The six fields of the request document are the ones MUST-T6-1 names: amount, currency, payee, tool, nonce, and manifestHash. -03 described requestHash as "the six-field hash" while naming SHA-256 for policyHash in the same sentence, which left a reader free to conclude that the request binding was not a digest at all. It is one.¶

Naming the members is not stating the document, so the document is stated here. The request document is a JSON object carrying exactly those six members and no others, every member always present. amount is the decimal string of the request, in the amount syntax the receipt claims table states, never a JSON number: [RFC8785] encodes the number 1 and the string "1" differently, and an implementation free to pick either would produce two digests for one request. currency, payee, and nonce are the request's text strings. tool is the request's text string, or JSON null where the deployment names none. manifestHash is the lowercase hexadecimal string, or JSON null for a spend bound to no manifest; an absent value is null, never an omitted member. A document with a seventh member, a missing member, or another type for one of these is not the request document this section defines.¶

The policy document is different on purpose, and the difference is scope rather than an oversight. Its member set is the deployment's own: this document defines how the bytes of whatever policy document a PDP evaluates are encoded (Section 7) and digested, not what its members are. policyHash binds a spend to the exact bytes its PDP evaluated; it is not a value two deployments are expected to compute from a shared schema, and nothing in the verification algorithm compares one deployment's policyHash to another's.¶

9.1. Record schema

The extract body is a JSON document. Each settlement record MUST contain the following members, under these names:¶

These member names are normative. A rail MAY add members of its own to a record; it MUST NOT rename the four above. -04 said the member names were the rail's to define, which contradicted this table and made the extract unconstructable from the text: a verifier reading reference where the table says ref has no rule telling it whether the two are the same member. The table wins, and -04's sentence is withdrawn. The table also used CBOR terms (tstr, uint) for what is a JSON body; the types above are stated in JSON terms.¶

A record MAY carry a beneficiary member (string). A rail that can resolve a payment reference to the party credited declares it there; when present, it is compared against the payee of the receipt that names the same ref, and a difference is reported (beneficiary-mismatch). Resolving a reference to a beneficiary is a feature of the rail's own system: this profile does not assume it, and measures it only when the rail declares it.¶

9.2. Scope

An extract is scoped to one account identifier, one rail identifier, and one half-open time window [windowStartMs, windowEndMs). The signed body is one JSON document with exactly this shape:¶

All six named members except clockSkewMs MUST be present; a body missing one, or a record renaming a core member, MUST be refused by name at both ends - by the signer before it signs and by the verifier before it checks a signature - so a malformed extract is the same refusal on both sides rather than a signature verdict. Additional members beyond these are the rail's to add, as with records.¶

The integer-valued members - windowStartMs, windowEndMs, each record's timestampMs, and clockSkewMs - MUST be integers of magnitude at most 2^53 - 1, the range a JSON number carries exactly, and clockSkewMs MUST NOT be negative; a value outside those bounds, or a non-integer, is refused by name in the same way as a missing member. windowEndMs MUST be greater than windowStartMs: the window is half-open, so one that does not end after it starts declares no population, and a body carrying one is refused by name (malformed-extract-window) in the same way, at both ends.¶

The body is read as text before it is read as an object. A text in which any object repeats a member name is refused as json-duplicate-key at both ends, before parsing and before any signature is checked (MUST-T4-20, Section 7); a signer that parsed first would sign one of the two values and an honest verifier could check the other.¶

clockSkewMs, when present, declares the boundary allowance the verifier applies at this window's edges during reconciliation (Section 11); when absent, the profile default of 300000 milliseconds (five minutes) applies.¶

9.3. Authentication

The rail signs Ed25519 [RFC8032] over the canonical encoding of the scoped body, which is a JSON document and therefore takes the encoding of Section 7: the signed octets are the UTF-8 octets of the [RFC8785] encoding of the body above. The signature and the rail's public key travel beside the body, the signature as base64 and the key as a SubjectPublicKeyInfo PEM; neither is part of the signed octets. A verifier MUST obtain the extract from the rail or from a signature the rail published (MUST-T10-7). A deployment that cannot do so is running the reconciliation against evidence it did not obtain independently, and MUST report the guarantee as conditional.¶

A signature on an extract proves internal consistency, not origin: a key generated by whoever produced the object verifies against itself. The verifier therefore MUST obtain the rail's public key out of band and MUST verify the extract signature against that key (MUST-T10-8). A key the extract carries is not that key: it is neither the rail's identity nor a fallback for one the verifier did not obtain. Where no such key is held, the carried key is the only key present, so the signature check that runs against it says the extract is internally consistent and says nothing about who produced it, and the verifier MUST treat the guarantee as conditional.¶

Keys are compared as bytes. A verifier MUST compare the pinned key and the key that signed the extract by their SubjectPublicKeyInfo DER encoding, not by any text encoding of it, so that the same key presented in a different envelope still compares equal (MUST-T10-9). A pinned key the verifier cannot decode is a fault in the verifier's own configuration, not evidence about the extract, and MUST be reported as trust-key-unreadable rather than as a key mismatch.¶

What a verifier emits for an extract it cannot authenticate depends on whether it stated an expectation. With no pinned key the verifier has asserted nothing, so the condition is unauthenticated-extract whatever the extract carries - a signature that verifies against the carried key establishes internal consistency and not origin, and one that fails or is refused is not a verdict about a key either. It is a warning: completeness findings may still be computed, but the guarantee is conditional on the extract being authentic. With a pinned key the verifier has asserted what it requires, and an extract that fails to meet it is a failure rather than a caveat; see the verification algorithm for which finding applies. -00 defined only the first case, and readers of -00 should note that -02 made the pinned case fail closed. See Section 16.¶

9.4. Scope agreement

An extract declares a window and carries settlement records. The two MUST agree: a verifier MUST report every settlement record whose timestampMs falls outside [windowStartMs, windowEndMs) as extract-scope-mismatch, identified by that record's ref (MUST-T10-10). This check is about the extract's internal consistency and MUST be performed whether or not a rail key is pinned.¶

A verifier that knows which account, rail, and window it is auditing MUST also check the extract against that expectation and MUST fail closed when the extract does not cover it (MUST-T10-11). An extract for another account or rail, or one whose window does not span the period under audit, cannot support a completeness claim about that period.¶

A verifier that states no period leaves the extract free to define one, and an extract that reports on a millisecond balances as easily as one that reports on a month. Pinning a key establishes who signed; only a stated period establishes what the signature had to cover. A verifier that has not stated the period under audit therefore MUST emit unstated-audit-window and MUST treat the guarantee as conditional (MUST-T10-15), whatever else verifies.¶

The period is one axis of that scope. The account and the rail are the other two, and they behave the same way: an extract names one of each, so a verifier that has not stated them leaves the extract to say whose settlements were accounted for and which way out was watched. A verifier that has not stated the account or the rail under audit therefore MUST emit unstated-audit-scope and MUST treat the guarantee as conditional (MUST-T10-18). Where no rail key is pinned at all, all three axes are equally unstated and unauthenticated-extract is the condition reported.¶

Stating them does not widen the population; it names it. One account settling on two rails has two settlement paths, and an extract for the first reports nothing about the second: a spend that left that way is not an unmatched row, it is outside the population the extract declared. Because the strongest line this profile prints - a balanced audit under an unconditional guarantee - is true of one account, on one rail, over one window, a report that carries it MUST also carry that account, rail and window (MUST-T10-19). A completeness claim about an account is the conjunction of one such report per rail that account can settle on, and enumerating those rails is the deployment's statement, not something an extract can be asked to prove.¶

10.1. The issuer root

A verifier MUST obtain the issuer's public key out of band and MUST verify Spend Receipt and epoch checkpoint signatures against that key. A key the object carries is not that key: it establishes no signer identity and is not a fallback for a pin the verifier does not hold (MUST-T4-9, MUST-T4-11). Where no issuer key is held, a signature checked against the key its own object carries establishes internal consistency and nothing more, which is the state Section 6.3 and the last row of the table below describe. A verifier that holds no such key and is presented with any Spend Receipt or epoch checkpoint MUST treat the completeness guarantee as conditional and SHOULD report the condition; the identifier unauthenticated-issuer is used for it in this implementation.¶

The condition names those two objects because an audit given no receipts and no checkpoints rests on the extract alone. There the absent issuer root withholds nothing, and warning about a root the audit never consulted would spend the warning where it carries no information.¶

Reporting a mismatch is not sufficient on its own. A receipt that does not answer to the pinned issuer key MUST NOT count as coverage for the settlement it names, and the settlement MUST still be reported as uncovered (MUST-T4-10). A verifier that reports the mismatch and then lets the receipt match the settlement anyway has described the attack in its output while still concluding that the books balance.¶

Keys are compared as bytes, by their SubjectPublicKeyInfo DER encoding, on the same terms as MUST-T10-9. A pinned issuer key the verifier cannot decode is a fault in its own configuration and MUST be reported as trust-key-unreadable rather than as a mismatch against the objects; where no pinned key can be decoded at all, nothing is attested and the verifier MUST NOT fall back to accepting the keys the objects carry (MUST-T4-11). Falling back is how a mistyped configuration becomes a bypass.¶

Membership in the attested set follows one rule: the signature verifies under a pinned issuer key. The kid header routes the check to a candidate key; the key an object carries beside its signature is not an identity source, because it travels outside the signed octets and anyone can rewrite it. Two consequences are stated so that implementations do not diverge on them. First, an honestly signed object whose carried key was swapped stays attested: the swap is reported (carried-key-mismatch, a warning) and MUST NOT move the object out of the attested set or change the verdict, on the same reasoning as Section 5.1 - a surface the signature does not cover must not be able to manufacture a negative result. Second, an object that claims the pin, by its carried key or its kid, but does not verify under it is excluded from the attested set and MUST still be walked and named - for a receipt, receipt-chain-break with a signature-failed detail - never silently dropped; an object that neither verifies under the pin nor claims it is issuer-key-mismatch, excluded, and the settlement it names stays uncovered.¶

The rule, read out per cell (steps 6 and 8 are the verification algorithm's):¶

A verifier MUST accept an issuer root that is a set of keys rather than a single key (MUST-T4-12). An issuer that rotates its key mid-window otherwise produces a finding against every honest receipt signed by the retired key, and the reachable way out of that is to stop pinning, which is the opposite of what the pin is for. The same acceptance applies to a publisher pin, a witness pin, and a rail pin: a verifier MUST accept each of those roots as a set of keys, so a rotation inside the window does not force it off the pin.¶

10.2. The payee root

The optional countersignature in Section 5.1 travels beside the issuer signature without being covered by it. Anyone holding an honest receipt can append a countersignature of their own, so a verifier that checks it against the key carried next to it learns only that some key signed something.¶

A countersignature MUST NOT be treated as evidence that the payee approved the payment unless it verifies against a payee key the verifier obtained out of band (MUST-T4-13). Without such a key the verifier SHOULD report the condition and MUST treat the guarantee as conditional.¶

Naming a payee key states an expectation, and an expectation that only fires when the evidence is present can be cancelled by deleting the evidence. Where a verifier has pinned a key for a payee, a settled receipt naming that payee and carrying no attributable countersignature MUST be reported (MUST-T4-14): a countersignature that failed to verify, or verified under some other key, is discarded under Section 5.1 and leaves the expectation open exactly as a missing one does. Otherwise an attacker removes their own failed forgery - or appends one - and the report returns to unconditional. The discarded object itself is a warning, never a failure of the receipt it rode beside; Section 5.1 states the invariant.¶

10.3. The witness root

Section 11.3 describes what a transparency witness adds. An inclusion receipt checked against the key it carries says that some log is internally consistent, and a log is cheap to invent.¶

A verifier MUST obtain the transparency service's public key out of band and MUST verify inclusion receipts against it (MUST-T11-15). Inclusion receipts that cannot be checked that way MUST NOT be used as evidence, in either direction: they cannot establish that a checkpoint was anchored, and they cannot establish that one was withheld. A verifier SHOULD report that it left them out.¶

A log holds statements from everyone who uses it. A statement held by a pinned log MUST additionally answer to the issuer root before it counts as something that issuer published (MUST-T11-16); otherwise another user's epoch, sitting in a shared log, reads as this issuer publishing two checkpoints for one epoch.¶

Anchoring and withholding are different claims and need different evidence. Establishing that a checkpoint was logged needs only the statement hash. Establishing that an issuer withheld one needs to know whose statement it is, which an inclusion receipt carrying no statement body cannot say. Such a receipt MUST NOT be used to report a withheld checkpoint, and MUST NOT be silently discarded either: a real withholding must not be buried by removing the body (MUST-T11-17).¶

10.4. The decision root

A Decision Token is issued by the policy decision point and consumed by the same deployment. The consumer therefore holds the key it signs with and has no reason to ask the token which key to check it against. A consumer MUST verify a Decision Token against its own issuing key and MUST NOT accept one it cannot check that way (MUST-T6-6).¶

10.5. The manifest root

A Trade Manifest is optional. A deployment that presents none is not missing a root, and this requirement does not make such an audit conditional. The forbidden case is the other one: a manifest is presented, and the verifier accepts it because the key travelling inside it verifies against itself.¶

A verifier that is presented with a Trade Manifest MUST obtain the publisher's public key out of band and MUST verify the manifest signature against that key, not against a key the manifest carries (MUST-T4-15). A verifier without such a key that is presented with a Trade Manifest MUST report the completeness guarantee as conditional and SHOULD report the condition; the identifier unauthenticated-manifest is used for it in this implementation. An audit presented with no Trade Manifest is not made conditional by this requirement.¶

A pinned manifest key the verifier cannot decode is a fault in its own configuration and MUST be reported as trust-key-unreadable rather than as a mismatch, on the same terms as MUST-T4-11. A manifest that does not verify against a readable pin MUST be reported as manifest-key-mismatch and MUST fail the audit. Falling back to the key the manifest carries is how a presented document becomes a bypass.¶

Attribution is one question and coverage is another, and a root that answers only the first leaves the document doing work it was never spent under. A verifier presented with a Trade Manifest MUST compare the manifest hash to the manifestHash of the receipts presented to the audit and MUST report a manifest that no presented receipt references (MUST-T4-17); the identifier manifest-covers-no-receipt is used for it in this implementation, and the completeness guarantee is conditional. The comparison runs against those presented receipts, including aborted ones, and is made before any extract window is applied and before any issuer key is applied; a hash on an aborted receipt, on a receipt outside the extract window, or on a receipt no pinned key attests still counts as a reference. This requirement asks whether any receipt names the terms, not whether a settlement in the window was made under them, and not whether the receipt that names them is attributable. A forged receipt can therefore silence this warning. That is accepted: what it silences is a statement that terms were named, and the report it leaves behind is still marked conditional and still carries the finding that the receipt answers to no pinned key. A correctly attributed manifest travelling beside a set of receipts marked noManifest states terms nothing presented was spent under, and a report that stays silent about it reads as terms-backed when it is not. This requirement does not reach the audit presented with no Trade Manifest, which remains a deployment choice under MUST-T1-2.¶

Naming a manifest is not obeying one, and that is the third place this document has had to say the same thing twice. A verifier presented with a Trade Manifest MUST compare the amount, the currency and the settlement time of every receipt that names it against the manifest's amount, currency and expiry, and MUST report a receipt that departs from them (MUST-T8-9); the identifier manifest-terms-mismatch is used for it in this implementation. Every receipt that names the manifest is measured, aborted ones included: an aborted receipt that carries the hash of terms and a departing amount recorded an attempt against terms it misstates, and MUST-T4-17 next door already counts it as a reference. The time compared is the receipt's timestampMs, against the boundary MUST-T3-3 states: strictly after expiresAtMs departs, exactly at it does not. Amount and currency are compared on the exact-octet terms of MUST-T8-2 - the audit asks whether the gate's own rules were kept, so it compares the way the gate compares.¶

Where a usable issuer key is pinned, the comparison is made over the receipts that verify under it and the audit fails. Where none is pinned, the departure is still reported and the audit does not fail on it alone. An issuer key is usable when the pinned issuer root holds at least one key the verifier can decode. A pinned root none of whose keys decode is already trust-key-unreadable and attests nothing, so the comparison takes the unpinned branch while that finding stands; the audit has failed on the configuration fault, and the departure is still said out loud without becoming a charge no readable key backs. -03 stated the first case for both, and an implementation showed why that is wrong: a receipt signed by any key at all, carrying the right manifest hash and the wrong amount, made the verifier report a breach that never happened, against a payment reference the forger chose. Reporting a departure costs nothing if it is unattributable; failing an audit on it hands an attacker a way to accuse an honest payer.¶

MUST-T4-17 and this requirement therefore differ, and the difference is not an inconsistency. Asking whether a manifest hash appears anywhere is a question about a set of documents, and an unattributable document is still in that set. Saying that a named party broke terms it signed is a charge, and a charge needs a key behind it.¶

Only receipts that name the manifest are measured against it: reading the terms onto a receipt that never claimed them would invent a violation the payer did not commit.¶

The rules being enforced here are not new. A gate already refuses a bound spend whose amount or currency differs from the manifest (MUST-T8-2) and one made against an expired manifest (MUST-T3-3). Both were written for the point where money moves, and an audit reads the record after that point, where the gate is no longer present to be asked. Without a counterpart a receipt can carry the hash of terms it breaks and the report still calls the books balanced. This is a finding rather than a condition on the guarantee: a verifier that reports it held every root it needed, and the statement it is making is unconditional.¶

The gate answers differently from the audit, and the difference is deliberate. A policy decision point presented with a Trade Manifest it cannot attribute MUST refuse the payment rather than settle and record the doubt (MUST-T4-16). An audit describes what it found and may say the result is conditional; a gate decides whether money moves, and a settled payment carrying the hash of terms nobody authorised cannot be withdrawn by reporting it afterwards. The receipt would record those terms as agreed.¶

10.6. What the roots do not cover

A verifier that supplies none of these roots is not making an error, and this document does not require it to. It is making a weaker statement, and the guarantee it reports must say so. With no issuer key nothing distinguishes one submitted receipt from another, so conditions computed across the submitted set - two receipts claiming one settlement reference, for instance - cannot be attributed to anyone and are reported as conditions of the submission rather than as failures of a party.¶

11.1. Checkpoint claims

An epoch checkpoint MUST be COSE_Sign1-signed with the header profile in Section 6 and MUST bind all of the following (MUST-T11-1):¶

epoch, startMs, endMs, receiptCount, chainHeadHash, totals, and prevCheckpointHash.¶

The checkpoint window is half-open [startMs, endMs) (MUST-T11-7). receiptCount MUST equal the number of receipts (settled and aborted) whose timestampMs falls in that window. chainHeadHash MUST equal receiptHash of the last receipt in that window - the last link, in issuer order (the prevReceiptHash chain, as the verification algorithm's step 6 defines it), of the chain inside the window, not the last one presented or the latest timestampMs - or null if the window is empty (MUST-T11-2). Where totals is present it MUST sum only receipts with outcome = settled; the one permitted absence is the signed redaction below.¶

An issuer that publishes a checkpoint without its totals MUST encode totals as null in the signed payload (MUST-T11-12). An empty map is an honest zero for an empty window and is not a redaction. Because the redaction is inside the signature, it cannot be added to, or removed from, a checkpoint after signing.¶

A verifier MUST NOT accept a redaction asserted anywhere but the signed payload (MUST-T11-13). A presentation-layer flag alongside a checkpoint is chosen by whoever presents it, which is the party under audit; honouring such a flag would let that party switch off the totals comparison for a checkpoint whose signed totals are wrong. The structural claims (epoch, startMs, endMs, receiptCount, chainHeadHash, prevCheckpointHash) MUST NOT be redacted: a checkpoint missing any of them does not decode, and a verifier MUST treat it as a failed checkpoint rather than as a redacted one.¶

11.2. Genesis and continuity

The first checkpoint in a presented chain is the genesis checkpoint of that chain. Its prevCheckpointHash MUST be null. Epoch numbers MUST be consecutive integers. Adjacent windows MUST satisfy next.startMs = prev.endMs (MUST-T11-8).¶

A later checkpoint that omits a prefix of earlier epochs (prefix deletion) is detectable only if an external witness (transparency log) has recorded the missing prefix (MUST-T11-9). Without that witness, T11 guarantees about suppression are conditional.¶

-01 stated that dependency and stopped there: nothing in its verification algorithm read a witness receipt, so the witness had no way to speak. -02 gave it one. A verifier that holds witness receipts for the period under audit compares what the witness recorded against what the chain presented, and reports the difference under its own name (Section 11.3). A witness that holds a checkpoint the presented chain omits is not the same condition as a chain that leaves a gap in its own coverage, and the two MUST NOT be reported under one identifier (MUST-T11-11). The first says evidence is being withheld; the second says the evidence shown is incomplete. An operator who cannot tell them apart cannot tell an incomplete record from a concealed one.¶

11.3. The transparency witness

A checkpoint registered with a Transparency Service [RFC9943] is a Signed Statement whose payload is the checkpoint COSE object and whose content type is application/cedulon-checkpoint+cbor (Section 14). What comes back, and what it proves, is stated as two named tiers, because -04 promised the mechanics of one tier while describing the checks of the other.¶

Tier 1 - the witness receipt. The witness returns a co-signature over the statement hash of what it recorded: a COSE_Sign1 whose payload binds the statement hash, the entry index, and the witness's tree head. Verifying it establishes exactly one sentence - "the witness signed for this hash" - and nothing more; in particular it does not establish membership in an append-only log. -04 called this object a transparency receipt and cited the verification mechanics of [RFC9942] for it while describing a hash comparison; the admission in Section 18, that the receipt was a signature over a statement rather than a proof of log membership, was correct, and the protocol text now says the same thing. The [RFC9942] citation applies in tier 2, where its mechanics are actually performed.¶

On the wire the witness receipt is a COSE_Sign1 under Section 6, signed by the witness key, with content type application/cedulon-inclusion+cbor (Section 17.6). Its payload is a deterministic CBOR map carrying three entries and is not a CWT claim set: label 1 is the statement hash, label 2 the entry index, label 3 the tree head. The two hashes are text strings holding the lowercase hexadecimal of a 32-octet SHA-256, the statement hash taken over the octets of the statement the witness recorded; the entry index is an unsigned integer. The hash strings are compared as issued and are not passed through the hash-claim grammar the claim sets use; the revision that moves them to byte strings will close that difference. Entries under other labels are not defined, and a verifier of this revision does not refuse them. The map carries no statement body: a receipt that travels with the body carries it beside the COSE object, not inside it (Section 10.3, MUST-T11-17). A receipt whose content type is another value, or whose payload lacks one of the three entries or carries one of another type, does not verify: the content type is the check Section 6 makes on every object of this profile, and the payload map is the one this paragraph states.¶

A verifier MAY be given witness receipts for the period under audit. It is a distinct input from the presented checkpoint chain, and supplying it is optional: a verifier given none performs the same steps, and reports the same findings, that it would if this input did not exist (MUST-T11-10). Supplying an empty set is not the same as supplying none. An empty set says a witness is configured and recorded nothing, which is itself reportable; absence says no witness was consulted.¶

A receipt binds a statement hash, not a statement. The body is not carried by the receipt and a verifier will often not hold it. Two levels of checking follow from that, and they are not the same (MUST-T11-10).¶

Every receipt MUST have its signature verified before it counts for anything. That is what establishes the hash as one the service signed for, and it is all that comparing recorded hashes against presented ones requires: the verifier computes the statement hash of each presented checkpoint itself.¶

A receipt accompanied by the statement body carries more, and MUST be checked further before that body is relied on. The body's statement hash MUST equal the hash the receipt binds, and the body MUST itself verify as a checkpoint. A body that fails either check proves nothing and MUST be ignored rather than counted, while the receipt it came with remains usable for the hash comparison. Equivocation is the case that needs a body, because it compares claims rather than hashes.¶

Tier 2 - log membership. A verifier MAY additionally be given, for one recorded statement, the registered Signed Statement bytes (the candidate entry) and an inclusion proof. When both are present, the verifier MUST perform the verification of [RFC9942] Section 5.2.1 over them: hash the candidate entry bytes to obtain the leaf, apply the proof to reproduce a root, and accept only when the leaf hash, the proof's leaf index, and the reproduced root are all equal to the statement hash, entry index, and tree head of one witness receipt that verifies under the pinned witness key (MUST-T11-18). Reproducing a root is deliberately not sufficient on its own: the proof format below carries no domain separation between leaves and interior nodes, and the exact match against a witness-signed receipt is what closes the ambiguities that follow from that. A pair that fails this check, or a candidate entry presented without a proof, MUST be reported as a failing finding; the identifier witness-inclusion-invalid names it.¶

The inclusion proof is an audit path: the leaf index, and the sibling hashes from the leaf's level up to the root, lowest level first. The tree is built over statement hashes as leaves; an interior node is the SHA-256 of the concatenation of its two children's 32 raw bytes; a level with an odd count pairs its last node with itself, so the path needs no separate leaf count.¶

Where witness receipts are supplied and this pair is not, tier 2 was not exercised, and the report MUST say so rather than letting the tier pass silently (MUST-T11-19); the identifier witness-inclusion-not-exercised names it, as a warning - the witness attested the statement hash, and log membership was not proven. A pair that verifies is silent, like every other passing check in the algorithm.¶

What tier 1 establishes, and what it does not, is worth stating plainly. It establishes that the service signed for that statement. Whether the statement is a member of an append-only log is tier 2's question, answered only where tier 2's inputs were supplied and verified; whether the log has ever equivocated remains a property of the service and its own proofs. A verifier that treats a tier-1 receipt alone as proof of log membership is claiming more than the receipt carries.¶

11.4. Verification algorithm

A verifier MUST perform all of these steps and MUST report every finding they produce (MUST-T10-1, MUST-T11-2). They are numbered for reference, not to require an evaluation order: no step short-circuits another, and an implementation may evaluate them in any order that produces the same set of findings.¶

The data dependencies are named, because "any order" read naively would break them. Step 15 decides which witness receipts, and which statement bodies, survive checking; steps 14 and 16 consume what survives. Step 7's index of refs is what steps 8 and 9 reconcile. Step 11 decides which checkpoints verified, and step 14 compares only those together with what step 15 admitted. An implementation that ran a consumer against an unchecked producer would not produce the same set of findings, so those orders are not among the permitted ones.¶

The second is the issuer pin. The step that resolves it decides the attested set - the receipts and checkpoints that verify under a usable pinned issuer key, or the whole presented set when no usable key is pinned - and every later step that walks receipts or checkpoints consumes that set: the chain walk in step 6, the indexing and reconciliation in steps 7 through 9, the checkpoint comparisons in steps 11 through 13, and the MUST-T8-9 comparison. A receipt the pin rejects is reported once and then excluded, which is what keeps the settlement it names visible as uncovered (MUST-T4-10); an implementation that let it back into any of those steps would let a forged receipt cover a settlement, satisfy a checkpoint count, or invent a terms charge. Two checks deliberately stay on the presented set whatever any key says, and MUST NOT acquire the dependency: MUST-T4-17, which asks whether a manifest was named at all, and the per-receipt defect checks that ask what a receipt says about itself. -04 asserted that nothing else in the list fed another step, which the dependencies above had already made false; the assertion is withdrawn and the list above is the inventory, maintained rather than summarised.¶

When a step names an identifier in backticks, that identifier SHOULD be used for the condition in diagnostic output. The normative requirement is the behaviour: report the condition, identified by the ref or other handle given in the step. The identifiers are not an interoperability surface.¶

1. Establish the subject of the audit. When an extract is supplied, the settlement records it carries are the ones reconciled; a settlement list from any other source MUST NOT be substituted for them (MUST-T10-12). If the caller supplies both and they differ, the verifier MUST report that the caller-supplied list disagrees with the extract, and MUST still reconcile the extract. The identifier extract-settlement-mismatch SHOULD be used for this condition in diagnostic output.¶

2. Verify the extract signature against the out-of-band rail key (MUST-T10-8, MUST-T10-9). If no key is pinned, the check that runs is against the key the extract carries, which establishes internal consistency and not origin; the verifier MUST still compute it, MUST NOT read it as a statement about who produced the extract, and MUST treat the completeness guarantee as conditional (MUST-T10-7). The identifier unauthenticated-extract SHOULD be used for this condition in diagnostic output, whatever the extract carries. If a key is pinned and cannot be decoded, the verifier MUST report that the pinned key is unreadable. The identifier trust-key-unreadable SHOULD be used for this condition. If a key is pinned and the signature does not verify against it, or verifies against a different key, the verifier MUST report that the extract is not signed by the pinned key. The identifier extract-key-mismatch SHOULD be used for this condition. The rows of an extract the pin refused are not reconciled against the receipts, and no settlement finding is read out of that document (MUST-T10-20); the identifier settlement-comparison-skipped SHOULD be used to say that the comparison did not run. A finding that puts the extract itself in doubt MUST prevent an unconditional guarantee.¶

3. Check scope. The verifier MUST report each settlement record whose timestampMs falls outside the declared window, identified by that record's ref (MUST-T10-10). When the verifier states an expected account, rail, or window, it MUST report an extract that does not cover it (MUST-T10-11). The identifier extract-scope-mismatch SHOULD be used for both conditions. If the verifier stated no period, it MUST treat the guarantee as conditional (MUST-T10-15). The identifier unstated-audit-window SHOULD be used for this condition. If it stated no account or no rail, it MUST treat the guarantee as conditional for the same reason (MUST-T10-18); the identifier unstated-audit-scope SHOULD be used. Whatever the verdict, the report MUST name the account, rail and window the extract declared, in every structure it returns for the audit (MUST-T10-19).¶

4. Resolve each Spend Receipt against the issuer root (Section 10.1) in one pass. Decode the COSE_Sign1; a content type that is not the receipt type, a decoder bound, or a decoded claim map that does not match the presented claims is a named refusal, not a signature verdict (MUST-T4-2, MUST-T4-8). Then ask one question: does the signature verify under a pinned issuer key. kid routes the check to a candidate key and carries no authority of its own; the carried key is not consulted for membership at all. The resolution table in Section 10.1 reads the answer out per cell. Every cell there is a named condition plus a membership decision; no cell is a silent removal, and the word "reject" in earlier revisions meant nothing more than a cell of that table. Where a countersignature is present, Section 10.2 governs what it establishes (MUST-T4-13, MUST-T4-14). Where a Trade Manifest is presented, Section 10.5 governs it (MUST-T4-15): with no publisher key pinned the verifier reports unauthenticated-manifest and the guarantee is conditional; with a pin that cannot be read, trust-key-unreadable; with a pin the manifest does not answer to, manifest-key-mismatch; and with a manifest that no presented receipt references, manifest-covers-no-receipt (MUST-T4-17). A receipt that names the manifest but departs from its amount, currency, expiry or, where the manifest names one, payee is reported as manifest-terms-mismatch; with a usable issuer key pinned the comparison runs over the attested receipts and the departure fails the audit, and with no usable issuer key it is a warning over the presented receipts and does not by itself fail the audit (MUST-T8-9). An audit presented with no Trade Manifest is not made conditional by this step.¶

5. Scope the receipts. Membership follows the ref binding first: a receipt whose ref appears on the extract is reconciled against this extract even when its own timestampMs falls outside the declared window - the rail has signed that the settlement belongs to the window, and the receipt follows its settlement. The timestampMs sieve applies only to receipts the extract does not name: such a receipt outside the window is not a completeness failure against this extract (MUST-T10-16); auditing a longer period requires extracts that cover it. At the window's edges the declared allowance applies (Section 9): an unmatched settled receipt within clockSkewMs of windowEndMs, and an unmatched settlement record within clockSkewMs of windowStartMs, are reported as boundary-deferred, a warning, rather than as step 8's completeness findings - two honest clocks can disagree by less than the allowance, and both verifiers of an honest edge payment would otherwise reach the same false accusation (MUST-T10-17). Where the following window's extract is presented and verifies, a deferred receipt whose ref appears on it is resolved and not reported, and one whose ref does not appear hardens into the step 8 finding; a deferred settlement record near the opening edge resolves through this step's ref binding, since the prior window's receipt that names its ref is reconciled here regardless of timestamp. The following window's extract closes or hardens closing-edge deferrals only; an opening-edge record stays deferred until a receipt in the presented bag names its ref, whether or not a following extract is presented. In a single-window audit a deferred record keeps the guarantee conditional. Receipts remain subject to every other check regardless of window.¶

6. Walk the attested receipts in issuer order. Issuer order is the order induced by the prevReceiptHash chain: the verifier rebuilds the chain from the links, and the order in which receipts were presented carries no weight. timestampMs is issuer-asserted and is not an ordering source. The first prevReceiptHash MUST be null. Each later prevReceiptHash MUST equal receiptHash of the previous receipt. A miss, and a receipt the links cannot place, MUST be reported as a break in the receipt chain. The identifier receipt-chain-break SHOULD be used for this condition.¶

7. Index the attested settled receipts and extract records by ref. A ref that appears more than once on either side MUST be reported as a repeated reference (MUST-T10-6). The identifier duplicate-ref SHOULD be used for this condition.¶

8. For each ref that appears exactly once on each side, require a one-to-one match on ref AND amount AND currency (MUST-T10-1), compared as exact octets on the terms of MUST-T8-2; step 9's aggregation is the only place this algorithm reads an amount as a number. Amount or currency mismatch MUST be reported as a settlement that does not match its receipt, identified by that ref. The identifier settlement-mismatch SHOULD be used for this condition. A settlement with no receipt MUST be reported as lacking a receipt, identified by its ref (MUST-T10-2). The identifier settlement-without-receipt SHOULD be used for this condition. A settled receipt with no extract row MUST be reported as a completeness failure (MUST-T10-3). The identifier receipt-without-settlement SHOULD be used for this condition. A settled receipt with a null rail ref MUST be reported as settled without a rail reference; this check asks what a receipt says about itself and runs over the presented receipts, attested or not. The identifier settled-without-ref SHOULD be used for this condition. Where a settlement record declares a beneficiary (Section 9), it MUST be compared against the matched receipt's payee as exact octets; a difference is beneficiary-mismatch and fails the audit. Where neither the manifest names a payee nor any settlement record declares a beneficiary, the report MUST carry counterparty-unbound, a scope record: ref, amount and currency closed against the payer's account extract, and the counterparty's identity was not bound. It is a statement of what the evidence did not cover, not a doubt about what it did, so it does not move the verdict and does not by itself make the guarantee conditional.¶

9. A ref already reported as repeating MUST still be reconciled by amount rather than dropped from the comparison (MUST-T10-13). For each currency under that ref, compare the total settled against the total receipted. A settled total that exceeds the receipted total MUST be reported as a settlement lacking a receipt, and the finding MUST state the unaccounted amount. The identifier settlement-without-receipt SHOULD be used for this condition. A settled total that is less than the receipted total MUST be reported as a settlement that does not match its receipt, identified by that ref. The identifier settlement-mismatch SHOULD be used for this condition. An amount on that repeating ref that cannot be parsed as an integer MUST be reported without abandoning the audit; the identifier malformed-amount SHOULD be used for this condition. A verifier MUST still report findings for the remaining records.¶

10. Aborted receipts are not matched to extract rows and are not added to totals.¶

11. Decode each checkpoint. Reject a failed signature, and reject a kid that does not match the key obtained for the checkpoint issuer, on the same terms as a receipt (MUST-T4-8). Require receiptCount, chainHeadHash, and totals to match the attested receipts in [startMs, endMs) as defined above (MUST-T11-2); a receipt step 4 rejected is not among them, or a forged receipt could satisfy a checkpoint count. The identifier checkpoint-total-mismatch SHOULD be used for a failed signature, a wrong receiptCount, or totals that disagree, and checkpoint-head-mismatch for a chainHeadHash that is not the last link, in issuer order (step 6), of the chain inside [startMs, endMs) - "last receipt" binds to the chain, not to presentation or to timestampMs. If the signed totals is null, the verifier cannot perform the totals comparison for that checkpoint. It MUST report that the comparison was skipped and MUST treat the completeness guarantee as conditional; the absence of a comparison is not a passed comparison (MUST-T11-12). The identifier checkpoint-totals-redacted SHOULD be used for this condition. receiptCount and chainHeadHash MUST still be checked. A checkpoint that fails verification MUST NOT be treated as redacted, whatever it claims about its own totals.¶

12. Every chained receipt MUST fall in exactly one checkpoint window. A gap or double count MUST be reported as a window coverage failure (MUST-T11-7, MUST-T11-8). The identifier window-coverage SHOULD be used for this condition. The check runs against the presented checkpoint windows and it is fail-closed: a receipt that falls under none of them is this failure - including every receipt when no checkpoint was presented, and receipts after the last closed checkpoint's endMs. The text names that last state an open epoch, and it is auditable only when the checkpoint that closes it is issued; the name explains why the finding fired, it does not soften it. Nothing about an absent checkpoint is silent: uncovered evidence surfaces as a finding rather than as a gap in the report.¶

13. Walk checkpoints in epoch order. prevCheckpointHash MUST equal the SHA-256 of the previous checkpoint COSE bytes, or null for genesis (MUST-T11-4). The identifier checkpoint-total-mismatch SHOULD be used for a broken chain, which is the fourth condition its table row names.¶

14. If two successfully verified checkpoints share an epoch number and have different hashes, the verifier MUST report equivocation (MUST-T11-3). The identifier equivocation SHOULD be used for this condition. The checkpoints compared here are those presented together with any carried by verified witness receipts (step 15). Comparing only the presented chain cannot raise this finding: MUST-T11-8, applied in step 12, requires that chain's epochs to be consecutive, so no two of its members share an epoch. A copy recorded by a witness is where the second one is found.¶

15. If witness receipts were supplied, verify them against the out-of-band witness key (Section 10.3); receipts that cannot be checked that way are not evidence in either direction and the verifier reports that it left them out (MUST-T11-15); the identifier unauthenticated-witness SHOULD be used for this condition. Discard any whose signature fails (MUST-T11-10). A surviving receipt whose statement body verifies against the issuer root is a statement that issuer published; one that does not is another party's, and is not this issuer equivocating (MUST-T11-16). The survivors are the recorded statement hashes used in step 16. Where a receipt also carries the statement body, discard that body unless its statement hash equals the one the receipt binds and it verifies as a checkpoint; the surviving bodies are what step 14 compares. Discarding a body does not discard its receipt. This is tier 1 of Section 11.3. Where the tier-2 pair - the registered Signed Statement bytes and an inclusion proof - was also supplied, verify it as Section 11.3 states: apply the proof to the candidate entry's hash and accept only on an exact match with a witness-signed receipt (MUST-T11-18); a pair that fails, or a candidate without a proof, is witness-inclusion-invalid and the audit MUST fail. Where witness receipts were supplied and no tier-2 pair was, report witness-inclusion-not-exercised as a warning (MUST-T11-19): the witness attested the statement hash, and log membership was not proven.¶

16. Compare the surviving witness records against the presented chain (MUST-T11-11). For each presented checkpoint with no surviving record, report that it is not anchored; the identifier checkpoint-not-anchored SHOULD be used. This is a warning: a witness may have been configured after the checkpoint was issued, and an operator's own gap is not evidence of concealment. For each surviving record whose statement is absent from the presented chain, report that a recorded checkpoint was withheld; the identifier checkpoint-withheld SHOULD be used. This is a finding and the audit MUST fail. A record that carries no statement body cannot say whose statement it binds, so it MUST NOT produce this finding; it is reported as an entry that could not be attributed and makes the guarantee conditional, because a real withholding must not be buried by removing the body (MUST-T11-17). Such a record still establishes anchoring in the first half of this step: proving that a checkpoint was logged needs only its hash. The verifier MUST NOT report a withheld checkpoint as a window coverage failure (MUST-T11-11).¶

17. If any finding remains that is not a warning (a warning is a condition that only makes the completeness guarantee conditional), the audit MUST fail (MUST-T10-4).¶

11.5. Finding codes

The identifiers below are for diagnostic output. They are not an interoperability surface. A finding object that can be carried on the wire is outside the scope of this document and may be defined later. Two implementations interoperate when they accept the same inputs and fail or warn on the same conditions, not when they print the same strings.¶

A condition that makes the audit fail is a finding. A condition that only makes the completeness guarantee conditional is a warning. Warnings MUST still appear in operator-facing output (MUST-T10-14).¶

A finding that puts the extract itself in doubt (extract-key-mismatch, trust-key-unreadable, extract-scope-mismatch, or extract-settlement-mismatch) MUST also prevent an unconditional guarantee, not merely fail the audit. A finding that puts a presented Trade Manifest in doubt (manifest-key-mismatch, or trust-key-unreadable on the manifest pin) does the same.¶

An unconditional guarantee therefore requires all of: an extract, a pinned rail key the extract's signature verifies against, a stated period the extract covers, an issuer root for whatever receipts and checkpoints are presented, a manifest root for whatever Trade Manifest is presented, no finding that puts the extract in doubt, and no warning that withholds part of the comparison. A checkpoint whose totals were signed as withheld (checkpoint-totals-redacted) removes a comparison the guarantee rests on, and a presented checkpoint a supplied witness does not hold (checkpoint-not-anchored) leaves part of the chain unwitnessed. Either one makes the result conditional. Anything less than the whole list is conditional, and the report MUST say so.¶

An implementation MUST make the guarantee and any warnings visible in whatever human-readable audit report it produces under this document, not only in a returned structure (MUST-T10-14). A report that says the books balance while withholding that the balance is conditional invites the reader to take a conditional result for an unconditional one.¶

Checkpoints SHOULD be registered with a Transparency Service (SHOULD-T11-5). A test deployment MAY use an in-process append-only log as the witness (MAY-T11-6). Cedulon still MUST NOT take custody.¶

The guarantee named above is about completeness against the extract, which is the subject of T10. It is not a claim that no checkpoint was suppressed. Suppression is the subject of T11, and a report MUST NOT be read as settling it when no witness was consulted: with no witness receipts, the presented chain is self-consistent by construction and says nothing about what it left out (MUST-T11-9). A verifier that consulted a witness and found every presented checkpoint recorded, with nothing recorded that was not presented, has discharged T11 for the period those receipts cover, and for no longer.¶

16.1. T1: Prompt injection leads to unauthorized spend

16.2. T2: Runaway agent (loop spend)

16.3. T3: Replay of payment authority

16.4. T4: Receipt forgery or repudiation

16.5. T5: Policy bypass via direct rail access

16.6. T6: TOCTOU between policy check and payment

16.7. T7: Signing-key leakage

16.8. T8: Counterparty price gouging or defective delivery

16.9. MUST-T8-custody

Implementations of this specification MUST NOT take custody of funds or operate escrow. See also Section 16.13.¶

16.10. T9: PII leakage into the transparency log

See also Section 15.¶

16.11. T10: Secret spend via rail bypass

See Section 11.¶

In MUST-T10-4, a completeness finding that makes the audit fail is distinct from a warning that only makes the guarantee conditional. The verification algorithm states that distinction by behaviour (Section 11).¶

16.12. T11: Checkpoint suppression or rollback

Issuer self-attestation:

A Receipt Issuer that also produces the only copy of the extract can omit settlements. Completeness holds only against an extract the verifier obtained from the rail or from a rail signature.¶

Key rotation and revocation:

kid identifies the verification key. This -08 does not specify a revocation list. Verifiers MUST pin the issuer keys they accept and MUST stop accepting a kid after an authenticated revocation signal.¶

Timestamp trust:

timestampMs is issuer-asserted. Window assignment uses that field. A lying issuer can slide a receipt between windows. External timestamping of receipts is out of scope for this revision; the checkpoint witness covers checkpoints, not receipt timestamps.¶

Collusion:

If the rail operator and the issuer collude, they can publish a matching extract and receipt set that hides a real-world settlement. Cedulon does not detect extract-external agreement.¶

Reversal, refund, and partial settlement:

State machines for reversal, refund, and partial settlement are out of scope for this revision.¶

16.13. Optional escrow role

Parties MAY name an escrow actor in a Trade Manifest as a third-party role that holds funds under rules outside this protocol (MAY-T8-6). Implementations of this specification MUST NOT take custody or operate escrow (MUST-T8-custody).¶

16.14. T12: Settlement without a recorded receipt

The threats above are about a counterparty, a rail or an attacker. This one is about the issuer's own implementation, and it produces exactly the condition the rest of this document exists to make detectable.¶

An issuer that settles a payment, appends the receipt in memory and then persists its state has three steps where it could have two outcomes. If the write fails, the rail holds a settlement and the receipt exists nowhere durable. The next start reads a state that does not contain it, and the audit in Section 11 reports settlement-without-receipt against an honest issuer that did everything its own policy asked. The evidence is missing because the issuer lost it, not because anyone hid it, and nothing in the report can tell those apart.¶

Ordering:

Settle-then-record is the natural order to write and the wrong one to ship. The record is what makes the settlement accountable, so the record is what has to be secured first (MUST-T12-1), and a settlement that cannot be recorded has to be undone everywhere the issuer still controls, including the nonce and the allowance it never used (MUST-T12-2). That undo is what the in-process RailLedger and the session tests measure. Once value has entered a rail the issuer does not control, a local snapshot cannot retract it. Persistence failing after that point leaves the outcome indeterminate; authority is not returned without authenticated evidence that the rail did not complete the settlement or that a reversing entry did (MUST-T12-4).¶

Recovery:

A durable-state conflict is not necessarily fatal, but it MUST NOT be silent, and an implementation that refuses every subsequent write without offering a way back has turned a recoverable condition into an outage. The reason reported has to separate the cases an operator would act on differently (MUST-T12-3): a write that conflicted with another writer, a write that failed, and a state another process is holding. A single opaque failure leaves the operator to guess which of those happened.¶

Observability:

A violation of this threat is not visible in the evidence a verifier receives. The audit sees a settlement with no receipt and reports settlement-without-receipt, which is the same finding an adversary would produce, and nothing in the extract or the receipt set distinguishes an issuer that lost the evidence from one that hid it. That is why the requirements here fall on the issuer rather than on the verifier, and why an operator-facing reason is required rather than optional.¶

17.1. application/cedulon-receipt+cbor

Type name:

application¶

Subtype name:

cedulon-receipt+cbor¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

binary. A COSE_Sign1 structure [RFC9052] in deterministic CBOR [RFC8949], untagged, as profiled in Section 5 and Section 6.¶

Security considerations:

See Section 16 of this document. The object is signed; its evidentiary weight depends on the verifier holding the issuer key out of band (Section 10.1), never on a key the object carries.¶

Interoperability considerations:

The claim set is a CBOR map with the labels and types stated in Section 6.1, encoded per [RFC8949] Section 4.2.1. A decoder refuses a duplicate key (MUST-T4-18), an input beyond its stated bounds (MUST-T4-19), and a non-empty unprotected header (MUST-T4-21) by name rather than accepting it.¶

Published specification:

This document, Section 5.¶

Applications that use this media type:

Agent payment adapters, policy decision points, auditors, and dispute-evidence tooling that produce or verify Cedulon Spend Receipts.¶

Fragment identifier considerations:

N/A¶

Additional information:

Deprecated alias names for this type: N/A. Magic number(s): N/A. File extension(s): N/A. Macintosh file type code(s): N/A.¶

Person and email address to contact for further information:

Emek Can Dogru, e.dogru@cedulon.com¶

Intended usage:

COMMON¶

Restrictions on usage:

N/A¶

Author:

Emek Can Dogru¶

Change controller:

IETF¶

17.2. application/cedulon-checkpoint+cbor

Type name:

application¶

Subtype name:

cedulon-checkpoint+cbor¶

Encoding considerations:

binary. A COSE_Sign1 structure in deterministic CBOR, untagged, as profiled in Section 11.1 and Section 6; the same object is the payload of the Signed Statement Section 14 registers.¶

Security considerations:

See Section 16 of this document. A checkpoint carries the suppression guarantee for its window (Section 11.3). Its evidentiary weight depends on a pinned issuer key (Section 10.1) and never on the key it carries; where no such key is held the signature is still checked against the carried key, which establishes internal consistency only.¶

Interoperability considerations:

As for application/cedulon-receipt+cbor; the labels are those of the checkpoint table in Section 6.1, and totals signed as null is a redaction, not a malformed claim.¶

Published specification:

This document, Section 11.1.¶

Applications that use this media type:

As for application/cedulon-receipt+cbor, and transparency witnesses that co-sign or register checkpoints.¶

Required parameters, optional parameters, fragment identifier considerations, additional information, contact, intended usage, restrictions on usage, author, change controller:

As for application/cedulon-receipt+cbor.¶

17.3. application/cedulon-manifest+cbor

Type name:

application¶

Subtype name:

cedulon-manifest+cbor¶

Encoding considerations:

binary. A COSE_Sign1 structure in deterministic CBOR, untagged, as profiled in Section 4 and Section 6.¶

Security considerations:

See Section 16 of this document. A manifest is an offer signed before payment; it binds terms, not delivery, and is verified only against a publisher key held out of band (Section 10.5).¶

Interoperability considerations:

As for application/cedulon-receipt+cbor; the labels are those of the manifest table in Section 6.1, and the payee label is encoded only when present.¶

Published specification:

This document, Section 4.¶

Applications that use this media type:

Payees and marketplaces that publish signed offers to paying agents, and verifiers reconciling receipts against those offers.¶

Required parameters, optional parameters, fragment identifier considerations, additional information, contact, intended usage, restrictions on usage, author, change controller:

As for application/cedulon-receipt+cbor.¶

17.4. application/cedulon-decision+cbor

Type name:

application¶

Subtype name:

cedulon-decision+cbor¶

Encoding considerations:

binary. A COSE_Sign1 structure in deterministic CBOR, untagged, as profiled in Section 8 and Section 6.¶

Security considerations:

See Section 16 of this document. A Decision Token is consumed at the gate by the party that issued it (Section 10.4); it is not an input to the retrospective audit (Section 11.4), and a verifier that treated it as one would be claiming a check the audit does not make.¶

Interoperability considerations:

As for application/cedulon-receipt+cbor; the labels are those of the Decision Token table in Section 6.1, all five always present.¶

Published specification:

This document, Section 8.¶

Applications that use this media type:

Policy decision points and the payment adapters that consume their allow decisions.¶

Required parameters, optional parameters, fragment identifier considerations, additional information, contact, intended usage, restrictions on usage, author, change controller:

As for application/cedulon-receipt+cbor.¶

17.5. application/cedulon-countersign+cbor

Type name:

application¶

Subtype name:

cedulon-countersign+cbor¶

Encoding considerations:

binary. A detached COSE_Sign1 structure in deterministic CBOR, untagged, as profiled in Section 5.1, whose payload carries the exact issuer receipt octets it countersigns.¶

Security considerations:

See Section 16 of this document. A countersignature that does not verify under a payee key held out of band carries no evidentiary weight and cannot move the verdict on the receipt it travels beside (Section 5.1, Section 10.2).¶

Interoperability considerations:

As for application/cedulon-receipt+cbor; the optional deliveredHash claim is a 32-octet byte string and is read as absent when it is not.¶

Published specification:

This document, Section 5.1.¶

Applications that use this media type:

Payees that acknowledge a receipt and, optionally, bind the bytes they delivered.¶

Required parameters, optional parameters, fragment identifier considerations, additional information, contact, intended usage, restrictions on usage, author, change controller:

As for application/cedulon-receipt+cbor.¶

17.6. application/cedulon-inclusion+cbor

Type name:

application¶

Subtype name:

cedulon-inclusion+cbor¶

Encoding considerations:

binary. A COSE_Sign1 structure in deterministic CBOR, untagged, as profiled in Section 6, whose payload is the three-entry map Section 11.3 states: statement hash, entry index, tree head.¶

Security considerations:

See Section 16 of this document. A witness receipt verified under the key it carries establishes that some log is internally consistent and nothing about which log; it carries evidentiary weight only under a witness key held out of band (Section 10.3, MUST-T11-15). It attests a statement hash, not membership in an append-only log; membership is tier 2 of Section 11.3 and needs the candidate statement and an inclusion proof beside the receipt.¶

Interoperability considerations:

As for application/cedulon-receipt+cbor, except that the payload is not a CWT claim set: its three labels are local to the map and are stated, with their types, in Section 11.3.¶

Published specification:

This document, Section 11.3.¶

Applications that use this media type:

Transparency witnesses that co-sign the statements they record, and verifiers that hold witness receipts for a period under audit.¶

Required parameters, optional parameters, fragment identifier considerations, additional information, contact, intended usage, restrictions on usage, author, change controller:

As for application/cedulon-receipt+cbor.¶

18.1. Changes from -07

This revision has one subject. It widens MUST-T10-19 from the two surfaces -07 named to every structure an implementation returns for an audit, and it states one shape rule the half-open window already implied: an extract whose window does not end after it starts declares no population and is refused as malformed by name. That rule was measured before it was written - a correctly signed extract with its window inverted and no rows came back from the companion as a balanced audit under an unconditional guarantee - and the companion refuses it at both ends from 0.10.0.¶

-07 had the report carry the account, rail and window it was computed over in the printed report and in the finding object, and said in its own change note that the companion's MCP result and ledger export returned the finding list and the guarantee without a scope field, and that a revision widening the requirement to every returned structure would ship with the package that carries it. This is that revision. The reasoning did not change between the two: the strongest line an audit prints is true of one account on one rail over one window, and a structure that carries the verdict without the population it was measured over can be read as a statement about paths the audit never looked at. That reading is available on any surface the verdict travels on, not only the two -07 named, so the requirement now names them all.¶

What the requirement asks of a structure computed with no extract is nothing: there is no declared population, and the structure names none. The companion's MCP cedulon_audit result carries scope exactly when the audit ran over a presented extract, which that tool now accepts as an input, and it refuses rows added beside such an extract rather than reconciling them, on the reasoning MUST-T10-20 gives from the other side. Its ledger export is unchanged: that export's audit is always over the in-process ledger, which declares no population, so it has nothing to name, and a member that is always absent would say nothing. The requirements table row, the third step of the verification algorithm and the abstract say the widened form, and the extract shape paragraph of Section 9 states the window rule. The Implementation Status section is re-measured for this revision, the sentences that name the revision are renumbered, and no other text moved.¶

18.2. Changes from -06

This revision has three subjects. The first repairs a wording residue that -06's own repair created, reported by the reader who implemented -06 from the posted text; it changes no behaviour. The second adds three requirements on the rail path: two on an axis of the audit's declared scope that every earlier revision left unstated, and one on what a verifier may read out of an extract its pinned key refused. The third states the wire form of the witness receipt, which every earlier revision described and none encoded, and registers its media type.¶

-06 stated, for the first time, what a verifier does when it holds no pinned issuer key: the signature is still checked against the key the object itself carries, which establishes internal consistency and nothing about who signed it (Section 6.3, Section 10.1). Seven places in the same document still carried the older absolute formulation, under which no signed object may be verified against a key it carries at all. Read literally, those seven forbade the check the other two had just defined, and two implementations following different halves of the document would produce different findings from the same evidence.¶

• The Abstract said no signed object may be verified against a key it carries itself. It now says no signed object is attested by one.¶

• The opening paragraph of Section 10.1 stated the prohibition without the no-pin case. It now separates the two: a carried key is neither an identity nor a fallback for a pin (MUST-T4-9, MUST-T4-11), and where no key is held the check that runs establishes internal consistency only.¶

• MUST-T4-9 carries the same split, in the requirement's own words.¶

• MUST-T10-8, the paragraph of Section 9 that introduces it, and the opening of Section 10 carried the identical residue on the rail path, in three places, where it was not reported: an extract presented under no pinned rail key is verified against the key it carries, and the implementation says so in its own warning. The requirement and both paragraphs now separate identity from internal consistency the same way, and name unauthenticated-extract as the condition; MUST-T10-7, step 2 of the verification algorithm and the unauthenticated-extract row of the finding table say the same.¶

• The application/cedulon-checkpoint+cbor template in Section 17 said a checkpoint is verified only against a pinned issuer key. It now states the same split as Section 10.1.¶

The witness root already stated the distinction correctly and is unchanged; it is where the wording for the other seven came from. The manifest root (Section 10.5) and MUST-T4-15 keep their absolute wording on purpose: a Trade Manifest presented under no publisher pin is not checked against the key it carries at all, so there is no internal-consistency check to describe there, and unauthenticated-manifest says so.¶

The second subject is the scope a completeness result is over. -05 established that a verifier which states no period cannot call its result unconditional, because the extract then defines the period it reports on (MUST-T10-15). The account and the rail are the same kind of axis and were never given the same treatment: an extract names one account and one rail (Section 9), so a verifier that states neither leaves the extract to define whose settlements were accounted for and which way out was watched. MUST-T10-18 closes that axis the way -05 closed the period.¶

MUST-T10-19 states the consequence the earlier revisions left to the reader. A balanced audit under an unconditional guarantee is true of one account, on one rail, over one window. An account that can settle on a second rail has a settlement path no presented extract covers, and a spend that left that way is not an unmatched row - it is outside the declared population, which is precisely the bypass Section 16 names in T10. The report now carries the account, rail and window it was computed over, in the printed report and in the finding object, so the strongest line it prints cannot be read as a statement about paths it never looked at. Those two surfaces are the ones the requirement names; the companion's MCP result and ledger export return the finding list and the guarantee without a scope field, and a revision that widens the requirement to every returned structure will ship with the package that carries it. Enumerating an account's rails remains the deployment's statement; no extract can be asked to prove that the enumeration is complete.¶

This distinction is the one [ABAK] draws for control instructions, where a receiver-side observation at one enforcement point does not establish that another required path was reached.¶

MUST-T10-20 closes the other gap on the same path. -06 reported an extract that a stated rail pin refused as extract-key-mismatch and said nothing about what that document's rows could still be used for, so a verifier could reject the extract and then convict with it: a mismatch against a receipt, money reported as unaccounted for, a receipt left unmatched by rows the refused document omits. The refusal is now the finding, no settlement finding is read out of that body, and the verifier reports settlement-comparison-skipped in the same result, so that a comparison which never ran cannot be mistaken for one that found nothing. It is MUST-T8-9's rule for a refused Trade Manifest, on the money axis and for the same reason.¶

The witness receipt of Section 11.3 has been described since -02 as a receipt binding the statement the witness recorded, and since -05 as a COSE_Sign1 binding a statement hash, an entry index and a tree head; every revision left its encoding to the reader. The companion implementation, at its published 0.9.0, issues and verifies that object under the content type application/cedulon-inclusion+cbor, a name no revision registered over a payload no revision stated, while Section 6 makes the content type a normative check inside a protected header (MUST-T4-8). Section 11.3 now states the payload as issued, Section 6 lists the name beside the other five, and Section 17 requests its registration as the sixth template. No behaviour changes for objects already issued. The encoding is stated as it ships: hashes as hexadecimal text strings, and three small positive labels that are local to the map rather than CWT claims. A later revision may move the hashes to byte strings and the labels into the private-use range the other objects use; it will do so in step with a package release, and will say so here.¶

Also in this revision: the note on distribution in Section 18 now says that what -05, -06 and this revision add is in the published packages at 0.9.0, where -06 said those items were in the repository and in no package, 0.8.0 and 0.9.0 having been published after it was posted; Related Work cites [ABAK]; and Section 19 points at -08 or later.¶

18.3. Changes from -05

This revision has one subject on the wire, one at the registry, and one repair to what the text claimed about verification without a pinned key. On the wire it adds two decoder rules, each the named refusal of a surface the posted -05 left implicit; at the registry it turns the placeholder table of -05's IANA section into the registration requests [RFC6838] asks for. Both rules landed red-then-green in the companion implementation before they were written here, and each came from reading rather than from a reader: the first from running the canonicalization vectors of a neighbouring draft [CPB] through this profile's own [RFC8785] encoder, the second from measuring what would change if the digests of Section 7.1 were taken over the COSE ToBeSigned structure instead of the signed octets. That second question is not answered in this revision; what the measurement found on the way is.¶

• JSON text gains the rule CBOR already had. [RFC8785] takes I-JSON [RFC7493] as its input, and an I-JSON object carries no duplicate member names; a verifier that receives a JSON document as text now refuses a text in which any object repeats a member name, by the name json-duplicate-key, before parsing it (MUST-T4-20, Section 7, Section 9). -05 was silent, and the companion refused such texts anyway; its conformance runner carried that difference as a recorded split against the posted -05, and this sentence is what the split was waiting for. The rule is measured on the text because a parser that keeps either value has already discarded the evidence of the other.¶

• The empty unprotected header became a decoder rule rather than an encoder promise. Every digest over a signed object covers the unprotected header and the signature does not, so a decoder that verified the signature and ignored a stuffed header would compute a receiptHash the issuer never produced. A COSE_Sign1 whose unprotected header is not an empty map is refused as cose-sign1-unprotected (MUST-T4-21, Section 6). The companion decoder had ignored the header. The vectors in Appendix A are unchanged, because every one of them carries an empty one.¶

• Section 17 states a full [RFC6838] template for each of the five media types and requests their registration in the standards tree, and says of the claim labels that they lie in the Private Use range of [RFC8392] and are not requested. -05 listed the names and said they should be registered if the work were taken up.¶

• What a verifier holding no pinned issuer key does is now stated as measured, in one wording rather than two. The verification path said no signature comparison happened at all; the finding-code table said the objects were checked against the keys they carry. Measurement settled the two in opposite directions, so both were rewritten rather than reconciled to either: a receipt or checkpoint signature is checked against the key its own object carries, which is why a broken signature is still named while two issuers cannot be told apart, and a presented Trade Manifest with no pinned publisher key is not checked at all. Neither statement is a new requirement; both describe what Section 11.4 already did. Sweeping the rest of the table the same way found one more row describing one branch of three: unauthenticated-extract is reported for an extract whose signature verifies under no pinned rail key, for one that does not, and for a pinned rail key with no extract presented at all, where -05 named only the unsigned case and sent the pinned case to extract-key-mismatch, which is where a presented extract that fails under a pin goes and the only one of the three that lands there.¶

• Two more rows say what a pinned issuer key does to a checkpoint. A checkpoint that does not verify under the pin, whether because it was signed by another key or because its bytes were altered, is issuer-key-mismatch and leaves its window uncovered; it never reaches the totals comparison, so the signature branch of checkpoint-total-mismatch belongs to the unpinned path. The pin table in Section 10.1 described only the receipt outcome for that cell, because a checkpoint has no chain walk to be named in. The companion also carried an operator-facing message asserting that an unpinned manifest's signature proved internal consistency, which the same measurement shows it never checks; the message now says so, red before green.¶

• Section 6.3 defines the carried key those statements turn on. Every presented receipt, checkpoint, Trade Manifest and Decision Token carries the signer's SubjectPublicKeyInfo PEM beside its signed octets, and Section 10.1 has named a warning for that key since -05 without any revision saying where the key came from: -05 defined such a member only for the Rail Extract. The state the unpinned cell names, presented-unattested, is likewise defined in the terminology rather than used once.¶

• A Trade Manifest refused by a stated publisher pin no longer founds a charge. Its body was still supplying the terms comparison of MUST-T8-9 and the acceptance-criteria hash behind delivery-mismatch, so a manifest anyone could mint, presented beside an honest receipt, produced two hard findings against the payee while the same report refused the document as manifest-key-mismatch. That is the shape this profile closes everywhere else: evidence nothing stands behind must not manufacture a negative result. The requirement says so where the charge is defined, and the companion stops reading the body at the refusal, measured red before green.¶

• Six more finding-code rows were swept the same way as the three above and named the branch they were missing: the refused chain head under checkpoint-head-mismatch, cover reported on presentation rather than on attribution, the payee branch of the terms comparison, the four fields extract-settlement-mismatch actually compares, the unpinned half of unstated-audit-window, and what witness-inclusion-not-exercised does and does not say about verification. Two operator-facing messages stopped reporting states the same report contradicted: a reconciliation that had not closed and a witness attestation nothing had verified.¶

• Section 18 names what this revision adds as not yet in a published package, on the same terms -05 used for its own additions, carries the suite size measured at the commit it describes, and records the conditions of the outside vector run and of the regeneration of a vector from this text alone.¶

18.4. Changes from -04

All but the last three changes in -05 answered a first-failure list filed against the posted -04 by an independent reader who ran the Appendix A vectors against the exact archive bytes before reading the text: eight points where an implementation could no longer be built from the text alone, one question, and three mechanical defects. The last three answered a counter-reading of -05, made from the text alone before it was posted, and a reply on the DISPATCH list. The repairs landed red-then-green in the companion implementation before the sentences below were written, and the shapes in the text are taken from what the implementation measurably does.¶

• The transparency receipt path stopped promising [RFC9942] mechanics it did not perform. Section 11.3 now names two tiers: the witness receipt (a co-signature over the statement hash, and nothing more) and log membership (candidate Signed Statement bytes plus an inclusion proof, verified by RFC 9942 Section 5.2.1 mechanics against a witness-signed tree head, with exact receipt-matching stated as normative). Where tier 2's inputs are absent, the report says the tier was not exercised (MUST-T11-18, MUST-T11-19).¶

• Key resolution in step 4 collapsed to one rule - membership in the attested set follows verification under the pinned root - read out cell by cell in a table, each cell a named condition plus a membership decision, never a silent removal. The carried key is not an identity source: swapping it on an honestly signed object is carried-key-mismatch, a warning, and cannot move the object out of the attested set (Section 10.1).¶

• The Rail Extract body has one normative shape. Table 8's member names bind the rail; the sentence that said the names were the rail's to define is withdrawn; the full signed body - members, types in JSON terms, and the signature representation - is stated in Section 9.¶

• "Issuer order" is defined as the order induced by the prevReceiptHash chain; presentation order carries no weight, and chainHeadHash binds to the last link of the chain in the window. The window-coverage check is stated as fail-closed, zero checkpoints and the open epoch included. The claim that no other step fed another is withdrawn for the maintained dependency list.¶

• The window boundary stopped manufacturing accusations out of two honest clocks: membership follows the ref binding first, and an unmatched item within the extract-declared clockSkewMs of the edge is boundary-deferred: a closing-edge item resolves against the following window's extract, an opening-edge item only against a receipt in the presented bag (MUST-T10-17).¶

• An appended countersignature can no longer fail an honest audit. Attribution gates evidentiary weight; an unattributable countersignature is discarded with a warning, the pinned expectation stays open, and the verdict on the issuer receipt does not move (Section 5.1).¶

• The counterparty triangle is closable and honestly scoped: an optional manifest payee, an optional settlement-record beneficiary, and a counterparty-unbound scope record when neither is present.¶

• The delivery claim shrank to its evidence and the evidence grew: an optional deliveredHash on the countersignature makes the acceptance comparison signed-to-signed (MAY-T8-11), and the Introduction conditions "what bytes were delivered?" on that evidence being present.¶

• "Allowed by policy" is stated as the Receipt Issuer's signed assertion, with the trust boundary named: the audit does not independently verify the PDP's allow, and a receipt-to-token binding is a possible extension, not -05.¶

• Mechanical: the hash-claim grammar (64 lowercase hex) moved into the signers and validators, named per claim, and the Appendix A receipt vector - which violated Table 3 in the posted -04 - is regenerated with a computed digest. MAY-T8-9 is renumbered MAY-T8-10; the number collided with MUST-T8-9 and the requirement text did not change. The lone-surrogate escape permission contradicted [RFC8785] Section 3.2.2.2 and is removed: producers refuse by name, verifiers report rather than crash (Section 7).¶

• The extract's time fields are refused at the shape gate when they are not integers, the way the tables already named them: a counter-reading found that 1.5 and NaN passed a number check and were signed. windowStartMs, windowEndMs, each record's timestampMs, and clockSkewMs are now refused by name unless they are integers of magnitude at most 2^53 - 1, and clockSkewMs unless it is also non-negative; the canonical-encoding refusal for non-finite numbers still guards members the rail adds.¶

• An opening-edge deferral is closed only by a receipt in the presented bag. The implementation had let a following window's extract harden it into settlement-without-receipt; the text's reason for the deferral, ref binding, never said so, and the seven edge cases are locked as tests.¶

• The abstract no longer says that payment rails and mandate protocols lack a fail-closed policy check; a mandate protocol has one, and returns signed receipts. It names the missing piece as what a party that is neither payer nor rail operator can retrieve and reconcile against an authenticated rail extract. A reply on the DISPATCH list narrowed the claim, and the narrowing is right.¶

18.5. Changes from -03

-04 had one subject: -03 could not be implemented from its own text. Eighteen decision points were read out of it by someone working from the words alone, and eight of them had two defensible answers. Nothing here adds a capability. Everything here closes a place where two conforming implementations would produce different bytes or reach different verdicts.¶

Five of those eight were the same defect wearing different clothes. -03 hashed or signed a JSON document in four places and called the encoding "canonical" without ever defining it, and named the digest for some hash-valued fields and not others. Section 7 defines the encoding by reference to [RFC8785], and Section 7.1 states, for every hash-valued field, exactly which octets go in. The heaviest of those was requestHash: -03 called it "the six-field hash" in the same sentence that named SHA-256 for policyHash, and a reader was entitled to conclude it was not a digest at all.¶

MUST-T8-9 changes in a way a diff will show, and the change is deliberate. -03 said an unpinned departure from manifest terms fails the audit, full stop. An implementation showed what that permits: a receipt signed by any key, carrying the right manifest hash and a wrong amount, makes a verifier report a breach that never happened against a payment reference the forger picks. The requirement now separates the two cases and says why it differs from MUST-T4-17, which is a naming question rather than a charge and is answered from the presented set whether or not anything vouches for it.¶

MUST-T4-18 and MUST-T4-19 are new: -03 bound the encoder to deterministic CBOR and said nothing about the decoder, neither about a duplicate key nor about what a decoder does when an input is larger than it is willing to read. The second fixes no numbers. A bound is deployment policy; refusing by name rather than by running out of stack is not.¶

MUST-T3-3 and MUST-T8-2 gain the boundary and the comparison rule they were missing: whether a settlement exactly at expiry is inside the manifest, and whether a currency may be case-folded before it is compared. MUST-T10-1 says what an audit with nothing in it reports.¶

The acceptance-criteria hash had two readings and no way to signal which one was used, so two implementations would have hashed the same delivery differently. This revision defines one of them and puts the other out of scope until something can say which is meant.¶

The verification algorithm now names its data dependencies. -03 named one and said nothing else fed another step, which stopped being true once the issuer pin began deciding the attested set: the chain walk, the reconciliation, the checkpoint comparisons and MUST-T8-9 all consume it, and the algorithm now says so, along with the two checks that deliberately stay on the presented set. The two severities of MUST-T8-9 are now stated in the algorithm step and the finding table as well as in the requirement, after an early draft of this revision changed the requirement and left the step and the table carrying the old unconditional verdict.¶

Three encodings that could be read two ways are now stated once each: kid is the SHA-256 of the SubjectPublicKeyInfo DER truncated to its first 8 bytes, in that order; "the signed COSE_Sign1 octets" are the untagged array, never tag 18; and the six-field request document is given as an exact JSON shape, member by member, rather than as a list of names. The hash-input table now covers acceptanceCriteriaHash and says whose digest ap2MandateHash is. The Decision Token gains the same expiry boundary MUST-T3-3 states for the manifest.¶

Appendix A no longer defers to the tests of an implementation; a specification that points at code cannot be implemented from its own text, which is the property this revision is trying to restore.¶

One change is metadata rather than text: the submission stream in the document's header changes from independent to IETF. The Note to Readers has named an eventual Standards Track intent since -00, and Section 17 asks for Standards Tree registration; neither belongs on the Independent Stream. The rendered pages are unchanged by it.¶

What has not changed: MUST-T12-4 remains specified and not executed, and this document still has no independent implementation written from its text alone. The point of this revision is to make that possible, not to claim it happened.¶

18.6. Changes from -02

-03 had two subjects. The first is that -02 stated a rule for signed objects and left the implementation and the verification algorithm without a counterpart for every object the rule applied to. The second is T12, which no reader reported and which is not about an adversary at all.¶

-02 Section 6.2 already required a verifier to obtain the public key from an authenticated channel (a preconfigured issuer set, a directory, or a transparency statement) and to reject a message whose kid does not match that key (MUST-T4-8). That rule was general. What -02 did not carry was the verification algorithm that applies it to each signed object, the separate root inputs a verifier supplies out of band, and the error semantics that name a missing, unreadable, or mismatched pin. A companion implementation that followed the algorithm it had, rather than that prose, still checked a Spend Receipt, an epoch checkpoint, a Decision Token and a transparency inclusion receipt against the key travelling inside them. A receipt like that silences the settlement-without-receipt finding for the settlement it names. The completeness property is then computed over evidence that answers to nobody. Section 10 states the missing algorithm and the error semantics, and the verification algorithm now applies them.¶

A reader raised the inclusion-receipt half of this against the posted -02 after checking the archived text against the implementation commit. Following it into the code turned up the other three, along with two conditions that were not about keys at all.¶

The first is that reporting a mismatch is not enough. An implementation that names a foreign key and then still lets the receipt match its settlement has described the attack in its output while concluding that the books balance. MUST-T4-10 now requires the settlement to stay reported.¶

The second is that an expectation which only fires when the evidence is present can be cancelled by deleting the evidence. A pinned payee key with no countersignature to check was silence, so removing a countersignature removed the question with it. MUST-T4-14 closes that, and MUST-T11-17 closes the same shape in the witness: an inclusion receipt with its body stripped off can no longer bury a withholding, while still not being allowed to accuse anyone.¶

T12 is new and is not about an adversary. An issuer that settles, appends the receipt in memory and then writes its state will, when that write fails, leave the rail holding a settlement whose receipt exists nowhere durable. Restarted, it reports settlement-without-receipt against itself. The condition this document exists to make detectable was reachable through the implementation's own ordering, and no requirement in -02 said otherwise.¶

The same first subject carries five requirements this section has not named so far, all of them stated in Section 10. A pinned key that cannot be decoded MUST NOT fall back to the keys the objects carry (MUST-T4-11). An issuer root may comprise more than one key, and a verifier must accept one that does, so a rotation inside the audited window does not force it to choose between findings against honest receipts and abandoning the pin (MUST-T4-12); the same set-of-keys acceptance applies to a publisher, witness, or rail pin. The same out-of-band rule reaches the payee countersignature (MUST-T4-13), the transparency witness (MUST-T11-15 and MUST-T11-16), the Decision Token, whose consumer issued it and therefore already holds the key to check it with (MUST-T6-6), and a presented Trade Manifest (MUST-T4-15).¶

Two requirements belong to neither subject. MUST-T7-5 and MUST-T7-6 come from measuring the protection a stored signing key actually has instead of deriving it from the platform. A mount that ignores filesystem permissions accepts the call and protects nothing, and a writable directory or a symbolic link anywhere on the path makes the file permission moot. They are stated because the implementation reported protection it did not have.¶

Two things are stated here that -02 got right and -03 kept unchanged: the extract rule itself, and the treatment of a pinned key the verifier cannot decode. What changed is their reach, and the change is not backward compatible. Where a verifier pinned the rail key, supplied no issuer key, and was presented with receipts or checkpoints, -02 reported the guarantee as unconditional and -03 reports it as conditional. Nothing about the evidence changed; what changed is that the guarantee now says which questions were never asked. An audit presented with neither is unaffected, for the reason given in Section 10.1.¶

18.7. Changes from -01

-02 had one subject: the checkpoint, which carries the T11 guarantee against suppression and rollback, was not wired into anything that could discharge it.¶

A reader of -01 set out the gap and a second reader confirmed it independently. Four things were wrong at once, and they were the same thing seen from four sides. The SCITT anchoring section profiled the Spend Receipt and not the checkpoint, so SHOULD-T11-5 asked for checkpoints to be registered without saying in what form (MUST-T11-14 now says). None of the steps of the verification algorithm read a witness receipt, so a deployment could follow SHOULD-T11-5 to the letter and still have a verifier that never consulted the witness (steps 15 and 16 now do). MUST-T11-3, equivocation, could not fire at all: the only checkpoints compared were the presented ones, and MUST-T11-8 requires those to be consecutive, so no two of them can share an epoch. A second copy is found in a witness, and nothing brought one in. And the checkpoint binds a per-currency total for a window while the privacy section counted only receipt fields, so a window total could be published, or withheld, with no stated rule either way.¶

The repairs are MUST-T11-10 through MUST-T11-14. The transparency receipt is a new optional input; supplying none leaves the verifier behaving exactly as in -01, which is deliberate, because the point of the witness is to add a claim that could not be made before, not to withdraw one that could.¶

Two decisions inside those repairs are worth stating on their own, because a reader might reasonably have expected the other choice.¶

• A recorded checkpoint the presented chain omits gets its own identifier, checkpoint-withheld, rather than being folded into window-coverage (MUST-T11-11). The reporter asked which way it should go. Coverage says the record shown is incomplete; a withheld checkpoint says the party under audit is holding a record it did not show. An operator who sees one identifier for both cannot tell an incomplete record from a concealed one, which is the distinction the whole threat is about.¶

• A checkpoint with no receipt in a supplied witness is a warning rather than a failure. A witness may be configured after checkpoints have already been issued, and an operator's own gap in anchoring is not evidence that anything was concealed. The asymmetry is deliberate: what the witness holds and the chain does not is a finding, what the chain holds and the witness does not is a warning.¶

One change is not a repair of -01 but of the first attempt at this revision, and it is recorded because the failure is instructive. Signed totals were first made redactable through a field carried alongside the checkpoint rather than inside the COSE payload. Anything outside the signature is chosen by whoever presents the object, which here is the party under audit, so a checkpoint whose signed totals disagreed with its receipts could be re-presented as redacted and the mismatch went unreported. Redaction is now inside the signature and a redaction asserted anywhere else MUST be ignored (MUST-T11-12, MUST-T11-13). This was the same shape as the bypass -01 was written to close: a check that a party under audit could switch off.¶

Reversal, refund, partial settlement, and the escrow role remain out of scope and are still expected later, with no date. -01 said the same, and no revision since has improved on it.¶

The reporters are named in the Acknowledgments.¶

19.1. Re-attestation profile

Algorithms retire. A Spend Receipt or checkpoint signed under Ed25519 today may need a later verifier that no longer accepts -19. A companion seed [REATTEST] sketches re-attestation: register the original COSE bytes as a SCITT Signed Statement and have a current algorithm countersign or receipt them. The principle is that structures outlive ciphers. The first concrete example is the profile's own move from generic EdDSA (-8) to Ed25519 (-19) in [RFC9864].¶

19.2. Streaming reconciliation

Epoch checkpoints in this document are batch windows. A later revision may define a continuous, second-scale profile [STREAMING] in which the same completeness relation is evaluated as settlements arrive, without waiting for an epoch close. That work does not change the matching rules in this document, and it did not arrive in this revision either.¶

19.3. Generalization

Payment is the special case that this -08 implements. The same completeness calculus (an authenticated extract of consumed units reconciled to signed receipts) can apply to other consumable resources such as compute, data, or energy. This document does not specify those profiles.¶

21.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC6234]

Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/rfc/rfc6234>.

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/rfc/rfc6838>.

[RFC7493]

Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/rfc/rfc7493>.

[RFC8032]

Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/rfc/rfc8032>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8392]

Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.

[RFC8410]

Josefsson, S. and J. Schaad, "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure", RFC 8410, DOI 10.17487/RFC8410, August 2018, <https://www.rfc-editor.org/rfc/rfc8410>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC8949]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/rfc/rfc8949>.

[RFC9052]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/rfc/rfc9052>.

[RFC9053]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, August 2022, <https://www.rfc-editor.org/rfc/rfc9053>.

[RFC9864]

Jones, M.B. and O. Steele, "Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)", RFC 9864, DOI 10.17487/RFC9864, October 2025, <https://www.rfc-editor.org/rfc/rfc9864>.

[RFC9942]

Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "CBOR Object Signing and Encryption (COSE) Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026, <https://www.rfc-editor.org/rfc/rfc9942>.

[RFC9943]

Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, <https://www.rfc-editor.org/rfc/rfc9943>.

21.2. Informative References

[ABAK]

Abak, A. T., "Evidence Requirements for Agent Control Delivery and Outcome Reconciliation", August 2026, <https://datatracker.ietf.org/doc/draft-abak-agent-control-delivery-evidence/>.

[ACTA]

Farley, T., "Signed Decision Receipts for Machine-to-Machine Access Control", June 2026, <https://datatracker.ietf.org/doc/draft-farley-acta-signed-receipts/>.

[AP2]

Google Agentic Commerce, "Agent Payments Protocol (AP2)", September 2025, <https://ap2-protocol.org/ap2/specification/>.

[BATES-ATP]

Bates, D., "Agent Transaction Protocol (ATP)", May 2026, <https://datatracker.ietf.org/doc/html/draft-bates-atp>.

[CPB]

Mih, S. and A. Sokolov, "Canonical Payload Binding: A Signed Statement Construction Profile", August 2026, <https://datatracker.ietf.org/doc/draft-mih-sokolov-scitt-payload-binding/>.

[GRIGG]

Grigg, I., "Triple Entry Accounting", 2005, <https://iang.org/papers/triple_entry.html>.

[HOPLEY]

Hopley, C., "Categorical Compliance Screening Receipt Format for Agentic-Payment Flows", May 2026, <https://datatracker.ietf.org/doc/draft-hopley-x402-compliance-receipt/>.

[MARQUES]

Gomes Marques, J. A., "Compliance Profile of Signed Action Receipts for AI Agents", July 2026, <https://datatracker.ietf.org/doc/draft-marques-asqav-compliance-receipts/>.

[PACIOLI]

Pacioli, L., "Summa de arithmetica, geometria, proportioni et proportionalita", 1494.

[REATTEST]

Dogru, E. C., "Cedulon Re-Attestation: Carrying Spend Evidence Across Algorithm Retirement", August 2026, <https://github.com/dogrucanemek-alt/cedulon/blob/e681e24d1b29912d8c190259c2ea9f4f9538c29d/spec/draft-dogru-cedulon-reattestation-00.md>.

[RFC7942]

Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/rfc/rfc7942>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[RFC9421]

Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.

[SCHROCK]

Schrock, I., "Outcome Binding for Authorized Actions and Independently Observed Effects", July 2026, <https://datatracker.ietf.org/doc/draft-schrock-ep-outcome-binding/>.

[STREAMING]

Dogru, E. C., "Cedulon Streaming Reconciliation: Continuous Completeness for Agent Spend", August 2026, <https://github.com/dogrucanemek-alt/cedulon/blob/e681e24d1b29912d8c190259c2ea9f4f9538c29d/spec/draft-dogru-cedulon-streaming-00.md>.

[VAUBAN]

Vauban Research, "x402 STARK Receipt Format Extension", May 2026, <https://datatracker.ietf.org/doc/draft-vauban-x402-stark-receipts/>.

[X402]

x402 Foundation, "x402: An Open Standard for Internet-Native Payments", 2026, <https://www.x402.org/>.