Two-Party Settlement Records for Agent Payments

1.1. What This Document Does Not Do

This document does not move money, define a payment protocol, replace any protocol it binds to, or decide between the parties. It defines no trust policy for deciding which key may seal for a payer or payee; that is the verifier's policy, as in [I-D.mih-scitt-agent-action-capsule]. It does not rank, rate, or otherwise grade the parties to a settlement. It records what each side observed, and it defines how a verifier derives whether the observations agree.¶

4.1. Carriage in a Capsule

A leg record is an Agent Action Capsule of format 4 [I-D.mih-scitt-agent-action-capsule] with a top-level settlement member. Everything the base profile requires of a Capsule applies: the capsule_id is the SHA-256 of the RFC 8785 form of the Capsule without capsule_id, floating-point numbers are forbidden in digest-bearing material, and the settlement member participates in the digest. A leg record's identity is its capsule_id.¶

A leg record SHOULD use action_type: "fyi" and an assurance block whose effect_mode is not_applicable: the leg records an observation, and the payment itself is not an effect the sealer's gate committed. A deployment in which the sealer's own gate dispatched the payment MAY instead record it as the effect of a separate Capsule with effect.type: "send_payment" and cite that Capsule from the payer-observed leg; this document does not require it.¶

A verifier unaware of this document processes a leg record as an ordinary Capsule. Every check of the base profile still applies to it.¶

4.2. The settlement Member

The settlement member is a JSON object:¶

A member not listed for a leg MUST NOT be present in that leg. A verifier reports a missing required member or a present forbidden member as settlement_malformed.¶

No member of settlement states the settlement's state. The state is derived (Section 9); a member that asserted it would let one sealer state a fact that only the combination of both sides' records can establish.¶

4.3. Citations Between Legs

Legs cite each other in two ways.¶

The terms reference. Every leg other than the terms leg carries terms_ref, the capsule_id of the terms leg it answers. A leg answers exactly one terms leg. terms_ref is a bare digest, in the same way the base profile's cross_party.initiator_ref is: it names the terms leg's capsule_id, and a verifier compares it with the recomputed capsule_id of the terms leg it holds.¶

Counterparty legs. A sealer that holds a leg sealed by the other party MAY cite it from its own leg with a references entry ([I-D.mih-scitt-agent-action-capsule], Cross-record references) of type agent-action-capsule, digest_alg SHA-256, the cited leg's capsule_id as digest, and citation_purpose: "counterparty_half". As the base profile defines that purpose, the citation records custody of the counterparty's leg, not an observation of it.¶

A sealer's own legs form its own stream, and a sealer MAY link them with chain (for example, a payee's delivered leg following its payee-observed leg with relation follows). The join of a settlement never depends on chain; it depends on terms_ref and payment_ref only.¶

The usual order of a settlement is shown below. Only the terms leg must exist before the others; any subset of the other legs can be present.¶

   payee (or payer)              payer                 payee
  +----------------+     +------------------+    +------------------+
  |  terms leg     |<----| payer_observed   |    | payee_observed   |
  |  amount, wraps |     | payment_ref,     |    | payment_ref,     |
  |  offer/mandate |<-+  | amount,          |<...| received,        |
  |                |  |  | routing_fee,     |    | receive_fee,     |
  |                |  |  | status           |    | status           |
  +----------------+  |  +------------------+    +------------------+
          ^           |                                   |
          |           +-----------------------------------+
          |                terms_ref (every leg)
  +-----------------------------+
  |  delivered leg (either side)|
  |  content_digest, direction  |
  +-----------------------------+

   <---- terms_ref        <.... references[] counterparty_half

5.1. Terms

The terms leg fixes what the payment is for and how much it is. It is sealed by the party that set the terms. That is usually the payee, whose offer or invoice states the price; in a mandate-based flow it is usually the payer, whose mandate states what it authorized. The other party accepts the terms by citing them: its observed leg carries the same terms_ref. A terms leg that no counterparty leg cites is one party's statement of the terms, not an agreement on them.¶

The terms leg carries:¶

• amount: the agreed amount (Section 6).¶

• wrapped (OPTIONAL): the protocol object that stated the terms. Examples are the x402 signed offer [X402-OFFER-RECEIPT], the AP2 Checkout or Payment Mandate [AP2], and a BOLT 12 invoice [BOLT12].¶

