Independent Submission A. Ganji Internet-Draft Independent Researcher Intended status: Informational 23 April 2026 Expires: 23 October 2026 Fluid Agentic DeFi Protocol (FADP/1.0): HTTP-Native Micropayment Authentication for Autonomous AI Agents draft-fluid-fadp-01 Abstract This document defines the Fluid Agentic DeFi Protocol (FADP), version 1.0. FADP is an application-layer protocol layered atop HTTP that enables autonomous AI agents to pay for access to web resources using on-chain cryptocurrency transfers, with cryptographic proof of payment embedded directly in HTTP headers. FADP extends HTTP 402 (Payment Required) with two new header fields: X-FADP-Required, which a server uses to communicate payment terms to an agent, and X-FADP-Proof, which an agent uses to supply a verifiable on-chain payment receipt. A nonce-challenge mechanism prevents proof replay. An optional verification endpoint allows third-party on-chain confirmation without requiring the verifying party to run blockchain infrastructure. FADP is designed for agent-to-server and agent-to-agent payment flows operating at sub-dollar granularity (micropayments), where credit- card or OAuth-based billing is impractical. The reference implementation targets USDC on Base (an Ethereum Layer 2), though the protocol is token- and chain-agnostic. About This Document This note is to be removed before publishing as an RFC. This document is submitted as an independent submission to the IETF datatracker. It does not represent the consensus of any IETF working group. The author welcomes discussion on the GitHub repository (https://github.com/fluidbase9/fadp) and via the contact address above. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Ganji Expires 23 October 2026 [Page 1] Internet-Draft FADP April 2026 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 23 October 2026. 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 4. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. X-FADP-Required . . . . . . . . . . . . . . . . . . . . . 6 4.2. X-FADP-Proof . . . . . . . . . . . . . . . . . . . . . . 8 5. Verification Endpoint . . . . . . . . . . . . . . . . . . . . 9 5.1. Verification Request . . . . . . . . . . . . . . . . . . 9 5.2. Verification Response . . . . . . . . . . . . . . . . . . 9 6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Issuing Payment Challenges . . . . . . . . . . . . . . . 10 6.2. Verifying Payment Proofs . . . . . . . . . . . . . . . . 11 7. Agent Behavior . . . . . . . . . . . . . . . . . . . . . . . 11 8. Error Responses . . . . . . . . . . . . . . . . . . . . . . . 12 9. Chain Identifiers . . . . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10.1. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 14 10.2. Overpayment . . . . . . . . . . . . . . . . . . . . . . 15 10.3. Front-Running and Transaction Interception . . . . . . . 15 10.4. Verification Service Trust . . . . . . . . . . . . . . . 15 10.5. Blockchain Finality . . . . . . . . . . . . . . . . . . 16 Ganji Expires 23 October 2026 [Page 2] Internet-Draft FADP April 2026 10.6. Nonce Store Exhaustion . . . . . . . . . . . . . . . . . 16 10.7. Header Injection . . . . . . . . . . . . . . . . . . . . 16 10.8. Transport Security . . . . . . . . . . . . . . . . . . . 16 10.9. Agent Spending Controls . . . . . . . . . . . . . . . . 16 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 11.1. HTTP Header Field Registration . . . . . . . . . . . . . 17 11.2. Media Type . . . . . . . . . . . . . . . . . . . . . . . 17 12. Implementation Notes . . . . . . . . . . . . . . . . . . . . 17 12.1. Reference Implementations . . . . . . . . . . . . . . . 17 12.2. Nonce Storage in Distributed Deployments . . . . . . . . 18 12.3. Amount Precision . . . . . . . . . . . . . . . . . . . . 18 12.4. Cross-Origin Resource Sharing . . . . . . . . . . . . . 18 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 13.1. Normative References . . . . . . . . . . . . . . . . . . 18 13.2. Informative References . . . . . . . . . . . . . . . . . 19 Appendix A: Complete Exchange Example . . . . . . . . . . . . . . 19 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction Autonomous AI agents—software processes that browse the web, call APIs, and complete tasks on behalf of users without per-action human approval—are an emerging class of HTTP client. Unlike human-operated browsers, these agents cannot authenticate themselves to paid services via credit-card billing flows, OAuth consent screens, or similar interactive mechanisms. The practical result is that most commercial APIs are inaccessible to fully autonomous agents, forcing developers to hard-code credentials that cannot be scoped, limited, or revoked per-task. HTTP has carried a 402 (Payment Required) status code since RFC 7231 [RFC7231], but that specification explicitly reserved the code for future use and defined no standard payment handshake. Numerous proprietary schemes have since emerged, but none has achieved broad adoption, and none addresses the specific needs of machine-to-machine micropayments at the scale and frequency that autonomous agents require. Blockchain-based stablecoins—particularly USDC on high-throughput, low-cost Layer 2 networks—have made sub-cent on-chain transfers economically viable for the first time. A transaction settling 0.001 USDC (one-tenth of one cent) on Base costs roughly USD 0.0001 in gas, making per-request billing at very fine granularity practical. FADP defines a minimal, HTTP-native handshake that combines these two properties: the well-understood 402 status code as a payment prompt, and an on-chain transfer as the payment instrument. The protocol Ganji Expires 23 October 2026 [Page 3] Internet-Draft FADP April 2026 requires no browser, no OAuth server, no API-key issuance flow, and no pre-existing billing relationship between the agent and the server. An agent that has a funded wallet and a Fluid agent key can pay for any FADP-gated resource it discovers, at runtime, without human intervention—provided the requested amount is within the agent's pre-configured spending limit. 1.1. Design Goals * *HTTP-native*: the entire payment handshake is expressed in standard HTTP status codes and header fields. No new transport layer is required. * *Stateless from the agent's perspective*: the server supplies all information needed to pay in the 402 response; the agent needs no prior knowledge of the server's payment address or preferred token. * *Replay-safe*: a nonce bound to each payment challenge ensures that a valid payment proof cannot be reused across requests or across sessions. * *Verifier-decoupled*: servers can delegate on-chain verification to a third-party service, removing the need to run or maintain blockchain node infrastructure. * *Token- and chain-agnostic*: while USDC on Base is the reference currency, FADP carries token and chain identifiers in every message and imposes no restriction on supported assets. * *Human-in-the-loop friendly*: spending limits and out-of-band approval flows are outside protocol scope but are natural affordances of agent runtime environments built on FADP. 1.2. Non-Goals * FADP does not specify how agents acquire, store, or rotate their wallet credentials. * FADP does not define a streaming or subscription billing model. Each request-response pair is an independent payment event. * FADP does not mandate a specific blockchain or token. * FADP does not replace existing API authentication schemes; it may operate alongside them. Ganji Expires 23 October 2026 [Page 4] Internet-Draft FADP April 2026 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Agent An autonomous software process that issues HTTP requests on behalf of a user or another automated system, without interactive human approval for each request. Server An HTTP origin server that gates one or more resources behind a FADP payment requirement. Payment Challenge A 402 HTTP response carrying an X-FADP-Required header that specifies the payment terms the agent must satisfy. Payment Proof A JSON object carried in the X-FADP-Proof header of a subsequent request, asserting that the agent has executed an on- chain transfer matching the payment challenge. Nonce A cryptographically random, single-use token embedded in a payment challenge. The server MUST reject any proof whose nonce has already been consumed or has expired. Verification Service An HTTPS endpoint that accepts a payment proof and independently confirms the corresponding on-chain transaction. May be operated by a third party. On-chain Transfer A transaction recorded in a distributed ledger (blockchain) that transfers a specified amount of a digital asset from one address to another. Transaction Hash (txHash) A unique identifier for an on-chain transfer, derived from the cryptographic hash of the transaction data. Immutable once the transaction is finalized. 3. Protocol Overview A FADP interaction consists of three HTTP exchanges: 1. *Initial Request*: The agent sends an ordinary HTTP request to a protected resource, without any payment header. 2. *Payment Challenge*: The server responds with HTTP 402 and an X- FADP-Required header describing the payment terms. The agent executes an on-chain transfer matching those terms. Ganji Expires 23 October 2026 [Page 5] Internet-Draft FADP April 2026 3. *Authenticated Request*: The agent repeats the original request, adding an X-FADP-Proof header that references the completed on- chain transfer and the challenge nonce. The server verifies the proof and, if valid, fulfills the request. Agent Server Verifier | | | | GET /resource | | |----------------------------->| | | | | | 402 Payment Required | | | X-FADP-Required: { | | | version, amount, token, | | | chain, payTo, nonce, | | | expires, verifyUrl } | | |<-----------------------------| | | | | | [Agent executes on-chain transfer to payTo] | | [Receives txHash from blockchain] | | | | | GET /resource | | | X-FADP-Proof: { | | | txHash, nonce, timestamp }| | |----------------------------->| | | | POST verifyUrl | | | { txHash, payTo, | | | amount, token, | | | chain, nonce } | | |------------------------->| | | | | | { verified: true, | | | from, to, amount } | | |<-------------------------| | | | | 200 OK + resource data | | |<-----------------------------| | Figure 1: FADP Full Handshake 4. Header Fields 4.1. X-FADP-Required The X-FADP-Required response header field is sent by the server in a 402 response. Its value is a JSON object with the following members: version REQUIRED. String. MUST be "1.0" for this version of the protocol. Ganji Expires 23 October 2026 [Page 6] Internet-Draft FADP April 2026 amount REQUIRED. String. The amount of the specified token that the agent MUST transfer, expressed as a decimal number (e.g., "0.001"). The server SHOULD use the minimal number of decimal places necessary to avoid ambiguity. token REQUIRED. String. The symbol of the digital asset to be transferred (e.g., "USDC", "ETH", "USDT"). The symbol SHOULD conform to the canonical symbol registered with the issuer or a well-known token list. chain REQUIRED. String. The identifier of the blockchain network on which the transfer must be executed. Registered values include "base" (Base Mainnet), "ethereum" (Ethereum Mainnet), and "solana" (Solana Mainnet). Implementors MAY define additional chain identifiers using reverse-DNS notation to avoid collision. payTo REQUIRED. String. The blockchain address of the server operator's wallet. For EVM-compatible chains, this MUST be a checksummed Ethereum address (EIP-55). nonce REQUIRED. String. A cryptographically random, single-use token generated by the server for this payment challenge. The server MUST ensure that each nonce is unique across all active challenges. The nonce MUST be at least 16 bytes of entropy, encoded as a lowercase hexadecimal string (minimum 32 characters). expires REQUIRED. Number. A Unix timestamp (seconds since epoch) indicating when this payment challenge expires. The server MUST reject proofs referencing a nonce whose expiry has passed. The RECOMMENDED default TTL is 300 seconds (5 minutes). description OPTIONAL. String. A human-readable description of the resource or service being paid for (e.g., "Premium market data API"). Intended for display in agent UIs and transaction logs. verifyUrl OPTIONAL. String. An HTTPS URL identifying the verification service the server will use to confirm payment proofs. If omitted, the default is https://fluidnative.com/v1/fadp/verify. Servers operating their own verification infrastructure SHOULD set this field. Example value (formatted for readability; actual header value MUST be a single-line JSON string): Ganji Expires 23 October 2026 [Page 7] Internet-Draft FADP April 2026 { "version": "1.0", "amount": "0.001", "token": "USDC", "chain": "base", "payTo": "0xAbCd1234AbCd1234AbCd1234AbCd1234AbCd1234", "nonce": "a3f9c2b1d4e5f6a7b8c9d0e1f2a3b4c5", "expires": 1745001234, "description": "GPT-4o inference via OpenRouter proxy", "verifyUrl": "https://fluidnative.com/v1/fadp/verify" } 4.2. X-FADP-Proof The X-FADP-Proof request header field is sent by the agent in the authenticated request. Its value is a JSON object with the following members: txHash REQUIRED. String. The transaction hash of the on-chain transfer executed by the agent in response to the payment challenge. For EVM-compatible chains, this is a 0x-prefixed 32-byte hex string. nonce REQUIRED. String. The nonce value copied verbatim from the X-FADP-Required header of the payment challenge to which this proof responds. The server MUST verify that this nonce matches a known, unexpired, unconsumed challenge. timestamp REQUIRED. Number. A Unix timestamp (seconds since epoch) representing the time at which the agent assembled this proof. The server SHOULD reject proofs where |currentTime - timestamp| > 300 seconds. agentKeyPrefix OPTIONAL. String. A non-sensitive prefix of the agent's credential (e.g., the first 8 characters of a fwag_ key), used for logging and audit. Implementations MUST NOT include the full credential. Example: { "txHash": "0xabc1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcd", "nonce": "a3f9c2b1d4e5f6a7b8c9d0e1f2a3b4c5", "timestamp": 1745001200, "agentKeyPrefix": "fwag_a3f9" } Ganji Expires 23 October 2026 [Page 8] Internet-Draft FADP April 2026 5. Verification Endpoint The verification endpoint is an HTTPS resource that the server (or its delegate) calls to confirm that a payment proof corresponds to a valid on-chain transfer. This section defines the request and response formats for that endpoint. 5.1. Verification Request The server sends an HTTP POST to the verifyUrl with a JSON body containing: txHash REQUIRED. String. The transaction hash from the agent's proof. payTo REQUIRED. String. The wallet address that should have received the transfer. amount REQUIRED. String. The amount that should have been transferred. token REQUIRED. String. The token symbol. chain REQUIRED. String. The chain identifier. nonce REQUIRED. String. The nonce from the original challenge. 5.2. Verification Response The verification service responds with a JSON object: verified REQUIRED. Boolean. true if and only if all of the following conditions hold: * The transaction identified by txHash exists on the specified chain. * The transaction status is finalized (not reverted). * The recipient address matches payTo. * The transferred amount is greater than or equal to the required amount. * The transferred token matches the required token. txHash OPTIONAL. String. Echo of the verified transaction hash. Ganji Expires 23 October 2026 [Page 9] Internet-Draft FADP April 2026 amount OPTIONAL. String. The actual transferred amount. token OPTIONAL. String. The actual transferred token symbol. chain OPTIONAL. String. The chain on which the transfer occurred. from OPTIONAL. String. The sender's wallet address. to OPTIONAL. String. The recipient's wallet address (SHOULD match payTo). error OPTIONAL. String. A human-readable error message when verified is false. Example successful response: { "verified": true, "txHash": "0xabc123...", "amount": "0.001", "token": "USDC", "chain": "base", "from": "0xAgentWallet...", "to": "0xServerWallet..." } Example failed response: { "verified": false, "error": "Transfer amount 0.0005 USDC is less than required 0.001 USDC" } 6. Server Behavior 6.1. Issuing Payment Challenges When a server receives a request for a FADP-protected resource without an X-FADP-Proof header, it MUST: 1. Generate a nonce of at least 16 bytes of cryptographically secure random data. 2. Record the nonce and its expiry time in durable server-side storage (memory, cache, or database). 3. Respond with HTTP 402. Ganji Expires 23 October 2026 [Page 10] Internet-Draft FADP April 2026 4. Set the X-FADP-Required header to a JSON object as defined in Section 4.1. 5. Set Access-Control-Expose-Headers: X-FADP-Required to ensure cross-origin agents can read the header. 6.2. Verifying Payment Proofs When a server receives a request with an X-FADP-Proof header, it MUST perform the following checks in order, returning an appropriate error response if any check fails: 1. Parse the header value as JSON; return 400 if malformed. 2. Verify that txHash, nonce, and timestamp are present; return 400 if any is absent. 3. Look up the nonce in server-side storage; return 402 if the nonce is unknown. 4. Verify the nonce has not expired; return 402 if expired (delete the nonce). 5. Verify that |currentTime - proof.timestamp| <= 300 seconds; return 402 if outside range. 6. Call the verification service at verifyUrl; return 402 if verified is false. 7. Atomically mark the nonce as consumed (delete it from storage) to prevent replay. 8. Proceed to handle the original request. Step 7 (nonce consumption) MUST occur before the server fulfills the request. If the server cannot atomically consume the nonce and fulfill the request (e.g., due to a crash), it SHOULD err on the side of not consuming the nonce, accepting the risk of a duplicate fulfillment rather than silently accepting payment without delivering service. 7. Agent Behavior An agent implementation SHOULD: 1. On receiving a 402 with X-FADP-Required, validate that the requested amount does not exceed the agent's configured spending limit before proceeding. Ganji Expires 23 October 2026 [Page 11] Internet-Draft FADP April 2026 2. Execute the on-chain transfer to the address and chain specified in the payment challenge, transferring at least the specified amount of the specified token. 3. Await sufficient blockchain confirmation before constructing the proof. The definition of "sufficient" is implementation- specific; at minimum, the transaction MUST appear in a block (status: success) before the proof is submitted. 4. Construct an X-FADP-Proof object containing the txHash, the nonce from the challenge, and the current Unix timestamp. 5. Retry the original request with the X-FADP-Proof header added. 6. If the server returns another 402 with a new nonce (e.g., because the previous nonce expired), restart the payment flow. An agent MUST NOT reuse a txHash or nonce across separate request/ response cycles. Each resource access requires a fresh payment and a fresh proof. 8. Error Responses FADP servers SHOULD include a JSON body in all error responses with at least the following fields: error String. A machine-readable error key. protocol String. SHOULD be "FADP/1.0" to identify the protocol version. detail String. OPTIONAL human-readable elaboration. Ganji Expires 23 October 2026 [Page 12] Internet-Draft FADP April 2026 +========+=========================+=============================+ | HTTP | Condition | Recommended error value | | Status | | | +========+=========================+=============================+ | 400 | Malformed X-FADP-Proof | invalid_proof_format | | | header (not valid JSON) | | +--------+-------------------------+-----------------------------+ | 400 | Missing required fields | missing_proof_fields | | | in proof | | +--------+-------------------------+-----------------------------+ | 402 | No proof header present | payment_required | | | (initial challenge) | | +--------+-------------------------+-----------------------------+ | 402 | Nonce unknown (never | unknown_nonce | | | issued or already | | | | expired from store) | | +--------+-------------------------+-----------------------------+ | 402 | Nonce expired (TTL | nonce_expired | | | elapsed) | | +--------+-------------------------+-----------------------------+ | 402 | Proof timestamp too old | proof_timestamp_invalid | | | or too far in future | | +--------+-------------------------+-----------------------------+ | 402 | On-chain verification | payment_verification_failed | | | returned verified: | | | | false | | +--------+-------------------------+-----------------------------+ | 402 | Transferred amount less | insufficient_payment | | | than required | | +--------+-------------------------+-----------------------------+ | 403 | Nonce has already been | nonce_already_used | | | consumed (replay | | | | attempt) | | +--------+-------------------------+-----------------------------+ Table 1: FADP Error Conditions 9. Chain Identifiers FADP uses short string identifiers for blockchain networks. The following values are defined by this specification: Ganji Expires 23 October 2026 [Page 13] Internet-Draft FADP April 2026 +==============+===============+=================+==============+ | Identifier | Network | Native Currency | EVM Chain ID | +==============+===============+=================+==============+ | base | Base Mainnet | ETH | 8453 | | | (Coinbase L2) | | | +--------------+---------------+-----------------+--------------+ | ethereum | Ethereum | ETH | 1 | | | Mainnet | | | +--------------+---------------+-----------------+--------------+ | solana | Solana | SOL | N/A | | | Mainnet Beta | | | +--------------+---------------+-----------------+--------------+ | injective | Injective | INJ | N/A | | | Mainnet | | | +--------------+---------------+-----------------+--------------+ | base-sepolia | Base Sepolia | ETH | 84532 | | | Testnet | | | +--------------+---------------+-----------------+--------------+ Table 2: FADP Chain Identifier Registry Implementors that wish to support chains not listed here SHOULD use identifiers of the form {namespace}-{networkname} to avoid collisions with future registered values. 10. Security Considerations 10.1. Replay Attacks The nonce mechanism is the primary defense against replay attacks. A valid txHash from a past payment cannot be reused because: 1. Each payment challenge carries a unique nonce. 2. The proof MUST echo that nonce. 3. The server atomically consumes the nonce upon first successful verification. 4. Subsequent proofs referencing the same nonce are rejected with 403. Server implementations MUST use cryptographically secure random number generation for nonces (e.g., /dev/urandom or equivalent). Predictable nonces would allow an attacker to pre-compute valid proofs. Ganji Expires 23 October 2026 [Page 14] Internet-Draft FADP April 2026 The nonce store MUST be shared across all instances of a horizontally scaled server deployment. If a local per-process nonce store is used, the same nonce could be accepted by two different instances simultaneously, creating a replay window. A distributed cache (e.g., Redis) or a database with atomic compare-and-delete operations is RECOMMENDED for production deployments. 10.2. Overpayment The verification service checks that the transferred amount is _at least_ the required amount. Servers SHOULD NOT issue refunds for overpayments, as the complexity of doing so on-chain outweighs the benefit for small amounts. Agents SHOULD transfer exactly the required amount to avoid unnecessary token loss. 10.3. Front-Running and Transaction Interception In principle, an attacker observing the agent's on-chain transaction in the mempool could copy the txHash and attempt to submit a proof before the legitimate agent. This attack is mitigated by: 1. The nonce binding: the attacker must have obtained the nonce from a legitimate 402 challenge targeted at their own session. Nonces are per-session and cannot be forged. 2. The proof timestamp check: the server rejects proofs assembled more than 300 seconds after the challenge was issued. Servers that require strong session binding MAY add an additional check verifying that the HTTP session initiating the proof matches the session that triggered the original challenge (e.g., via a session cookie or TLS channel binding), though this is outside the scope of the current protocol version. 10.4. Verification Service Trust Servers that delegate verification to a third-party service are implicitly trusting that service's honesty and availability. A compromised or malicious verification service could return verified: true for invalid proofs, allowing unauthorized access. Servers operating in high-value contexts SHOULD run their own verification infrastructure against a direct blockchain RPC endpoint. The verification endpoint API defined in Section 5 is designed to be self-hostable for this reason. Ganji Expires 23 October 2026 [Page 15] Internet-Draft FADP April 2026 10.5. Blockchain Finality On chains with probabilistic finality (including Ethereum and Base), a transaction that appears in a block may be reorged out of the canonical chain. Servers accepting payments for high-value resources SHOULD wait for a chain-specific number of confirmation blocks before accepting a proof as final. For low-value micropayments on Base (an optimistic rollup with fast soft-finality), a single block confirmation is typically sufficient. Verification services MUST check that the transaction receipt status indicates success (i.e., it was not reverted), not merely that a transaction with the given hash exists. 10.6. Nonce Store Exhaustion An adversary could generate large numbers of initial requests to force the server to allocate nonces, potentially exhausting memory if the nonce store grows without bound. Server implementations MUST periodically prune expired nonces and SHOULD rate-limit the issuance of payment challenges per IP address or session. 10.7. Header Injection The X-FADP-Required and X-FADP-Proof header values are JSON strings. Implementations MUST parse these with a conformant JSON parser and MUST NOT construct them via string interpolation without proper escaping, to prevent injection attacks. 10.8. Transport Security All FADP exchanges, including calls to the verification service, MUST be made over TLS (HTTPS). Transmitting payment challenges or proofs over plaintext HTTP exposes the nonce to network adversaries, potentially enabling race-condition replay attacks. 10.9. Agent Spending Controls FADP does not define agent-side spending controls; these are the responsibility of the agent runtime. However, agent implementors MUST validate the requested amount in the payment challenge against a pre-configured limit before executing any transfer. Failing to do so could allow a malicious server to drain an agent's wallet by issuing artificially large payment challenges. Ganji Expires 23 October 2026 [Page 16] Internet-Draft FADP April 2026 11. IANA Considerations 11.1. HTTP Header Field Registration This document requests registration of the following header fields in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at https://www.iana.org/assignments/http-fields/. Header Field Name X-FADP-Required Status provisional Reference This document, Section 4.1 Header Field Name X-FADP-Proof Status provisional Reference This document, Section 4.2 11.2. Media Type No new media types are registered by this document. All message bodies are application/json as defined in [RFC8259]. 12. Implementation Notes 12.1. Reference Implementations Reference implementations of the server middleware (fadpGate()) and client interceptor (fadpFetch()) are available as open-source software: * *fluid-fadp* (npm): server middleware and standalone client interceptor for Node.js / TypeScript. Repository: https://github.com/fluidbase9/fadp * *fluid-wallet-agentkit* (npm): full agent SDK incorporating FADP auto-pay via the agent.fetch() method. Repository: https://github.com/fluidbase9/fluidwalletbase * *fluid-fadp-proxy* (npm): a ready-made reverse proxy that gates commercial AI service APIs (OpenRouter, RunPod, Vast.ai, Spheron) behind FADP payment walls. Repository: https://github.com/fluidbase9/fadp-proxy Ganji Expires 23 October 2026 [Page 17] Internet-Draft FADP April 2026 12.2. Nonce Storage in Distributed Deployments For single-process servers, an in-memory Map with periodic TTL pruning is sufficient. For multi-instance deployments, a shared store with atomic operations is required. A Redis SET NX EX command provides an atomic "set if not exists with expiry" primitive suitable for nonce issuance; a Redis DEL returning the count of deleted keys provides atomic consumption. 12.3. Amount Precision Token amounts MUST be represented as decimal strings to avoid floating-point precision loss. On-chain, USDC uses 6 decimal places; the string "0.001" corresponds to on-chain value 1000 (in the smallest unit). Implementations MUST convert between decimal string and on-chain integer representation using fixed-point arithmetic, not IEEE 754 floating-point. 12.4. Cross-Origin Resource Sharing Browser-based agent implementations require that X-FADP-Required be listed in the Access-Control-Expose-Headers response header for the 402 response. Servers MUST set this header when cross-origin clients are expected. 13. References 13.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, . [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 8259, DOI 10.17487/RFC8259, December 2017, . Ganji Expires 23 October 2026 [Page 18] Internet-Draft FADP April 2026 [RFC9110] Fielding, R., Nottingham, M., and J. Reschke, "HTTP Semantics", RFC 9110, DOI 10.17487/RFC9110, June 2022, . 13.2. Informative References [BASE-L2] Coinbase, "Base: An Ethereum L2 for the Next Billion Users", Technical overview, base.org, 2023. Base Mainnet is the reference deployment chain for FADP's reference implementation. [EIP-20] Vogelsteller, F. and V. Buterin, "ERC-20 Token Standard", Ethereum Improvement Proposal 20, November 2015. Defines the fungible token interface implemented by USDC and most payment tokens used with FADP. [EIP-55] Buterin, V., "Mixed-case checksum address encoding", Ethereum Improvement Proposal 55, January 2016. Defines the checksummed Ethereum address format used in FADP address fields. [x402] Coinbase Developer Platform, "x402: An Open HTTP Payment Protocol", github.com/coinbase/x402, 2025. A contemporaneous HTTP 402-based payment protocol from Coinbase. FADP shares the 402 status code and on-chain settlement approach but differs in nonce mechanism, header naming, and protocol extensibility design. Appendix A: Complete Exchange Example The following illustrates a complete FADP exchange over HTTP/1.1. *Step 1 — Initial Request (no proof):* POST /v1/chat/completions HTTP/1.1 Host: proxy.example.com Content-Type: application/json {"model":"openai/gpt-4o","messages":[{"role":"user","content":"Hello"}]} *Step 2 — Payment Challenge:* Ganji Expires 23 October 2026 [Page 19] Internet-Draft FADP April 2026 HTTP/1.1 402 Payment Required Content-Type: application/json X-FADP-Required: {"version":"1.0","amount":"0.001","token":"USDC", "chain":"base","payTo":"0xAbCd1234AbCd1234AbCd1234AbCd1234AbCd1234", "nonce":"a3f9c2b1d4e5f6a7b8c9d0e1f2a3b4c5","expires":1745001534, "description":"GPT-4o inference","verifyUrl":"https://fluidnative.com/v1/fadp/verify"} Access-Control-Expose-Headers: X-FADP-Required {"error":"Payment required","protocol":"FADP/1.0"} *Step 3 — Agent executes on-chain USDC transfer on Base, receives txHash.* *Step 4 — Authenticated Request:* POST /v1/chat/completions HTTP/1.1 Host: proxy.example.com Content-Type: application/json X-FADP-Proof: {"txHash":"0xabc123...","nonce":"a3f9c2b1d4e5f6a7b8c9d0e1f2a3b4c5", "timestamp":1745001480} {"model":"openai/gpt-4o","messages":[{"role":"user","content":"Hello"}]} *Step 5 — Successful Response (after on-chain verification):* HTTP/1.1 200 OK Content-Type: application/json {"choices":[{"message":{"role":"assistant","content":"Hello! How can I help?"}}]} Acknowledgements The author thanks the teams building open agent infrastructure across the Ethereum, Base, and Solana ecosystems whose work made practical micropayment settlement possible. The design of FADP was informed by the x402 protocol from Coinbase Developer Platform, the Model Context Protocol (MCP), and early feedback from developers building autonomous agents on the Fluid Wallet platform. Author's Address Abhijeeth Ganji Independent Researcher (Research Project: Fluid Wallet) Email: fluidbase9@gmail.com URI: https://fluidnative.com Ganji Expires 23 October 2026 [Page 20]