Spend Receipts and Payment Rail Reconciliation for AI Agents

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

6.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 7 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. 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 delivered 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 remains valid.¶

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

7.1. Claim labels

Registered CWT claims [RFC8392] are not required by this profile. Cedulon uses CWT private-use integer labels less than -65536.¶

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

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

7.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): every digest in Section 8.1 is computed over octets that include the unprotected header, which the signature does not cover. 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].¶

7.3. How a signed object is presented

The signed octets above are what this profile defines and what every digest in Section 8.1 is taken over. An object handed to a verifier travels with more than that, and this section names what.¶

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 8 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 10, 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 11.1). With no pin held it is the only key present, so any 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. A Trade Manifest with no pinned key is not checked against its carried key at all (Appendix B, unauthenticated-manifest).¶

8.1. Which octets are hashed

Every hash-valued field in this document is SHA-256 [RFC6234] of the input named below. All but two are rendered as lowercase hexadecimal, and a third differs in another respect. 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 7 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.¶

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

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

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

10.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 8); 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 12); when absent, the profile default of 300000 milliseconds (five minutes) applies.¶

10.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 8: 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. See Section 15.¶

10.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 has not stated the period under audit MUST emit unstated-audit-window and MUST treat the guarantee as conditional (MUST-T10-15), whatever else verifies.¶

Likewise, a verifier that has not stated the account or the rail under audit 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.¶

A balanced audit under an unconditional guarantee is true of one account, on one rail, over one window, so a report that carries it MUST also carry that account, rail and window (MUST-T10-19). A completeness claim about an account needs one such report per rail that account can settle on; enumerating those rails is the deployment's statement.¶

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

An audit given no receipts and no checkpoints rests on the extract alone and is not made conditional by this requirement.¶

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

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

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 6.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), so that a key rotation mid-window does not force it off the pin. 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.¶

11.2. The payee root

The optional countersignature in Section 6.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.¶

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 6.1 and leaves the expectation open exactly as a missing one does. The discarded object itself is a warning, never a failure of the receipt it rode beside; Section 6.1 states the invariant.¶

11.3. The decision root

A Decision Token is issued by the policy decision point and consumed by the same deployment. 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).¶

11.4. The manifest root

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

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 document, 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, so a forged receipt can silence this warning; the report it leaves behind is still conditional and still carries the finding that the receipt answers to no pinned key. 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. 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 document. Every receipt that names the manifest is measured, aborted ones included. 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.¶

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 reported without becoming a charge no readable key backs. Only receipts that name the manifest are measured against it. Under a usable issuer pin, a departure is a finding rather than a condition on the guarantee.¶

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): a settled payment carrying the hash of terms nobody authorised cannot be withdrawn by reporting it afterwards.¶

11.5. 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; the finding stands, only its attribution changes.¶

12.1. Verification algorithm

A verifier MUST perform all of these steps and MUST report every finding they produce (MUST-T10-1). 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.¶

Two data dependencies limit that freedom, because "any order" read naively would break them. An order that runs a step before the step it consumes does not produce the same set of findings and is not permitted.¶

The first is the index of refs: step 7 builds it, and steps 8 and 9 reconcile it.¶

The second is the issuer pin. The step that resolves it decides the working set: the attested set - the receipts and checkpoints that verify under a usable pinned issuer key - or, when no usable key is pinned, the whole presented set, whose members are presented-unattested. Every later step that walks receipts consumes the working set: the indexing and reconciliation in steps 7 through 9 and the MUST-T8-9 comparison. The chain walk in step 6 consumes the working set plus one addition named in Section 11.1: a receipt that claims the pin and fails to verify under it is walked so the break can be named, and is attested nowhere. A receipt that neither claims the pin nor verifies under it is reported once (issuer-key-mismatch) 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.¶

Checkpoint and witness verification consumes that working set and is specified in [CEDULON-CHECKPOINT] (Verification algorithm), which an implementation of this audit also implements: a receipt that falls in no presented checkpoint window, including every receipt when no checkpoint is presented, fails that document's window-coverage check.¶

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 11.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 11.1 reads the answer out per cell. Every cell there is a named condition plus a membership decision; no cell is a silent removal. Where a countersignature is present, Section 11.2 governs what it establishes (MUST-T4-13, MUST-T4-14). Where a Trade Manifest is presented, Section 11.4 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 10): 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 receipts of the working set, together with any receipt that claims the pin and failed to verify under it (Section 11.1), 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. An issuer stream that does not chain its receipts (SHOULD-T4-5) is therefore reported as a break from its second receipt on: the SHOULD states what an issuer owes, and this step states what a verifier does with a stream that did not.¶

7. Index the settled receipts of the working set and the 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 10), 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. 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).¶

12.2. Finding codes

The identifiers are listed in Appendix B. They 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.¶

15.1. T1: Prompt injection leads to unauthorized spend

An attacker plants instructions in tool output, a web page, or a retrieved document. The agent then calls a spend tool outside the principal's intent. Narrative: [CEDULON-THREATS].¶