• deliverable (OPTIONAL): an object with at least one of these members:¶

  • content_digest: the digest of the content to be delivered, when it is known in advance (for example a data set with a published digest).¶

  • description_digest: the JSON digest of a description of what is to be delivered, when the content is not known in advance (for example an inference whose output does not yet exist).¶

• payment_ref (OPTIONAL): the payment reference, when it is fixed before payment.¶

• valid_until (OPTIONAL).¶

Refunds and partial payments are out of scope for this revision. A refund can be recorded as a separate settlement, with its own terms leg and the roles reversed; this document defines no citation between it and the original terms leg (Section 16).¶

When the terms come from a protocol object, the terms leg's amount MUST equal the amount that object states (Section 6). The x402 offer's amount is already an integer string in the asset's atomic units, so it becomes value directly, with assetScale set to the asset's number of decimals.¶

5.2. Payer-Observed

The payer-observed leg records what the payer's own system reported about the payment it made: the payment reference, the amount it sent toward the payee (amount), the routing fee it paid on top of that (routing_fee), and the status the payer's system reported. It is sealed by the payer.¶

It SHOULD wrap the object the payer's system returned, where one exists: the x402 PaymentPayload the payer sent and the settlement response it received [X402], the BOLT 12 payer proof [BOLT12], or the ISO 20022 status report the payer's bank returned [ISO20022]. A payer that received a payee-issued receipt (for example an AP2 Payment Receipt or an x402 signed receipt) MAY wrap it here; it is then carried as the issuer's object, not as the payer's observation (Section 8).¶

5.3. Payee-Observed

The payee-observed leg records what the payee's own system reported about the payment it received: the payment reference, the amount credited to it (received), the fee deducted on the receiving side (receive_fee), and the status the payee's system reported. It is sealed by the payee.¶

It SHOULD wrap the object the payee's system produced or received: the x402 settlement response from its facilitator, the x402 signed receipt it issued [X402-OFFER-RECEIPT], the AP2 Payment Receipt or Checkout Receipt [AP2], the Payment-Receipt it returned [I-D.ryan-httpauth-payment], or the ISO 20022 credit notification its bank sent. Where a signed payee receipt already exists, the payee-observed leg wraps it; it does not restate and re-sign the same claim.¶

A payee that holds the payer-observed leg MAY cite it (Section 4.3).¶

5.4. Delivered

The delivered leg records what was delivered under the terms. Either party may seal one, and both may: the payee records what it sent, and the payer records what it received. Each records only its own side.¶

The delivery member is an object:¶

Binding to the terms. The delivered leg is bound to the terms in two ways. Its terms_ref names the terms leg, so the content digest is a statement about delivery under those terms and no other. And when the terms leg carries deliverable.content_digest, a verifier compares the delivered content_digest with it (Section 9.3). When the terms carry only description_digest, the verifier can establish that both sides name the same delivered content, but not that the content matches the description; that judgment is outside this document.¶

For an inference, content_digest is the digest of the completion as returned at the serving boundary, the same value a Capsule with effect.type: "inference_completion" records as its response_digest ([I-D.mih-scitt-agent-action-capsule], Effect Record). A delivered leg MAY cite that Capsule with citation_purpose: "acted_on".¶

6.1. Fees

The two sides of one payment do not, in general, report the same number. A Lightning payee's wallet, for example, can report 995 millisatoshi received with a receive-side fee of 5 for a payment of 1000 millisatoshi the payer sent with no routing fee. Both observations are honest. This document therefore records each side's gross, fee, and net separately, and never compares the payer's and the payee's amounts directly.¶

The members, each an amount in the form above:¶

• Payer-observed: amount is what the payer's system reports it sent toward the payee. routing_fee is what it paid to intermediaries on top. The payer's total debit is amount + routing_fee.¶

• Payee-observed: received is what the payee's system reports credited. receive_fee is what was deducted on the receiving side, including any charges deducted by intermediaries from the amount in transit, as the payee's system reports them. The gross amount that arrived for the payee is received + receive_fee; equivalently, net = gross - fee.¶

The rules for fees:¶

1. A fee is non-negative: its value follows the grammar of rule 1 above.¶

