13.9M x402 payments on XRPL: how to cap what your agent can spend

The XRP Ledger passed 13 million x402 agent payments in the second week of October 2026. RippleX engineering head J. Ayo Akinyele reported the milestone on 10 October: more than 13 million transactions across 166 registered x402 merchants (crypto.news, 10 October 2026).

The same index that counts those payments also counts what settled. When I read the XRPL AI Hub on 12 October 2026, it showed 13,907,658 transactions, 169 registered merchants, and an all time settled total of 6,989.40 XRP and 12,390.66 RLUSD (xrpl-ai.org).

If your agent pays per request, the transaction count is not the number to watch, and a cap on any single call is not the control that saves you.

What x402 actually does

x402 extends the HTTP 402 Payment Required status code into a full payment flow, and the XRP Ledger documentation spells out the exchange (xrpl.org):

1. The agent requests a resource.
2. The merchant answers 402 with the price, the payment address and a facilitator URL in a structured header.
3. The agent submits a presigned payment transaction for the required amount.
4. The agent sends the transaction hash to the facilitator, which verifies the on-chain payment and issues a signed receipt.
5. The agent retries the original request with the receipt in the X-PAYMENT header.
6. The merchant verifies the receipt and returns the resource.

No account, no invoice, no key rotation. On the XRP Ledger the payment is an ordinary Payment transaction carrying a memo, and the same documentation points at SourceTag and memos as the way to attribute and audit what an agent paid for. Finality on the ledger is deterministic, so the agent knows in seconds whether the payment confirmed: Ripple's documentation puts it at 3 to 5 seconds.

That is a good shape for machine payments, and one that hides spending.

What the count does not measure

13.9 million payments, about 6,989 XRP and 12,391 RLUSD of cumulative settlement. The live feed on that dashboard listed single settlements of 0.0005, 0.000694 and 0.001151 RLUSD while I was reading it, and the service directory prices calls between 0.002 and 0.006 RLUSD.

At that size the failure mode is not one expensive transfer. It is ten thousand cheap ones.

A per transaction cap is the wrong instrument for it. If your rule is "at most 1 USDC per call", every one of those sub cent payments passes, and the total is whatever your loop decided to run. Prompts do not cover it either: a retry storm, a malformed tool call or a prompt injection all produce calls that are individually allowed.

The XRPL numbers tell the same story with a bigger sample. In July 2026 the same index counted about 1.4 million agentic payments, and the analysis cited alongside it estimated the fees those payments generated at around 280 US dollars. The transaction count grew roughly tenfold in three months. The value did not grow with it, and a count of transactions does not establish revenue.

What catches that class of spending is a rolling budget: a daily, weekly or monthly ceiling the agent's own code cannot widen, plus an allowlist for destinations. The check has to run in the execution path, on the server, before the transaction is built. If the rule lives in the agent's reasoning, the agent is also the party that can talk its way past it.

The two calls that matter

On OpenClawCash the policy check runs server side before anything is signed: spending limits, address restrictions and approvals are evaluated first, and a denied request never reaches the chain (openclawcash.com/docs, openclawcash.com/agents). Both calls below use the X-Agent-Key header, with the key you generated for that agent.

First, read back what your agent actually paid. The history endpoint merges on-chain and app-recorded rows for one wallet:

curl "https://openclawcash.com/api/agent/transactions?walletId=YUZE66Z&chain=solana" \
  -H "X-Agent-Key: occ_your_api_key"

[
  {
    "id": 0,
    "walletId": "YUZE66Z",
    "hash": "5tS4...sig",
    "to": "GmjrX8...",
    "value": "1000000000",
    "fee": "5000",
    "platformFee": "0",
    "feePercent": "0%",
    "type": "transfer",
    "status": "confirmed",
    "data": "{\"source\":\"on-chain\",\"direction\":\"incoming\",\"token\":\"SOL\"}",
    "createdAt": "2026-02-19T17:15:00.000Z"
  }
]

Second, read the budget that governs it. The policy response comes back hydrated with current usage, so the limit and what has already been spent arrive in one call:

curl "https://openclawcash.com/api/agent/policy?walletId=Q7X2K9P" \
  -H "X-Agent-Key: occ_your_api_key"

{
  "wallet": {
    "id": "Q7X2K9P",
    "label": "Trading Bot",
    "address": "0x14ae8d93...",
    "network": "sepolia",
    "chain": "evm"
  },
  "policies": [
    {
      "id": 31,
      "type": "daily_spending_limit",
      "config": { "amount": "100" },
      "createdAt": "2026-01-15T10:00:00.000Z",
      "usage": {
        "spent": "45.00",
        "limit": "100.00",
        "symbol": "USD",
        "decimals": 2,
        "window": "24h"
      }
    }
  ]
}

Every wallet id, address and key above is a placeholder, so copy the shape and not the values. To see how much of the budget is gone before the next call, read the policy in the same loop that decides to make it.

The honest limit

OpenClawCash settles on Ethereum, Polygon, Base and Solana. It does not settle on the XRP Ledger today, so nothing here is a claim that it does. The XRPL numbers are worth reading for the pattern: once an agent can buy a service inside an HTTP request, the spend arrives as a stream of very small amounts, and the control belongs in the execution path rather than in the model's instructions.

If you are running an agent that already pays per request, the two calls above are the whole setup: read the log, read the budget.