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

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. 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). totals MUST sum only receipts with outcome = settled.¶

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

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

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

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. Require receiptCount, chainHeadHash, and totals to match the receipts in [startMs, endMs) as defined above (MUST-T11-2).¶

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

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

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

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

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, and no finding that puts the extract in doubt. Anything less 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.¶

14.1. T1: Prompt injection leads to unauthorized spend

14.2. T2: Runaway agent (loop spend)

14.3. T3: Replay of payment authority

14.4. T4: Receipt forgery or repudiation

14.5. T5: Policy bypass via direct rail access

14.6. T6: TOCTOU between policy check and payment

14.7. T7: Signing-key leakage

14.8. T8: Counterparty price gouging or defective delivery

14.9. MUST-T8-custody

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

14.10. T9: PII leakage into the transparency log

See also Section 13.¶

14.11. T10: Secret spend via rail bypass

See Section 9.¶

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

14.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 -01 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 or a transparency log is out of scope for -01.¶

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

14.13. Optional escrow role

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

16.1. Changes from -00

Two independent readers ran the -00 implementation and reported defects. One was a bypass of the completeness claim: the implementation verified an extract and then reconciled a separate settlement list, so a validly signed extract could carry an off-book settlement while the caller supplied an empty list, and the audit reported balanced books. That was the implementation contradicting -00, which already required reconciling against the extract; this revision states the requirement in the verification algorithm so it cannot be read as optional (MUST-T10-12).¶

The second was a gap in this document rather than in the code. -00 required an authenticated extract but never said which key the signature is checked against, so an implementation could satisfy the text while verifying a signature against a key the extract itself carried. Such a key verifies against itself. -01 requires the rail key out of band and compares keys as DER (MUST-T10-8, MUST-T10-9).¶

The remaining changes close narrower holes found while repairing those two: an extract whose declared window disagrees with the records it carries (MUST-T10-10), an extract that does not cover the period under audit (MUST-T10-11), a repeated ref dropping out of the comparison and hiding the unaccounted amount (MUST-T10-13), and a report that states a balance in operator-facing output while withholding that the balance is conditional (MUST-T10-14).¶

Three changes are not repairs and are recorded here so a reader of -00 is not surprised:¶

• A failed extract signature was a warning in -00 and stays one when no key is pinned. Once a key is pinned it now fails the audit. -00 did not contemplate a pinned key, so this is new behaviour rather than a clarification.¶

• Requiring that a disagreeing caller-supplied list be reported as extract-settlement-mismatch is new normative content. -00 required reconciling the extract; it did not require saying anything about a list that contradicted it.¶

• -00 said reversal, refund, and partial settlement were "expected in -01", and said reserved extensions belonged in "-01 or -02". Neither arrived in this revision. They are now stated as out of scope for this revision and expected later, with no date.¶

The reporters are named in the Acknowledgments.¶

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

17.2. Streaming reconciliation

Epoch checkpoints in this document are batch windows. A later revision (-02) 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.¶

17.3. Generalization

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

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

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