2. A fee MUST carry the same assetCode as the amount it accompanies (routing_fee with amount, receive_fee with received). It MAY use a different assetScale; sums are computed in exact integer arithmetic at the largest scale involved, as in rule 3 above. A fee in a different asset cannot be combined with its amount; a verifier reports fee_asset_differs and the pair is unjoined (Section 9.2).¶

3. A fee member that is present with value 0 states that the sealer's system reported no fee. A fee member that is absent states nothing.¶

4. An absent receive_fee is read as zero only when the payment reference type declares that receive fees are not applicable to it (Section 7.2). For every other type, a payee-observed leg without receive_fee cannot be joined: the verifier reports fee_unstated and the pair is unjoined, never agreed. A payee that observed no fee records receive_fee with value 0.¶

5. routing_fee does not enter the join (Section 9.2); the payee cannot observe it. A payer SHOULD record it so that the payer's total debit is reconstructable.¶

7.1. Shape and Join Rule

A payment reference is a JSON object with a type member, a value member, and the qualifier members its type defines:¶

{"type": "x402.transaction",
 "value": "0x5a1f...c3d2",
 "network": "eip155:8453"}

• type (string, REQUIRED): a registered payment reference type (Section 17.1).¶

• value (string, REQUIRED): the identifier, copied from the field the type names, in the normal form the type defines.¶

• Qualifiers (strings): as the type defines. A qualifier names the space in which value is unique (for example the CAIP-2 network of a transaction hash).¶

Two payment references are the same reference if and only if their type is the same registered type and every member is identical as a string after the type's normal form is applied. A verifier MUST NOT join legs on a payment reference whose type it does not recognize: equal-looking strings of an unknown type are not known to name the same payment, because the verifier does not know the type's normal form or uniqueness scope. Such a pair is unjoined (Section 9). Under the base profile's never-reject invariant, the legs themselves remain valid Capsules.¶

Types whose names begin with x- are private and MUST NOT be registered.¶

7.2. Initial Types

x402.transaction:

value is the settlement response transaction member. Qualifier network: the CAIP-2 network identifier [CAIP-2], from the settlement response network member. Normal form: for eip155 networks, lowercase hexadecimal with 0x prefix; otherwise as received. Source: [X402].¶

ln.payment_hash:

value is the BOLT 11 payment hash (tagged field p). Normal form: 64 lowercase hex. Source: [BOLT11].¶

bolt12.invoice_payment_hash:

value is the BOLT 12 invoice invoice_payment_hash. Normal form: 64 lowercase hex. Source: [BOLT12].¶

ap2.transaction_id:

value is the AP2 Payment Mandate transaction_id. Normal form: as received. Source: [AP2].¶

ap2.payment_id:

value is the AP2 Payment Receipt payment_id. Normal form: as received. Source: [AP2].¶

ap2.network_confirmation_id:

value is the AP2 Payment Receipt network_confirmation_id. Normal form: as received. Source: [AP2].¶

acp.order_id:

value is the ACP order order.id. Normal form: as received. Source: [ACP].¶

ucp.order_id:

value is the UCP order order.id. Normal form: as received. Source: [UCP].¶

mpp.reference:

value is the reference member of the decoded Payment-Receipt. Qualifier method: the receipt's method member. Normal form: as received. Source: [I-D.ryan-httpauth-payment].¶

iso20022.uetr:

value is the ISO 20022 UETR (Unique End-to-end Transaction Reference). Normal form: lowercase UUID string [RFC9562]. Source: [ISO20022].¶

iso20022.end_to_end_id:

value is the ISO 20022 EndToEndId. Qualifier debtor_agent: the BIC of the debtor agent. Normal form: as received. Source: [ISO20022].¶

open_payments.incoming_payment:

value is the Open Payments incoming payment id (a URL). Normal form: as received. Source: [OPEN-PAYMENTS].¶

Receive fees: x402.transaction declares receive fees not applicable for the x402 exact scheme only, because that scheme transfers exactly amount to payTo and any facilitator charge is outside that transfer. Other x402 schemes, present or future (for example schemes that batch many payments into one transfer), may differ, and a verifier MUST treat receive_fee as one that may apply for any scheme other than exact. The scheme is the scheme member of the x402 signed offer and of the PaymentRequirements the payer accepted [X402]; a verifier reads it from a wrapped x402.offer in the terms leg or a wrapped x402.payment-payload in the payer-observed leg whose octets it holds. A verifier that cannot establish that the scheme is exact treats the receive fee as one that may apply. Every other initial type declares that a receive fee may apply (Section 6.1, rule 4).¶

