Interesting. I couldn't get that working with Coinbase wallet or Metamask from FF on Android.
Is there a contract structure that obviates the need for Ether, or in there somewhere am I buying ether and USDC from somewhere and I just don't see that interaction?
Blockchains are fast and and cheap now! Modern blockchains like Base, Solana, Sui (and many more) typically have block times <2 seconds, and a stablecoin transfer can cost as little as $0.0005 independent of the $ amount being transfered
its not that 402 isn't used, its that there is no standard response, which makes it hard for AI agents to pay for access.
x402 provides a standard response format clients can programmatically use to create a payment, either using crypto assets like stablecoins, or in future, fiat methods.
>Given that this runs atop Payment Required, doesn’t this mean that each API request would involve an extra one or two data transfers?
Yes, assuming its the first time you've interacted with an API endpoint and don't have cached payment requirements.
>Is there a reason why you wouldn’t pay ahead of time? I just understand why you couldn’t buy a few dozen/hundred/thousand dollars worth of credits, and wait until it runs low.
This would require manually integrating each vendor, which is totally valid if your agent performs a lot of a single type of task, but we suspect over time there will be huge value in agents being able to dynamically select tools / apis they want to use to accomplish their tasks, and dynamically pay for what they use
This depends on the implementation on the underlying network, but basically the spending signs an authorization for transfer, and the merchant either settles that onchain themselves or delegates to what is called a facilitator that settles on their behalf. On EVM chains for the exact payment scheme this leverages EIP-3009 signatures
> AP2 builds trust by using Mandates—tamper-proof, cryptographically-signed digital contracts that serve as verifiable proof of a user's instructions. These mandates are signed by verifiable credentials (VCs) and act as the foundational evidence for every transaction.
> How can or should a Blockcert indicate an ILP Interledger Protocol address or a Payment Pointer?
In order to avoid DNS. Basically because gethostbyname() does not indicate DNSSEC validation status, or channel sec status e.g. whether there's DoH/DoT/DoQ at every edge in the DNS network), or CT Certificate Transparency log cert revocation status (and OCSP and CRL are in-band))
How can ILP and x402 (and IDK EDNS) be integrated? Are they complementary?
> Think of x402 as the universal "cash register" signal and ILP as the versatile "payment network" that can handle any currency. [...] and pathfinding with path cost and HTA Hashed-Timelock Agreements for the whole path, with an auditable open spec message standard that accounts for each of the Connectors involved (who specify credit limits).
> So, x402 can signal the need for a payment, and ILP can be the underlying mechanism to fulfill that payment request, regardless of the user's preferred currency or payment provider
How do x402 and ILP SPSP Simple Payment Setup Protocol compare in terms of signaling the need for a payment?
> SPSP is a simplified, connectionless mode of Interledger that is often used for streaming micropayments, as seen in the Web Monetization standard. The signaling is more implicit and is discovered through HTML/HTTP, rather than being an HTTP status code itself.
> The new W3C Payment Request API [4] makes it easy for browsers to offer a standard (and probably(?) already accessible) interface for the payment data entry screen, at least.https://www.w3.org/TR/payment-request/
There's probably a better HTTP Status dog for 402?
x402 as a protocol has no fees, but the underlying network transactions are conducted on my have costs. Merchants can choose the underlying network transactions are conducted on that best fit their usecase. x402 also has the concept of a facilitator, which exists to abstract away the underlying payment networks. Many facilitators (including Coinbase's) subsidize the gas used for transactions.
(x402 author here) Thats actually exactly what the intention with x402 is. Merchants express to the buyer multiple ways that they accept payment and the buyer chooses the one they prefer.
As of right now stablecoins on various crypto rails are the major form (largely because they're the easiest to start with from a development standpoint), but as Cloudflare indicated in their blogpost, they're proposing a scheme that uses deferred payment via credit card or ACH https://blog.cloudflare.com/x402/.
Hi Erik. Frankly, I wonder if this is an elaborate joke since there are some serious concerns in terms of CVP ("wait two seconds and retry"), in terms of gatekeeping potential nobody will sleepwalk in to ("we solve two the second wait with our CoinbaseCoin, get an enterprise subscription!"), or in terms of the inherent lack of openness in HTTP these days (client/server, HTTPS identity chains, DNS, gatekeepers like CloudFlare). For thoughts on a more open protocol without these drawbacks see https://raw.githubusercontent.com/globalcitizen/ifex-protoco... Sincerely, architect of a predecessor exchange (founder asked me not to continue work on open protocols).
we will happy accept PRs the add support for any chains that can perform the payment flows in a safe, non-custodial way for the client, resource server and faciliator. Currently x402 works with any EVM chain, and we're working with several chains on integrating.
