Agent-Payment Consent Receipt

A deterministic, offline reference for the human-authorization layer in machine-to-machine payments (x402 / L402, agent payments, NWC/NIP-47).

Every layer in the agent-payment stack today proves something happened or what settled. AIR proves agent<->merchant interaction. Settlement-binding proves what settled. Draft-morrison proves what was disclosed. None of them proves who authorized the spend — the amount, cap, purpose, and expiry a human actually signed.

A consent receipt is that record. It is a small, content-addressed, signed JSON object: who authorized what, for what purpose, up to what cap, until when. This repo ships a checker, a signer, and an AIR composer, plus the spec, the composition notes against live x402 drafts, and signed fixtures.

It is a verification and triage aid. It is not an audit, a certification, a solvency/safety verdict, a legal opinion, or an endorsement of any payment flow.

---

What's here

Path	What it does
tools/consent_receipt_check.py	Offline, deterministic validator. Structure, scope/cap consistency, expiry, nonce, and content integrity (SHA-256 over RFC 8785 JCS canonical bytes). Stdlib only.
tools/sign_consent_receipt.py	Ed25519 sign/verify over the canonical body (content_sha256 = SHA-256(JCS(receipt minus {content_sha256, signatures}))). Requires cryptography.
tools/air_consent_compose.py	Composes a consent receipt into an AIR authorizations[] binding entry, with the scheme-defined binding-coherence predicates (payment-within-cap, asset-match, within-validity).
tools/boundaryattest_interop.py	Composes a consent grant with a BoundaryAttest Interop v0.1 receipt via an authorization_ref digest pointer — provenance (the signed action) + authorization (the signed grant) in one check.
tools/nomos_consent_compose.py	Composes a consent grant as the human-authorization origin of a NOMOS intent (AgentNOMOS trust-chain) via authorization_ref — closes NOMOS's explicit execution-bound claim ceiling.
docs/agent-payment-consent-receipt.md	The spec.
docs/*.md	Composition notes mapping the receipt onto live drafts: AIR, draft-morrison-04, settlement binding, offer-receipt v2, auth-hints, risk-decision provenance, authorization-provenance (ZK), BoundaryAttest interop, NOMOS trust-chain.
examples/	Signed and unsigned fixtures, one per composition. All digests recompute byte-for-byte.

Quickstart

pip install cryptography        # only needed for signing/verifying

# validate a receipt
python3 tools/consent_receipt_check.py examples/agent-payment-consent-receipt/valid-receipt.json

# verify its Ed25519 signature over the canonical bytes
python3 tools/sign_consent_receipt.py verify examples/agent-payment-consent-receipt/valid-receipt.json

# compose a consent receipt into an AIR authorizations[] entry
python3 tools/air_consent_compose.py \
  --air examples/air-consent-receipt-composition/air-entry-with-authorization.json \
  --consent examples/air-consent-receipt-composition/consent-receipt.json

# run the test suite
python3 -m unittest discover -s tools -p 'test_*.py'

What a receipt proves — and what it does not

A valid receipt proves, for the bytes it covers:

• a named authorizer signed a bounded grant (amount, cap, purpose, expiry);
• the receipt's content_sha256 recomputes from its own canonical form; and
• any references[] entries (prior artifacts: offer, settlement, AIR receipt, attestation) are named by their own content digests.

It does not prove the authorizer's real-world identity, that payment actually occurred, that a referenced artifact is trustworthy, or that the action was lawful. Those are separate layers, deliberately out of scope.

Design constraints

• Prior-artifacts-only references[]. A receipt may reference artifacts that already exist (an accepted offer, a settlement record); it must not forward-reference something it authorizes. The checker warns on the latter.
• Decimal-string money. Amounts are JSON strings ("5.00"), never floats.
• RFC 8785 (JCS) canonicalization. content_sha256 is the SHA-256 of the receipt in JCS form, minus content_sha256 and signatures, lowercase hex.
• Recompute-by-arithmetic. Every digest in the shipped fixtures is regenerated by the checker; nothing is self-attested.

Context

The receipt composes with, and was validated against, live work in the agent-payment ecosystem: the AIR receipt format (accepted as a scheme under issuer_signed, with binding-coherence predicates), the IETF draft-morrison-consent-settlement grant, x402 settlement-receipt binding, and the x402 authorization-provenance / offer-receipt / auth-hints proposals.

Paid verification service

For a supplied receipt / disclosure manifest / AIR binding entry, Nightshift offers a fixed-scope, public-data-only verification pass using the tools in this repo: deterministic validation, binding-coherence check, digest recompute, and a one-page "what this proves vs. what it does not" result. Deliver-first, pay-on-acceptance, native USDC on Base only. See SERVICE.md for the full offer, price, and payment rails. This is a prepared offer — no buyer has been established.

License

MIT. See LICENSE.