# X Pay ## The Payment Layer for AI and APIs **Version 0.2, draft for review. August 2026.** --- ## Abstract The internet has a payment gap. HTTP has carried a status code reserved for payment since 1997, but no usable standard ever filled it, so the web grew a monetization stack built entirely around human buyers: accounts, cards, subscriptions and API keys. That stack fails at the exact moment software becomes the buyer. An autonomous agent cannot complete a signup form, accept terms of service or type a card number, and no card network will profitably clear a payment of two hundredths of a cent. X Pay is programmable payment infrastructure built on the x402 standard. It lets any HTTP endpoint quote a price, receive a cryptographically signed payment authorization, and serve its response inside a single round trip. Authorization happens offchain in milliseconds. Settlement happens onchain in stablecoins. The merchant never touches card rails, never carries chargeback risk and never builds a billing system. This paper describes the problem, the protocol in detail, the X Pay architecture, the verification algorithm, the security and threat model, the product surface, the token design, and the open problems that remain unsolved. :::info Reading this document Sections 1 to 4 are the case and the background. Section 5 is the protocol in detail and is the part an engineer should read first. Sections 10 and 16 are the parts an investor or a partner should read first, because they are where the unresolved risk lives. ::: --- ## 1. Introduction Two shifts are converging. The first is economic. Software is moving from things people operate to things people delegate to. An agent that plans a trip, reconciles a ledger or researches a market does not make one large purchase. It makes thousands of small ones: a geocoding lookup, a currency conversion, a document parse, a model call. Each is worth a fraction of a cent. Aggregated across a fleet of agents running continuously, they are worth a great deal. The second is technical. Stablecoin settlement on low fee networks has made a payment of $0.0002 economically real for the first time. The cost of moving value has fallen below the value being moved. What has been missing is the connective tissue: a way for a machine to discover a price, agree to it and pay it without a human in the loop, using infrastructure the machine already speaks. That infrastructure is HTTP. X Pay exists to make that round trip work in production. @diagram[handshake] --- ## 2. The problem ### 2.1 The monetization stack is built for humans To sell an API today, a developer assembles a stack that has almost nothing to do with the API itself: - user registration, email verification and account recovery - card processing, with its PCI scope, chargebacks and fraud review - subscription tiers that either under serve or over serve nearly every customer - API key issuance, rotation and revocation - usage metering, quota enforcement and invoice generation - dunning, refunds and reconciliation This is months of work that produces no product value. It is also a permanent tax: every one of those systems has to be maintained, secured and supported forever. ### 2.2 It excludes the fastest growing class of buyer Every element above assumes a human. An agent cannot register an account, cannot legally accept terms on its own behalf, and must not be handed a raw card credential. The workarounds in use today are all unsatisfying: - **A human pre provisions an API key.** This binds spend to a static secret with no per call ceiling. A leaked or misused key is an unbounded liability. - **A human prepays a balance.** This works, but only inside one vendor. It does not compose across the open web, and it cannot pay a service the agent discovers at runtime. - **The agent shares a card.** This is the outcome nobody wants, and it is what happens when no better primitive exists. ### 2.3 Small payments are structurally impossible on card rails A card transaction carries a fixed cost of roughly twenty to thirty cents plus a percentage. Selling a $0.002 API call over card rails loses money by two orders of magnitude. The only way to sell cheap things on expensive rails is to bundle them into a subscription, which is precisely the model that fails variable, bursty, machine driven demand. @diagram[cost] The result is a web where an enormous amount of value cannot be priced at all. --- ## 3. Background: HTTP 402 and the x402 standard RFC 7231 reserves status code **402 Payment Required** with the note that it is reserved for future use. It sat unused for a quarter of a century because there was no settlement layer fast or cheap enough to sit behind it. The x402 standard fills that gap. In outline: 1. A client requests a protected resource with no payment attached. 2. The server responds `402 Payment Required` together with a machine readable quote describing what payment would satisfy the request: scheme, amount, asset, network and recipient. 3. The client constructs a payment authorization, signs it, and retries the request with the authorization attached in a header. 4. The server verifies the authorization, serves the response, and settles the payment. The design has three properties that matter: - **It is in band.** No redirect, no hosted checkout page, no callback. The payment lives in the same request and response cycle as the resource. - **It is machine readable.** The quote is structured data, not a pricing page. Software can parse it, compare it against a budget and act. - **It is credential free.** A valid payment authorization is itself proof of entitlement. There is no separate API key to issue or revoke. x402 defines the handshake. It does not, on its own, give a merchant a gateway, a dashboard, a wallet with spending controls, payouts or a place to be discovered. That is the gap X Pay fills. :::note The standard is settled This was the largest open risk in the previous version of this document, and it has closed. The **x402 Foundation** launched under the **Linux Foundation in July 2026** with forty member organizations and open governance, independent of any single company. Premier members include Visa, Mastercard, American Express, Stripe, Adyen, Fiserv, Google, AWS, Cloudflare, Circle and Shopify. In its first year the protocol carried over 169 million payments across roughly 590,000 buyers and 100,000 sellers. An implementation should still pin a protocol version, because a governed standard continues to evolve. But the question is no longer whether machines will pay over HTTP. It is who runs the layer that turns the handshake into a business. ::: --- ## 4. Design principles **Payment is a property of the request, not a separate flow.** Anything that redirects, opens a window or requires a callback cannot be used by software. The handshake must complete inside one exchange. **Never hold a response behind a block.** Latency is the product. A design that inherits chain latency has already failed the workload it exists to serve. **Bound the blast radius before signing.** For an autonomous spender, controls that run after a signature exists are decoration. Every limit is enforced while refusal is still free. **Settle in something stable.** Nobody prices an API in a volatile asset. The token is for alignment, not for denomination. **Be honest about what is not built.** A payment system earns trust by being precise about its failure modes, not by omitting them. --- ## 5. The protocol ### 5.1 Objects Three objects carry the whole protocol. **Quote.** Issued with a 402. It describes what payment would satisfy the request. ```json { "x402Version": 1, "scheme": "exact", "network": "base", "asset": "USDC", "assetAddress": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "amount": "2000", "decimals": 6, "payTo": "0xA1c4...9F2b", "resource": "/v1/summarize", "nonce": "0x7f3a...c81d", "validBefore": 1786412400, "expiresIn": 120 } ``` `amount` is in atomic units, so `2000` at six decimals is $0.002. Amounts are never floats, and never travel as decimal strings, because a rounding disagreement between payer and payee is a dispute. **Authorization.** Produced by the payer, signed, and sent back in the `X-Payment` header. Under the `exact` scheme on EVM networks it is an EIP-3009 `transferWithAuthorization` payload signed as EIP-712 typed data: ```json { "x402Version": 1, "scheme": "exact", "network": "base", "payload": { "from": "0x9dE4...71aC", "to": "0xA1c4...9F2b", "value": "2000", "validAfter": "0", "validBefore": "1786412400", "nonce": "0x7f3a...c81d", "signature": "0x4c8b...1f00" } } ``` The header is the base64 encoding of that JSON, because header values must be ASCII safe. **Receipt.** Returned with the successful response in `X-Payment-Response`, and retained by both sides. ```json { "settled": true, "txHash": "0x7d1e...44b9", "network": "base", "amount": "2000", "asset": "USDC", "payer": "0x9dE4...71aC", "settledAt": "2026-08-03T14:21:07Z" } ``` Receipts are the basis of reconciliation, refunds and dispute handling. They are the only artefact that survives the request. ### 5.2 The wire exchange ```http GET /v1/summarize HTTP/1.1 Host: api.acme.dev HTTP/1.1 402 Payment Required X-Payment-Required: eyJ4NDAyVmVyc2lvbiI6MSwic2NoZW1lIjoiZXhhY3QiLCJu... Content-Type: application/json GET /v1/summarize HTTP/1.1 Host: api.acme.dev X-Payment: eyJ4NDAyVmVyc2lvbiI6MSwicGF5bG9hZCI6eyJmcm9tIjoiMHg5ZEU0... HTTP/1.1 200 OK X-Payment-Response: eyJzZXR0bGVkIjp0cnVlLCJ0eEhhc2giOiIweDdkMWUuLi4i... Content-Type: application/json {"summary": "..."} ``` ### 5.3 Why EIP-3009 `transferWithAuthorization` lets a holder sign a transfer that **someone else submits and pays gas for**. That single property is what makes x402 usable: - the payer needs no native gas token, only the stablecoin - the payer never sends a transaction, so there is no wallet popup and no pending state to poll - the signature is scoped to an exact amount, recipient, validity window and nonce - the facilitator, not the payer, absorbs gas and can batch A payer with $5 of USDC and zero ETH can transact. For an agent, which cannot be expected to manage a gas balance across chains, this is not a convenience. It is the difference between working and not working. ### 5.4 The verification algorithm Verification is the security boundary of the entire system. It runs on every paid request, and it must complete in single digit milliseconds. ``` verify(quote, authorization): 1. version and scheme must match the quote 2. payload.to == quote.payTo else REJECT wrong_recipient 3. payload.value == quote.amount else REJECT wrong_amount 4. payload.nonce == quote.nonce else REJECT nonce_mismatch 5. now < payload.validBefore else REJECT expired 6. now >= payload.validAfter else REJECT not_yet_valid 7. signer = recoverTypedDataAddress( domain: { name, version, chainId, verifyingContract: assetAddress }, types: TransferWithAuthorization, message: payload, signature: payload.signature ) signer == payload.from else REJECT bad_signature 8. atomically claim payload.nonce in the store already claimed else REJECT replay 9. balanceOf(payload.from) >= value else REJECT insufficient_funds (advisory, may be cached) ACCEPT ``` Steps 1 to 7 are pure computation and need no network. Step 8 is the only strongly consistent write on the hot path, which is why the nonce store is the component with the tightest latency and consistency budget in the system. :::danger Step 8 is the one that matters Every other check fails safe. If the nonce claim is not atomic, the same authorization can be spent twice concurrently, and the merchant serves two responses for one payment. A read then write is not sufficient. It must be a single atomic operation against a store with strong consistency. ::: ### 5.5 Error taxonomy A gateway returns `402` for anything the client can fix by paying correctly, and `4xx` or `5xx` for everything else. Machine readable codes matter more than messages, because the consumer is software. | Code | Status | Meaning | Client should | | --- | --- | --- | --- | | `payment_required` | 402 | No authorization attached | Sign the quote and retry | | `expired` | 402 | Quote or authorization past `validBefore` | Request a fresh quote | | `wrong_amount` | 402 | Value does not equal the quote | Re-sign against the quote | | `wrong_recipient` | 402 | `to` is not `payTo` | Re-sign against the quote | | `bad_signature` | 402 | Recovered signer is not `from` | Check signing domain and chain id | | `replay` | 409 | Nonce already claimed | Request a fresh quote | | `insufficient_funds` | 402 | Payer balance below value | Fund the wallet | | `unsupported_network` | 400 | Network not enabled for this route | Read `/v1/networks` | | `rate_limited` | 429 | Too many requests | Back off and retry | --- ## 6. Architecture ### 6.1 Components @diagram[architecture] **Gateway.** Middleware, plus a hosted edge service, that sits in front of a merchant endpoint. It resolves the price for the route, issues the 402 quote, verifies inbound authorizations, enforces replay protection and releases the response. **Facilitator.** The settlement service. It takes verified authorizations, submits them onchain, batches where batching is safe, tracks confirmation and produces receipts. Separating the facilitator from the gateway is what allows a response to be served before a block is confirmed. **Nonce and quote store.** The strongly consistent component. It holds unexpired quotes and claimed nonces, and it is the only thing in the path that cannot be eventually consistent. **Wallet.** The buyer side. It holds funds, evaluates quotes against policy, signs authorizations and records spend. The AI Wallet variant adds the constraints an autonomous spender needs. **Dashboard, Marketplace, SDK.** Merchant control plane, discovery surface, and the client and server libraries that mean neither side implements the handshake by hand. ### 6.2 Payment lifecycle @diagram[lifecycle] Everything from `quoted` to `served` is synchronous and inside the request. `settled` is not, and the merchant has already delivered value by the time it is reached. Section 7 explains why that is an acceptable trade and what bounds the exposure. --- ## 7. Verification and settlement ### 7.1 The latency argument @diagram[latency] If the gateway waited for onchain confirmation before responding, every API call would inherit the latency of the underlying chain. A one second block time turns a 40 millisecond API into a one second API. For the agent workloads x402 exists to serve, where a single task may make hundreds of sequential calls, that is the difference between a viable product and an unusable one. ### 7.2 What the split actually risks Serving before settling is a credit decision, and it should be described as one. | Risk | Why it exists | Mitigation | Residual | | --- | --- | --- | --- | | Balance moves between verify and settle | Authorization is not a lock on funds | Balance check at verify, short `validBefore`, prefunding on high value routes | Small, non zero | | Chain reorganization | Settlement can be undone | Confirmation depth policy per network before payout release | Bounded by depth choice | | Submission failure | RPC or gas market failure | Durable queue, retry with backoff, dead letter and alerting | Operational, not financial | | Payer griefing | Repeated deliberate failures | Reputation, rate limiting, forced prefunding after repeat failures | Bounded per payer | The merchant carries **no chargeback risk**, because a cryptographic authorization has no consumer initiated reversal path. This is a structural improvement over card rails, not merely a cost saving. The risk that remains is credit risk on a two hundredth of a cent, which is a different category of problem from fraud on a fifty dollar card payment. :::note Where the risk sits X Pay absorbs settlement risk on behalf of merchants rather than passing it through. That is a deliberate product decision and a real cost line, and it is why prefunding exists as an option for high value routes. ::: --- ## 8. Products ### 8.1 X Pay Gateway Pricing rules per route, including fixed price per call, price per unit of work, and dynamic pricing resolved by the merchant at request time. Handles verification, replay protection, idempotency, receipt generation and webhooks. ### 8.2 Merchant Dashboard Publish and price endpoints, watch revenue and call volume in real time, inspect individual payments, manage payouts, and see who the heaviest consumers are. The operational quality bar here is set by the best payment tooling in the industry, and matching it is a product requirement rather than a nice to have. ### 8.3 AI Wallet A wallet designed on the assumption that the spender is software and will occasionally behave in ways nobody predicted. Detailed in section 10. ### 8.4 SDK Server side: one middleware call wraps a route. Client side: a drop in replacement for `fetch` that catches a 402, evaluates it against policy, pays and retries transparently. ```js import { paywall } from "@xpay/sdk"; app.use("/v1/summarize", paywall({ price: "$0.002", network: "base", payTo: process.env.XPAY_PAY_TO, })); ``` ```js import { XPayWallet } from "@xpay/sdk"; const wallet = new XPayWallet({ sessionKey: process.env.XPAY_SESSION_KEY, limits: { perCall: "$0.05", daily: "$25" }, }); const res = await wallet.fetch("https://api.acme.dev/v1/summarize", { method: "POST", body: JSON.stringify({ text }), }); ``` ### 8.5 API Marketplace A catalogue where each listing carries structured pricing an agent can parse. Because payment requires no onboarding, discovery and first purchase collapse into a single step: an agent can find an endpoint and pay it in the same second. ### 8.6 Billing models Pay per use is the default, but the gateway supports per request, per second, per token, per unit of compute, prepaid credits, volume tiers and conventional monthly plans. These are configuration, not separate integrations, and can be mixed per route. --- ## 9. Security model **Replay protection.** Every authorization carries a nonce claimed atomically at verification time. See section 5.4, step 8. This is the single most important invariant in the system. **Quote expiry.** Quotes are short lived, which bounds the window in which a payer balance can change between quote and settlement. **Scope binding.** An authorization is bound to amount, asset, network, recipient and nonce. It cannot be replayed against a different route, a different merchant or a larger amount. **Domain separation.** EIP-712 typed data includes the chain id and the token contract address in the signing domain. A signature produced for one chain or one asset cannot be replayed on another. **Key handling.** Session keys are scoped and expiring by construction. They are the only credential an agent process should ever hold, and compromise is bounded by the limits attached to the key rather than by the balance of the underlying wallet. **Custody.** Merchant balances and payout paths are the highest value target in the system. The intended posture is that X Pay minimizes the period it holds merchant funds, and that the settlement path is independently reviewed before it carries meaningful volume. ### 9.1 Threat model | Threat | Vector | Control | | --- | --- | --- | | Double spend | Same authorization presented concurrently | Atomic nonce claim in a strongly consistent store | | Cross chain replay | Signature reused on another network | Chain id and token address in the EIP-712 domain | | Cross merchant replay | Signature reused against another payee | `to` bound in the signed payload and checked | | Amount tampering | Client re-signs for less | `value` compared against the quote before acceptance | | Quote forgery | Client invents a favourable quote | Quotes are server issued and stored, not trusted from the client | | Gateway compromise | Attacker fronts merchant traffic | Scoped payout addresses, payout allowlists, alerting on address change | | Facilitator key loss | Relayer key exposed | Relayer holds gas only, never merchant funds; authorizations are already scoped | | Agent runaway | Buggy or injected agent loops | Pre signature ceilings, session key expiry, revocation | :::danger Not yet reviewed No component described in this document has been through third party security review at the time of writing. No claim of audit, formal verification or production hardening is made anywhere in this paper. ::: --- ## 10. Agent safety An autonomous spender is a new category of risk. A bug, a prompt injection or an unbounded retry loop can turn a well behaved agent into one that drains a balance in seconds. The wallet is where this is contained. @diagram[limits] **Per call ceiling.** A hard maximum for any single payment. Quotes above it are refused without being signed. **Daily and rolling ceilings.** A budget across a time window, enforced locally before signing. **Session keys.** Scoped, expiring keys that an agent process holds instead of the wallet's main key. Revocation is immediate and does not require moving funds. **Destination policy.** An optional allowlist or denylist, so an agent can only pay endpoints its operator has sanctioned. **Auto pay thresholds.** Below a configured amount the wallet pays without asking. Above it, the payment requires explicit approval. This is the dial between autonomy and control. **Complete history.** Every quote seen, every authorization signed and every receipt received, queryable. An agent's spending must be auditable after the fact, not merely limited in advance. :::tip The ordering principle Limits are enforced **before a signature exists**. Once an authorization is signed and released it is a commitment that the payer cannot retract, so every control has to sit earlier in the pipeline. A wallet that checks its budget after signing has no budget. ::: --- ## 11. Token The network settles in stablecoins. The token does not sit between a buyer and a seller, and no user is required to hold it in order to transact. Nobody needs $XPAY to pay. It is what an operator posts in order to run infrastructure inside the network. That distinction matters, because the usual token utilities do not survive scrutiny. A discount on a fee that is already 1% is not a reason to hold anything. Governance that does not actually control fee parameters, slashing conditions and the treasury is a checkbox. Both are named here and deliberately rejected rather than quietly included. @diagram[fees] **Facilitator bonding.** Running a facilitator means posting $XPAY as collateral against the capacity it serves. Double settlement, censorship of a valid authorization, or downtime against a published service level is slashed against that bond. This is the utility that matters most, because it makes the token functionally necessary for anyone who wants to operate rather than merely pleasant to hold. It is the same shape as validator collateral in a proof of stake network, applied to the one component that can actually misbehave with a merchant balance. **Marketplace ranking.** Sellers stake to rank in the API catalogue. Visibility is revenue, so the natural buyer of the token is a merchant with something to sell rather than a speculator. Ranking is a function of stake and of measured reliability together, so stake alone cannot buy a bad endpoint a good position. **Priority capacity.** Stake sets a rate ceiling and a position in the queue when the gateway is congested. This has no value while capacity is abundant, and real value the moment it is not, which is the honest way to describe it. **Arbitration bonding.** A cryptographic authorization has no consumer initiated reversal path, so there are no chargebacks. What remains is disputes over whether a paid endpoint delivered what it advertised. Those are settled against a posted bond, which makes a complaint cost something to file and gives an arbiter something to award. :::note What is deliberately not here Fee discounts and governance. A discount on a 1% fee is immaterial to the merchant and transparent to everyone else, and governance without real control over fees, slashing and treasury is theatre. Neither is load bearing, so neither is claimed. ::: ### 11.1 Supply and distribution Total supply is fixed at **1,000,000,000 XPAY**. There is no inflation schedule and no mint function beyond the initial supply. | | | | --- | --- | | Total supply | 1,000,000,000 XPAY | | Listing price | $0.0600 | | Fully diluted valuation at listing | $60,000,000 | | Total raise across all rounds | $4,700,000 | | Supply offered across all rounds | 14.75% | | Circulating at listing | 8.76%, being 87,600,000 tokens | | Initial market capitalisation | $5,256,000 | **Allocation.** | Allocation | Share | Tokens | TGE unlock | Cliff | Vesting | | --- | --- | --- | --- | --- | --- | | Reserve and treasury | 35.00% | 350,000,000 | 0% | 6 months | 36 months | | Liquidity | 13.25% | 132,500,000 | 50% | 1 month | at cliff | | Team | 10.00% | 100,000,000 | 0% | 12 months | 30 months | | Ecosystem and rewards | 10.00% | 100,000,000 | 0% | 3 months | 24 months | | Marketing and partnerships | 8.00% | 80,000,000 | 5% | 1 month | 18 months | | CEX and market making | 3.00% | 30,000,000 | 50% | none | 6 months | | Airdrop and community | 3.00% | 30,000,000 | 1% | none | 6 months | | Foundation | 3.00% | 30,000,000 | 0% | 12 months | 24 months | | Sale rounds, angel to KOLs | 14.75% | 147,500,000 | per round below | per round below | per round below | **Sale rounds.** Seven rounds, each priced above the one before it, and the listing priced above all of them. The listing prices at four times the angel round, so no round is underwater at launch. | Round | Share | Price | Tokens | Raise | Round FDV | TGE unlock | Cliff | Vesting | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | Angel | 1.00% | $0.015 | 10,000,000 | $150,000 | $15,000,000 | 0% | 1 month | 30 months | | Pre-seed | 2.50% | $0.020 | 25,000,000 | $500,000 | $20,000,000 | 0% | 2 months | 26 months | | Seed | 3.00% | $0.025 | 30,000,000 | $750,000 | $25,000,000 | 0% | 2 months | 22 months | | Strategic | 2.50% | $0.030 | 25,000,000 | $750,000 | $30,000,000 | 1% | 3 months | 18 months | | Private 1 | 2.25% | $0.040 | 22,500,000 | $900,000 | $40,000,000 | 2% | 3 months | 15 months | | Private 2 | 2.00% | $0.045 | 20,000,000 | $900,000 | $45,000,000 | 3% | 4 months | 12 months | | KOLs | 1.50% | $0.050 | 15,000,000 | $750,000 | $50,000,000 | 5% | none | 6 months | | **Total** | **14.75%** | | **147,500,000** | **$4,700,000** | | | | | **Unlock profile.** Summing every allocation month by month against its own TGE percentage, cliff and vesting term gives the circulating supply curve. It reaches 8.76% at listing, 42.1% at month 12, 73.1% at month 24, 92.2% at month 36, and is fully diluted at month 42. The design principle behind that shape is a single sentence: **no allocation unlocks in a way that lets insiders exit ahead of the people building volume on the network.** Angel, pre-seed and seed release nothing at listing. The team sits behind a twelve month cliff followed by thirty months of vesting, which is the longest schedule of any allocation and deliberately longer than every investor round. :::warn Subject to change Token design, allocation and schedule are indicative and require legal sign off in each jurisdiction of offer before they are final. Nothing in this section is an offer to sell, or a solicitation of an offer to buy, any token or security. ::: --- ## 12. Business model The core rate is a **1% fee on settled volume**. No monthly minimum, no setup fee, and nothing charged on calls that fail. Additional lines: - **Premium merchant plans.** Higher limits, priority settlement, advanced analytics and service levels. - **Marketplace commission.** A share of volume on endpoints discovered and sold through the catalogue. - **Enterprise integration.** Bespoke deployment, compliance support and dedicated infrastructure. - **White label gateway.** The full stack running under a partner brand. - **Cross chain routing.** A routing fee when a payment settles across networks or assets. The incentive alignment is deliberate: X Pay earns only when a merchant is paid. --- ## 13. Alternatives | Approach | Small payments | Machine buyer | No onboarding | Reversal risk | | --- | --- | --- | --- | --- | | Card subscription | No | No | No | Chargebacks | | Metered card billing | No | No | No | Chargebacks | | Prepaid vendor credits | Yes | Partly | No, per vendor | None | | Raw API keys | Yes | Yes | No | None, but unbounded spend | | Direct onchain transfer | Yes | Yes | Yes | None, but needs gas and confirmation wait | | **x402 with X Pay** | **Yes** | **Yes** | **Yes** | **None, credit risk only** | The closest alternative is a direct onchain transfer, and the differences are decisive: the payer needs no gas token, the response is not held for a confirmation, and the price is discoverable in band rather than agreed out of band. Within x402 itself a market has now formed, and it is worth being precise about who does what. Facilitators verify and settle, and charge either a flat amount per transaction or a small percentage. Card processors have added x402 as a payment method with fiat settlement at around 1.5%. Stablecoin issuers offer batched settlement aimed at high frequency, sub cent traffic. The large clouds and CDNs have shipped edge middleware that answers a 402 and stops there. Two things follow. First, a flat fee per transaction is structurally hostile to micropayments: a flat $0.001 is half of a $0.002 payment, and only a percentage rate works below ten cents. Second, none of the edge products price routes, reconcile revenue, issue an invoice for a VAT jurisdiction or pay a merchant out. A gate is not a business, and the gap between the two is what X Pay occupies. --- ## 14. Roadmap **Q3 2026.** Gateway in public beta. Node and Python SDKs. Merchant dashboard v1. Stablecoin settlement on a first EVM network. **Q4 2026.** AI Wallet with session keys and spending limits. Marketplace launch. Usage based and prepaid billing. Webhooks, receipts and exports. **Q1 2027.** Multichain settlement and routing. $XPAY utility and staking. Governance framework. Enterprise and white label tiers. **Q2 2027 and beyond.** Paywalls for sites, games and media. IoT, robotics and DePIN metering. Agent to agent settlement. Fiat on and off ramps. Dates are plans, not commitments. --- ## 15. Risks and open problems Stated plainly, because a whitepaper that lists only strengths is marketing. **Standard risk, now much reduced.** x402 is governed by the Linux Foundation with forty members, so fragmentation is far less likely than it was. What replaces it is a subtler risk: a standard backed by the card networks and the large clouds evolves on their timetable rather than ours, and a change we dislike is a change we implement anyway. The answer is unchanged. Implement faithfully, pin a version, and keep the gateway able to speak more than one dialect. **Concentration risk.** Most x402 traffic settles through a small number of facilitators today. That is a risk to the ecosystem and an opening for us: routing a payment across more than one facilitator, with automatic failover, is a position nobody currently occupies. It is also work we have not done yet. **Regulatory risk.** Payment facilitation, custody of merchant funds and token distribution are all regulated activities, and the treatment varies by jurisdiction. This is a gating dependency on launch sequencing, not a detail to resolve later. **Settlement risk.** Verifying before settling is what makes the product fast, and it is also where the residual credit risk lives. Section 7.2 lists the mitigations. None of them reduce the risk to zero. **Security risk.** The gateway and the settlement path have not been independently reviewed. No production claims should be made until they have been. **Consistency risk.** The nonce store is a single strongly consistent dependency on the hot path. It is also the obvious scaling bottleneck and the obvious availability risk, and there is no version of this system that removes it. **Chain dependency.** Latency, cost and reliability are inherited from the settlement network. Multichain support is a mitigation and also an increase in surface area. **Adoption risk.** A marketplace is a two sided market. Merchants list where buyers are, and buyers arrive where listings are. The plausible wedge is agent frameworks, where the pain of the current model is sharpest. **Agent risk.** Spending controls reduce the blast radius of a misbehaving agent. They do not eliminate it, and the failure modes of autonomous spenders are not yet well understood by anyone. --- ## 16. Glossary **Atomic units.** An integer amount in the token's smallest denomination. `2000` at six decimals is $0.002. **Authorization.** A signed message committing a payer to a specific transfer. Not a transaction. **EIP-712.** The Ethereum standard for signing structured data, so a signature is human inspectable and domain separated. **EIP-3009.** The token standard that allows a signed transfer to be submitted and paid for by a third party. **Facilitator.** The service that submits verified authorizations onchain and reports settlement. **Nonce.** A single use value binding an authorization to one specific payment. **Quote.** The server issued description of what payment satisfies a request. **Receipt.** The record of settlement returned with a paid response. **Scheme.** The payment method identifier inside x402. `exact` means the payer authorizes precisely the quoted amount. **Session key.** A scoped, expiring key an agent uses instead of the wallet's main key. --- ## 17. Conclusion The web never got a native payment primitive, so it built a human shaped substitute and lived with the consequences: no small payments, no machine buyers, and a monetization stack every developer rebuilds. x402 supplies the missing handshake. X Pay supplies everything around it that turns a handshake into a business: the gateway that enforces it, the wallet that makes autonomous spending safe, the dashboard that makes revenue legible, and the marketplace that makes an endpoint discoverable. If software is going to buy things, it needs a way to pay for them. That is the whole thesis. --- ## Legal notice This document is a draft published for discussion. It is not an offer to sell, or a solicitation of an offer to buy, any token, security or financial instrument, and it is not investment, financial, legal or tax advice. Statements about future products, timelines, token mechanics and network behaviour are forward looking and subject to change without notice. Nothing here is a commitment to deliver any feature on any date. No representation is made that the systems described have been audited, formally verified or hardened for production use. Digital assets carry risk, including total loss of value. Contract addresses, amounts and identifiers shown in examples are illustrative and truncated. Do not copy them into production code. © 2026 X Pay. All rights reserved.