AIR/1: Offline-Verifiable Agent Intent Receipts over x402

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 17 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The x402 protocol [x402] lets a client pay for a single HTTP request on-chain with no account and no API key: the server answers an unpaid request with HTTP 402 (Payment Required), the client returns a payment authorization, and the server serves the result once settlement is arranged. After settlement the client holds a result, but nothing that independently proves what was requested, who fulfilled it, and that payment occurred.¶

This document defines the Agent Intent Receipt, version 1 (AIR/1): a compact, signed JSON object that binds those three facts together so a third party (an auditor, a marketplace, or a dispute resolver) can check them after the fact, offline, with no access to the issuer.¶

AIR/1 is transport- and platform-neutral. It does not depend on any particular gateway, facilitator, or chain beyond the abstractions defined here.¶

2. Trust Model

AIR/1 is trust-minimizing: three independent parties back three independent facts, and no single party can forge the whole receipt.¶

The facilitator holds its own settlement key and lands the payment on-chain; the receipt never needs that key. The issuer signs the whole receipt with its own key, identified by signature.signer. The facilitator and the issuer are distinct roles and are generally distinct entities.¶

The payment authorization signed by the payer (for example, an EIP-3009 [EIP-3009] transferWithAuthorization over EIP-712 [EIP-712]) is a separate signature, by a separate key, over a separate payload, and is out of scope for this document. AIR/1 attests to fulfillment, not to the payment authorization. Implementations MUST NOT reuse the payer's payment-authorization signature as the receipt signature.¶

3. Receipt Object

An unsigned receipt is a JSON object [RFC8259] with the following members.¶

Implementations MAY include additional top-level members. A verifier MUST preserve unknown members verbatim; unknown members are covered by the signature (Section 5).¶

4. Canonical Serialization and Hashing

Hashes and signatures are computed over a canonical byte encoding so that independent implementations agree. The canonical form of a value is produced by the following rules, applied recursively. These rules are compatible with JCS [RFC8785] for the value subset used by this specification.¶

1. Object member names are sorted in ascending order by Unicode code point.¶
2. No insignificant whitespace is emitted. The value separator is U+002C (,) and the name/value separator is U+003A (:).¶
3. Output is UTF-8. Characters outside the ASCII range are emitted literally and MUST NOT be \u-escaped, except where JSON string escaping is required by [RFC8259].¶
4. A number whose value is an integer (for example 500.0) is emitted without a fractional part or exponent (500). Other numbers are emitted in their shortest round-tripping decimal form. See the number-precision caveat in Section 9.¶
5. The literals true, false, and null are emitted as-is.¶

The intent_hash is the lowercase hex SHA-256 [RFC6234] [SHS] digest of the canonical encoding of the intent object. The result_hash is computed the same way over the result object.¶

5. Signature Block

A signed receipt carries a signature object with these members.¶

6. Verification

Given a receipt, a verifier:¶

1. Checks that version equals "AIR/1".¶
2. Selects the suite for signature.algorithm. An unrecognized algorithm, or a missing value or signer, makes the signature invalid.¶
3. Reconstructs the signable bytes (Section 5.1) and verifies signature.value against signature.signer using the selected suite.¶
4. If the original intent is available, recomputes intent_hash and compares.¶
5. If the original result is available, recomputes result_hash and compares.¶
6. Optionally pins the issuer by requiring signature.signer to equal an expected value (case-insensitively for EVM addresses).¶

A receipt is valid when the signature verifies, the version is "AIR/1", the signer matches any configured pin, and no supplied hash mismatches. Hash checks that the caller does not supply are skipped, not failed.¶

Confirming the payment itself is out of scope for receipt verification. A verifier that requires proof of payment MUST look up settlement.tx_hash on the named chain and confirm the amount, asset, and recipient. AIR/1 attests that the issuer asserts a given settlement; the chain is authoritative on whether it happened.¶

7. Example

A signed EVM receipt (whitespace added for readability; the signed bytes use the canonical form of Section 4):¶

{
  "version": "AIR/1",
  "issued_at": "2026-07-16T09:30:00Z",
  "provider_used": "gpt-4o-mini@example-provider",
  "intent_hash": "b5d4045c3f466fa9...e716e0a1e2789df78",
  "result_hash": "9f86d081884c7d65...d15d6c15b0f00a08",
  "settlement": {
    "tx_hash": "0xabc123...",
    "network": "eip155:8453",
    "amount": "2000",
    "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "facilitator": "https://x402.org/facilitator"
  },
  "issuer": "example-gateway",
  "signature": {
    "algorithm": "secp256k1-eip191",
    "signer": "0x84fA83f3627c7C7e8d...",
    "value": "0x1c9a...ab"
  }
}

8. IANA Considerations

This document requests that IANA create a new registry as described below.¶

9. Security Considerations

