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 a canonical encoding (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-9). The profile uses a detached COSE_Sign1 [RFC9052] whose payload is a CBOR map with a single private-use label:¶

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-9). If a countersignature is present, a verifier MUST reject it when the signature fails, when kid or content type does not match the configured payee key, or when label -70401 is not the issuer COSE bytes (MUST-T8-8). The identifier countersign-bad SHOULD be used for this condition. 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 in -02. Cedulon uses CWT private-use integer labels less than -65536 so that the profile does not occupy the 100-110 registry range.¶

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, or application/cedulon-countersign+cbor¶

• 4 (kid) = bstr, mandatory. The profile computes kid as the first eight bytes of SHA-256 over the issuer's SubjectPublicKeyInfo DER. 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. 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].¶

8.1. Record schema

Each settlement record MUST contain:¶

8.2. Scope

An extract is scoped to one account identifier, one rail identifier, and one half-open time window [windowStartMs, windowEndMs).¶

8.3. Authentication

The mock rail in the companion implementation signs the extract with Ed25519 over a canonical encoding of the scoped body. 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 rather than against any key the extract carries (MUST-T10-8). A verifier that holds no such key 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 an extract that does not carry a verifiable signature is unauthenticated-extract, 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 this revision makes the pinned case fail closed. See Section 15.¶

8.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.¶

9.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 rather than against a key the object carries (MUST-T4-9). 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.¶

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.¶

9.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 countersignature MUST be reported (MUST-T4-14). Otherwise an attacker removes their own failed forgery and the report returns to unconditional.¶

9.3. The witness root

Section 10.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).¶

9.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).¶

9.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; a hash on an aborted receipt or on a receipt outside the extract window 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. 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 presented 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 and the audit fails. 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.¶

9.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.¶

10.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, 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.¶

10.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 transparency receipt, so the witness had no way to speak. -02 gave it one. A verifier that holds transparency 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 10.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.¶

10.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 13). The service returns a receipt [RFC9942] that binds the statement it recorded.¶

A verifier MAY be given such 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.¶

What such a receipt 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, and whether that log has ever equivocated, are properties of the service and its own proofs, not of Cedulon. A verifier that treats a signed receipt as proof of log membership is claiming more than the receipt carries.¶

10.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.¶

One data dependency is worth naming, because "any order" read naively would break it. Step 15 decides which transparency receipts, and which statement bodies, survive checking. Steps 14 and 16 consume what survives. An implementation that ran step 14 against unchecked bodies, or step 16 against unchecked receipts, would not produce the same set of findings, so that order is not among the permitted ones. Nothing else in this list feeds another step.¶

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 verifier MUST treat the completeness guarantee as conditional (MUST-T10-7). The identifier unauthenticated-extract SHOULD be used for this condition in diagnostic output. 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. 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.¶

4. Decode each Spend Receipt COSE_Sign1. Reject if Ed25519 verify fails, if kid does not match the configured issuer key, if the content type is not the receipt type, or if the decoded claim map does not match the presented claims (MUST-T4-2, MUST-T4-8). Then apply the issuer root (Section 9.1): verify the signature against the out-of-band issuer key rather than the key the receipt carries. A receipt that does not verify against it is reported and is excluded from the reconciliation that follows, so the settlement it names is still reported as uncovered in step 8 (MUST-T4-9, MUST-T4-10). With no issuer key pinned the verifier makes no such distinction and reports that it did not; where any receipt or checkpoint was presented, the guarantee is conditional on the terms in Section 9.1. Where a countersignature is present, Section 9.2 governs what it establishes (MUST-T4-13, MUST-T4-14). Where a Trade Manifest is presented, Section 9.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 or expiry is reported as manifest-terms-mismatch and fails the audit (MUST-T8-9). An audit presented with no Trade Manifest is not made conditional by this step.¶

5. Scope the receipts. When an extract is supplied, only receipts whose timestampMs falls in the extract's declared window are reconciled against it (MUST-T10-16). A receipt outside that window is not a completeness failure against this extract; auditing a longer period requires extracts that cover it. Receipts remain subject to every other check regardless of window.¶

6. Walk receipts in issuer order. The first prevReceiptHash MUST be null. Each later prevReceiptHash MUST equal receiptHash of the previous receipt. A miss MUST be reported as a break in the receipt chain. The identifier receipt-chain-break SHOULD be used for this condition.¶

7. Index 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). 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. The identifier settled-without-ref SHOULD be used for this condition.¶

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 receipts in [startMs, endMs) as defined above (MUST-T11-2). 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 in-window receipt. 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.¶

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 transparency 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 transparency receipts were supplied, verify them against the out-of-band transparency key (Section 9.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). 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.¶

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).¶

10.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 transparency 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.¶

15.1. T1: Prompt injection leads to unauthorized spend

15.2. T2: Runaway agent (loop spend)

15.3. T3: Replay of payment authority

15.4. T4: Receipt forgery or repudiation

15.5. T5: Policy bypass via direct rail access

15.6. T6: TOCTOU between policy check and payment

15.7. T7: Signing-key leakage

15.8. T8: Counterparty price gouging or defective delivery

15.9. MUST-T8-custody

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

15.10. T9: PII leakage into the transparency log

See also Section 14.¶

15.11. T10: Secret spend via rail bypass

See Section 10.¶

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 10).¶

15.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 -03 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.¶

15.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).¶

15.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 10 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. Changes from -02

This -03 has 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 9 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 9. 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 this revision keeps 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 this revision 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 9.1.¶

17.2. 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 transparency 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 this revision does not improve on it.¶

The reporters are named in the Acknowledgments.¶

18.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].¶

18.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.¶

18.3. Generalization

Payment is the special case that this -03 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.¶

20.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>.

[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>.

[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>.

20.2. Informative References

[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>.

[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/>.