Notes on the initial types:¶

• x402 settlement responses always carry transaction and network. The x402 signed receipt omits transaction by default for privacy [X402-OFFER-RECEIPT]; a payee-observed leg takes the reference from the settlement response its facilitator returned, not from the receipt.¶

• For batched settlement, where many payments settle in one on-chain transaction, the transaction hash is not unique to one payment. Such a rail needs its own type naming the per-payment identifier it assigns.¶

• EndToEndId is assigned by the initiating party and is not globally unique; the debtor_agent qualifier narrows it. Where a UETR exists, iso20022.uetr SHOULD be used instead.¶

• AP2 payment_id and network_confirmation_id appear in the Payment Receipt, which is produced after the payment; transaction_id appears in the Payment Mandate, before it. A payer's leg and a payee's leg join only on a type both sides' systems report.¶

9.1. Inputs

A verifier derives states from a set of leg records. A party that presents its own legs, the counterparty legs it holds, and the octets of the objects they wrap can carry them together in an Evidence Bundle [I-D.mih-zhang-agent-disclosure-bundle], whose citation closure lets the verifier check that every leg a presented leg cites is present. For each leg it first checks:¶

1. the Capsule checks of the base profile;¶

2. each Producer Envelope, and the authenticated key;¶

3. the settlement member's structure (Section 4.2) and amounts (Section 6);¶

4. the wrapped entries (Section 8);¶

5. the sealer rules (Section 3), against the verifier's key policy.¶

A leg that fails a check is reported with the failure and does not contribute to the derived state. The distinct-key rule (Section 3) is a check on a pair of legs, not on one: sealer_conflation prevents agreed but does not by itself exclude either leg, because without a key policy the verifier cannot tell which of the two legs is the genuine one. The legs that remain are grouped by terms_ref. Every check is performed on the records' own bytes; no state is read from any record.¶

9.2. Payment State

For one terms leg, let P be the payer-observed legs that cite it and Q the payee-observed legs that cite it. A sealer SHOULD produce at most one observed leg per terms leg; when it produces a later one (for example when pending becomes settled), the later leg SHOULD chain to the earlier with relation supersedes, and the verifier uses the head of that chain.¶

The amount rule. The two observed legs are consistent on amount if and only if¶

   payer.amount = payee.received + payee.receive_fee

where all three carry the same assetCode and the sum and comparison are computed exactly at the largest assetScale of the three (Section 6, Section 6.1). If payer.amount has a different assetCode from payee.received, the amount rule fails and the state is mismatch. A verifier MUST NOT compare payer.amount with payee.received directly: a receive-side fee makes them differ in an honest payment, and treating that difference as a mismatch would misreport it. A verifier MUST NOT relax the amount rule by a tolerance; a difference of one unit at the common scale is a mismatch.¶

A verifier MUST NOT report agreed for a pair that fails the distinct-key rule (Section 3); it reports sealer_conflation instead.¶

A one-sided state is a stated claim. It says what one sealer reports its own system observed. It is not evidence of agreement, and a verifier MUST NOT present it as agreed. The absence of the other leg is not evidence that the other side disagrees: the other leg may not exist yet, may exist and not have been shared, or may never be produced. A verifier that needs to distinguish these can ask the counterparty for its leg using an evidence request [I-D.mih-agent-evidence-request], whose outcomes distinguish an answer, a signed refusal, and a recorded absence.¶

agreed is about the payment only. A verifier also reports, separately, whether the payer's amount equals the terms leg's amount (terms_amount: equal or differs). Two sides can agree on what moved and both differ from the terms. This document defines no fee bounds in the terms leg; whether a fee was acceptable is a question about the terms, not about whether the two sides agree, and a future revision that adds bounds reports them in the same separate way.¶

9.3. Delivery State

For one terms leg, let D be the delivered legs that cite it.¶

The two states are independent. A payment can be agreed while delivery is none, and delivery can be matched while the payment is payee_stated.¶

9.4. Failures

The failure codes a verifier reports for these records are:¶

17.1. Payment Reference Types

Registry name: Settlement Payment Reference Types.¶

Registration policy: Specification Required ([RFC8126], Section 4.6).¶

