Summary

  • draft-mih-agent-settlement-records-00 proposes separate signed observations from payer and payee and lets a verifier derive whether those payment legs agree. No leg is allowed to assert the combined state.
  • Payment agreement and delivery are independent. The draft explicitly permits a payment to be agreed while delivery is none; neither signature nor agreement proves that the promised good, content or service arrived.

The cleanest line in a new payment proposal is also the easiest one for a product to erase: “A payment can be agreed while delivery is none.”

The sentence appears in revision 00 of Two-Party Settlement Records for Agent Payments, posted to the IETF Datatracker on 2 October 2026. The draft starts from a practical asymmetry. A payer's wallet or bank observes money leaving. A payee's system observes money arriving. Existing protocols often preserve only one of those views, and most say little about what was delivered in exchange.

The proposal builds a settlement from as many as four kinds of leg: terms, payer-observed, payee-observed and delivered. Each party seals only what its own system observed. The payer must not turn evidence received from the payee into a payer observation, or vice versa. A citation to the other half records custody of that record, not ownership of its claim.

This makes the verifier, not either party, responsible for the combined state. No settlement member contains an agreed or mismatch verdict. The verifier first validates each Agent Action Capsule, producer envelope, structure, wrapped object, role and local key policy. It then groups acceptable legs by the terms reference and typed payment reference and derives the result from their own bytes.

One side alone remains a stated claim. payer_stated says only that a payer-side system reported an outgoing payment. payee_stated says only that a payee-side system reported an incoming one. The missing half is not evidence of disagreement: it may not exist yet, may have been withheld or may never be produced. The related evidence-request draft provides different outcomes for an answer, a signed refusal and a recorded absence.

agreed is deliberately narrower. Both observations must be joinable, use distinct accepted keys, carry the same normalized payment reference, satisfy the amount rule and report the same status. The amount comparison is exact: payer amount equals payee received plus the payee-side receive fee, in the same asset and at a common decimal scale. There is no tolerance. A direct comparison between payer amount and payee received would falsely call an honest fee a mismatch.

Even then, agreement is about what the two payment systems say moved. The draft separately reports whether the observed amount equals the terms. Both sides can agree with each other and both differ from the bargain. Whether a fee was commercially acceptable is a terms question, not a side effect of cryptographic agreement.

Delivery lives on its own state machine. With no delivered leg, its state is none. One non-conflicting side produces stated. Matching sent and received content digests produce matched; conflicting digests produce mismatch. The inverse separation also matters: delivery can be matched while payment is only payee_stated.

A digest narrows what can be disputed, but it does not settle every dispute. Equal content digests can show that both records refer to the same bytes. They cannot, without additional policy and evidence, establish that a physical item had acceptable quality, a service met its deadline, software performed as promised, a recipient had authority to accept it, or a contract's remedies have expired.

Status words are local observations too. settled means final on the sealer's own side—debited for payer or credited or received for payee. The model also permits reversed, and later observations should supersede earlier ones. The article therefore does not treat “settled” as a rail-independent promise that value can never be returned or challenged.

Signatures do not appoint the signer. The draft explicitly leaves trust policy outside its scope. A verifier must decide which key may speak for the claimed payer or payee. Distinct keys prevent one key from manufacturing both sides of an agreed pair, but two different keys are not by themselves proof of two authorised counterparties.

Wrapped payment objects preserve another boundary. Existing signed receipts are carried by digest and must not be re-signed. A wrapper proves that a sealer included particular bytes; it does not make the sealer the original issuer. Likewise, a SCITT receipt can prove that a leg entered a named transparency log. It does not prove the leg's content true and cannot make a one-sided leg bilateral.

These are proposal semantics, not deployment facts. The Datatracker record is an individual Internet-Draft with no stream or standards level. Its mappings to x402, AP2, Payment HTTP, Open Payments, Lightning and ISO 20022 are the draft author's crosswalks, not evidence that those communities adopted this record format.

Lu Heng's Minimum Initial Specification provides the useful institutional posture: share the smallest record shape that allows independent observations to meet, but keep consequential judgment local. Running-Code Primacy asks which rail object, key policy, normalization rule and supersession head actually ran. Reality Layers prevents signed observation, bilateral payment agreement, delivery evidence and contractual fulfilment from collapsing into one “complete” badge.

Leaders should demand a decision receipt that preserves all four. Record the accepted legs and failures, key-to-party policy, derived payment state, terms comparison, derived delivery state, wrapped-object verification, rail status, supersession and the local commercial action. Then a dispute can reveal exactly where agreement ended and judgment began.

Sources