



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,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC7231]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,
              <https://www.rfc-editor.org/rfc/rfc7231>.

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

   [RFC8259]  Bray, T., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 8259, DOI 10.17487/RFC8259,
              December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.





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,
              <https://www.rfc-editor.org/rfc/rfc9110>.

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]