15.2. T2: Runaway agent (loop spend)

A stuck tool loop or recursive planner issues many payments. Velocity and cumulative-limit counters live in the PDP, fail-closed. Narrative: [CEDULON-THREATS].¶

15.3. T3: Replay of payment authority

An observer replays a signed payment payload, mandate, or Cedulon decision token. Every gated spend carries a unique nonce; manifests expire; tokens are single-use. Narrative: [CEDULON-THREATS].¶

15.4. T4: Receipt forgery or repudiation

A party alters a receipt, invents a receipt, or denies a real spend. Receipts are signed; verification covers the signed bytes; a hash chain links them. Narrative: [CEDULON-THREATS].¶

15.5. T5: Policy bypass via direct rail access

The agent or an attacker calls the rail without the PDP. The only payment function is the adapter that calls the PDP first. Narrative: [CEDULON-THREATS].¶

15.6. T6: Time-of-check to time-of-use (TOCTOU) between policy check and payment

An allow is computed; the request is then swapped before the rail sees it. Settlement pays only the exact fields hashed into the single-use decision. Narrative: [CEDULON-THREATS].¶

A later verifier cannot make this comparison. Decision Tokens are not among the inputs Section 12.1 enumerates: the extract, the receipts, the manifests, the checkpoints, and the witness receipts. The rule is written on the party that can apply it. Verification does not repeat it.¶

MUST-T6-7 does not let a later verifier detect a settlement that predates its decision. That would require carrying the decision's issuance time on the token and binding the receipt to it, which this document does not define. MUST-T6-4 names the same five labels.¶

15.7. T7: Signing-key leakage

Keys leak from disk, logs, or a prompt. Forged manifests or receipts follow. Narrative: [CEDULON-THREATS].¶

15.8. T8: Counterparty price gouging or defective delivery

The payee ships a different artifact, or the price exceeds the signed offer. The Trade Manifest binds price and an acceptance-criteria hash before payment. Narrative: [CEDULON-THREATS].¶

15.9. 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.10. T9: Personally identifiable information (PII) leakage into the transparency log

A public receipt or transparency statement carries names, addresses, or full amounts that should stay private. Log-facing encodings offer redaction. See also Section 14. Narrative: [CEDULON-THREATS].¶

15.11. T10: Secret spend via rail bypass

An operator, leaked credential, or a second binary can settle on the rail and omit the Receipt Issuer. Completeness reconciles the extract to the receipts. See Section 12. Narrative: [CEDULON-THREATS].¶

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

15.12. T11: Checkpoint suppression or rollback

Checkpoint suppression and rollback, and the witness that detects them, are addressed in [CEDULON-CHECKPOINT]. The two requirements below are defined here because the core label set and the reconciliation depend on them.¶

15.13. 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. Ordering, recovery and observability: [CEDULON-THREATS].¶

16.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 6 and Section 7.¶

Security considerations:

See Section 15 of this document. The object is signed; its evidentiary weight depends on the verifier holding the issuer key out of band (Section 11.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 7.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 6.¶

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¶

16.2. 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 5 and Section 7.¶

Security considerations:

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

Interoperability considerations:

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

Published specification:

This document, Section 5.¶

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

16.3. 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 9 and Section 7.¶

Security considerations:

See Section 15 of this document. A Decision Token is consumed at the gate by the party that issued it (Section 11.3); it is not an input to the retrospective audit (Section 12.1), 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 7.1, all five always present.¶

Published specification:

This document, Section 9.¶

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

16.4. 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 6.1, whose payload carries the exact issuer receipt octets it countersigns.¶

Security considerations:

See Section 15 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 6.1, Section 11.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 6.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.¶

20.1. Normative References

[CEDULON-CHECKPOINT]

Dogru, E. C., "Cedulon Checkpoints: Epoch Witnesses and Transparency", 2026, <https://github.com/dogrucanemek-alt/cedulon/blob/master/spec/draft-dogru-cedulon-checkpoint-00.md>.

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

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

[BIRKHOLZ-VAC]

Birkholz, H., Heldt, T., and O. Steele, "Verifiable Agent Conversation Records", August 2026, <https://datatracker.ietf.org/doc/draft-birkholz-verifiable-agent-conversations/>.

[CEDULON-DT]

Dogru, E. C., "Cedulon: An Audit Layer for Agent-to-Agent Commerce", 2026, <https://datatracker.ietf.org/doc/draft-dogru-cedulon/>.

[CEDULON-THREATS]

Dogru, E. C., "Cedulon Threat Narratives", 2026, <https://github.com/dogrucanemek-alt/cedulon/blob/master/spec/draft-dogru-cedulon-threats-00.md>.

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

[KUEHLEWIND-AUDIT]

Kuehlewind, M. and H. Birkholz, "An Architecture for Auditing AI Agent Delegation and Interactions", May 2026, <https://datatracker.ietf.org/doc/draft-kuehlewind-audit-architecture/>.

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