Each entry has: the type name; the upstream field value is copied from; the qualifier members and their meaning; the normal form; whether a receive fee may apply or is not applicable (Section 6.1); and a reference to a publicly available specification of the upstream field.¶

Designated-expert guidance: the expert checks that the upstream field is publicly specified, that the normal form makes equality well defined, that the qualifiers make value unique for one payment, and that the type does not duplicate an existing one. Names beginning with x- are not registered.¶

Initial contents: the types in Section 7.2, each referencing this document and the source listed there.¶

17.2. Wrapped Object Types

Registry name: Settlement Wrapped Object Types.¶

Registration policy: Specification Required ([RFC8126], Section 4.6).¶

Each entry has: the type name; the issuer of the object under its own specification; the exact octets the digest is computed over; and a reference.¶

Initial contents:¶

x402.offer:

Issuer: payee. Octets: JWS format: the ASCII octets of the JWS compact serialization. EIP-712 format: RFC 8785 form of the envelope object (format, payload, signature). Reference: [X402-OFFER-RECEIPT].¶

x402.receipt:

Issuer: payee. Octets: As for x402.offer. Reference: [X402-OFFER-RECEIPT].¶

x402.payment-payload:

Issuer: payer. Octets: The base64-decoded value of the PAYMENT-SIGNATURE header as sent. Reference: [X402].¶

x402.settle-response:

Issuer: facilitator. Octets: for the payer, the base64-decoded value of the PAYMENT-RESPONSE header as received; for the payee, the settlement response body as its facilitator returned it. Reference: [X402].¶

ap2.checkout-mandate:

Issuer: user or agent. Octets: The SD-JWT serialization as presented. Reference: [AP2].¶

ap2.payment-mandate:

Issuer: user or agent. Octets: The SD-JWT serialization as presented. Reference: [AP2].¶

ap2.checkout-receipt:

Issuer: merchant. Octets: The JWT compact serialization as received. Reference: [AP2].¶

ap2.payment-receipt:

Issuer: payment processor. Octets: The JWT compact serialization as received. Reference: [AP2].¶

bolt12.invoice:

Issuer: payee. Octets: The invoice TLV stream octets. Reference: [BOLT12].¶

bolt12.payer-proof:

Issuer: payer. Octets: The payer proof TLV stream octets. Reference: [BOLT12].¶

mpp.payment-receipt:

Issuer: payee. Octets: The base64url-decoded value of the Payment-Receipt header. Reference: [I-D.ryan-httpauth-payment].¶

iso20022.message:

Issuer: the agent that sent it. Octets: The XML message octets as received. Reference: [ISO20022].¶

delivery.proof:

Issuer: carrier or payee. Octets: The proof-of-delivery document octets. Reference: this document.¶

17.3. No Other Actions

This document reserves the Capsule payload member name settlement for the use defined here. The base profile has no IANA registry of payload member names, so no IANA action is requested for it. The leg, sealer_role, status, and delivery.direction values are closed sets defined by this document and are not registries; a future revision that needs a new value updates this document.¶

18.1. Normative References

[I-D.mih-scitt-agent-action-capsule]

Mih, S., "An Agent Action Capsule Profile for SCITT", Work in Progress, Internet-Draft, draft-mih-scitt-agent-action-capsule-05, September 2026, <https://datatracker.ietf.org/doc/html/draft-mih-scitt-agent-action-capsule-05>.

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

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

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

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

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

18.2. Informative References

[ACP]

Agentic Commerce Protocol contributors, "Agentic Commerce Protocol", 2026, <https://github.com/agentic-commerce-protocol/agentic-commerce-protocol>.

[AEP]

A-Comm Technologies, Inc., "A-Comm Evidence Protocol (AEP) Specification v1.0.3-rc.2 (Draft)", July 2026, <https://github.com/A-Comm-Tech/a-comm-evidence-protocol>.

[AP2]

FIDO Alliance, "Agent Payments Protocol (AP2) Specification, v0.2", April 2026, <https://ap2-protocol.org/ap2/specification/>.

[BOLT11]

Lightning Network specification contributors, "BOLT #11: Invoice Protocol for Lightning Payments", n.d., <https://github.com/lightning/bolts/blob/master/11-payment-encoding.md>.

[BOLT12]