Sign the whole object. An implementation MUST NOT sign a subset of fields or a delimiter-joined string; doing so invites field-injection and cross-field ambiguity. Section 5.1 signs the canonical whole, which is the only supported mode.¶

The receipt is not proof of payment. A valid signature proves only that the issuer asserts a settlement. For value-bearing decisions a verifier MUST confirm settlement.tx_hash on-chain, as described in Section 6.¶

Pin the issuer. An unpinned valid signature says only that some holder of some key signed the receipt. A verifier that knows who should have signed MUST pin signature.signer to the expected identity.¶

Canonicalization is load-bearing. Two encoders that disagree on number normalization, member ordering, or string escaping will disagree on hashes and signatures. Implementations MUST follow Section 4 exactly. The number normalization in Section 4 assumes intent and result payloads carry no numbers that require more precision than an integer-valued float can represent; producers SHOULD encode high-precision or large-magnitude quantities as strings.¶

Key separation. The issuer's receipt-signing key SHOULD be distinct in role from any payment key. Even where the same curve is used (for example secp256k1 on EVM), the payment authorization and the receipt use different envelopes and different payloads and MUST NOT be conflated (Section 2).¶

Replay and freshness. AIR/1 does not itself prevent a receipt from being presented more than once. issued_at and the on-chain uniqueness of settlement.tx_hash give a verifier the means to detect duplicates; applications that require single-use semantics MUST enforce them out of band.¶

Algorithm agility and downgrade. Because the suite is named in the receipt, a verifier MUST fail closed on unrecognized suites and MUST NOT silently accept a weaker suite than a policy requires.¶

Appendix A. Test Vectors

This appendix provides deterministic golden test vectors. Any conforming implementation MUST reproduce the exact hash and canonical byte values below from the given inputs, and MUST produce byte-identical signatures given the listed test keys. The keys here are well-known test keys and MUST NOT be used on a live chain.¶

{
  "action": "search",
  "query": "cheapest flight SFO->NRT",
  "constraints": {
    "max_price_usd": 900,
    "nonstop": true
  }
}

{
  "provider": "acme-search",
  "answers": [
    {
      "price_usd": 812
    }
  ]
}

{
  "tx_hash": "0x58f1c0000000000000000000000000000000000000000000000000000000abcd",
  "amount": "0.05",
  "currency": "USDC",
  "chain": "base",
  "facilitator": "facilitator.example",
  "timestamp": "2026-07-16T00:00:00Z"
}

secp256k1 private key: 0x59c6995e998f97a5a0044966f0945389dc9e86dae88c7a8412f4603b6b78690d
ed25519 seed (hex):    000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f

intent_hash = e89e9e4315f34c58f639eb47b4bb627c1565fd39a8475c3b7fd9dab731feffb8
result_hash = 262c92c42f58d42d907971cab83a15de0232cffbdd96461a464bf2c07fc20776

{"intent_hash":"e89e9e4315f34c58f639eb47b4bb627c1565fd39a8475c3b7fd9dab731feffb8","issued_at":"2026-07-16T00:00:00Z","issuer":"issuer.example","provider_used":"acme-search","result_hash":"262c92c42f58d42d907971cab83a15de0232cffbdd96461a464bf2c07fc20776","settlement":{"amount":"0.05","chain":"base","currency":"USDC","facilitator":"facilitator.example","timestamp":"2026-07-16T00:00:00Z","tx_hash":"0x58f1c0000000000000000000000000000000000000000000000000000000abcd"},"signature":{"algorithm":"secp256k1-eip191","signer":"0x70997970C51812dc3A010C7d01b50e0d17dc79C8"},"version":"AIR/1"}

{"intent_hash":"e89e9e4315f34c58f639eb47b4bb627c1565fd39a8475c3b7fd9dab731feffb8","issued_at":"2026-07-16T00:00:00Z","issuer":"issuer.example","provider_used":"acme-search","result_hash":"262c92c42f58d42d907971cab83a15de0232cffbdd96461a464bf2c07fc20776","settlement":{"amount":"0.05","chain":"base","currency":"USDC","facilitator":"facilitator.example","timestamp":"2026-07-16T00:00:00Z","tx_hash":"0x58f1c0000000000000000000000000000000000000000000000000000000abcd"},"signature":{"algorithm":"ed25519","signer":"FAe4sisG95oZ42w7buUn5qEE4TAnfTTFPiguZUHmhiF"},"version":"AIR/1"}

Appendix B. Reference Implementation

The agent_intent_protocol.receipt module of the agent-intent-protocol project implements this specification: canonicalize, hash_object, build_receipt, sign_receipt, verify_receipt, and the secp256k1-eip191 and ed25519 signer/verifier suites. It is provided for interoperability testing and is not normative.¶

Acknowledgments

This work distills the offline-verifiable-receipt idea explored by earlier agent-intent projects into a platform-neutral, x402-native form.¶

Author's Address