Lightning Network specification contributors, "BOLT #12: Flexible Protocol for Lightning Payments (including payer proofs)", July 2026, <https://github.com/lightning/bolts/blob/master/12-offer-encoding.md>.

[CAIP-2]

Chain Agnostic Standards Alliance, "CAIP-2: Blockchain ID Specification", n.d., <https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/caip-2.md>.

[CAIP-19]

Chain Agnostic Standards Alliance, "CAIP-19: Asset Type and Asset ID Specification", n.d., <https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/caip-19.md>.

[I-D.dogru-cedulon-core]

Doğru, E. C., "Spend Receipts and Payment Rail Reconciliation for AI Agents", Work in Progress, Internet-Draft, draft-dogru-cedulon-core-02, 30 September 2026, <https://datatracker.ietf.org/doc/html/draft-dogru-cedulon-core-02>.

[I-D.mih-agent-bilateral-attestation]

Mih, S., "Bilateral Attestation of Cross-Organization Agent Actions", Work in Progress, Internet-Draft, draft-mih-agent-bilateral-attestation-02, 13 September 2026, <https://datatracker.ietf.org/doc/html/draft-mih-agent-bilateral-attestation-02>.

[I-D.mih-agent-evidence-request]

Mih, S., "An Interaction Model for Requesting Verifiable Evidence", Work in Progress, Internet-Draft, draft-mih-agent-evidence-request-00, 26 September 2026, <https://datatracker.ietf.org/doc/html/draft-mih-agent-evidence-request-00>.

[I-D.mih-scitt-agent-action-capsule-sel-disc]

Mih, S., "Selective Disclosure Profile for Agent Action Capsules", Work in Progress, Internet-Draft, draft-mih-scitt-agent-action-capsule-sel-disc-00, 19 June 2026, <https://datatracker.ietf.org/doc/html/draft-mih-scitt-agent-action-capsule-sel-disc-00>.

[I-D.mih-sokolov-scitt-payload-binding]

Mih, S. and A. Sokolov, "Canonicalization Declaration for SCITT Signed Statements", Work in Progress, Internet-Draft, draft-mih-sokolov-scitt-payload-binding-05, 11 September 2026, <https://datatracker.ietf.org/doc/html/draft-mih-sokolov-scitt-payload-binding-05>.

[I-D.mih-zhang-agent-disclosure-bundle]

Mih, S. and Y. Zhang, "AAC Evidence Bundle", Work in Progress, Internet-Draft, draft-mih-zhang-agent-disclosure-bundle-00, September 2026, <https://datatracker.ietf.org/doc/html/draft-mih-zhang-agent-disclosure-bundle-00>.

[I-D.ryan-httpauth-payment]

Ryan, B., Moxey, J., Meagher, T., Weinstein, J., and S. Kaliski, "The "Payment" HTTP Authentication Scheme", Work in Progress, Internet-Draft, draft-ryan-httpauth-payment-01, 17 March 2026, <https://datatracker.ietf.org/doc/html/draft-ryan-httpauth-payment-01>.

[ISO4217]

International Organization for Standardization, "Codes for the representation of currencies", ISO 4217:2015, n.d..

[ISO20022]

International Organization for Standardization, "ISO 20022 Financial Services - Universal Financial Industry Message Scheme (message definitions pacs.002, pacs.004, pacs.008, camt.054)", n.d., <https://www.iso20022.org/>.

[OPEN-PAYMENTS]

Interledger Foundation, "Open Payments API", n.d., <https://openpayments.dev/>.

[RFC9338]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Countersignatures", STD 96, RFC 9338, DOI 10.17487/RFC9338, December 2022, <https://www.rfc-editor.org/rfc/rfc9338>.

[RFC9562]

Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, <https://www.rfc-editor.org/rfc/rfc9562>.

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

[UCP]

Universal Commerce Protocol contributors, "Universal Commerce Protocol", January 2026, <https://github.com/Universal-Commerce-Protocol/ucp>.

[X402]

x402 Foundation, "x402 Protocol Specification, Version 2", 2026, <https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md>.

[X402-OFFER-RECEIPT]

x402 Foundation, "x402 Extension: Signed Offer and Receipt (version 0.6)", February 2026, <https://github.com/x402-foundation/x402/blob/main/specs/extensions/extension-offer-and-receipt.md>.