138M x402 payments on Base. Cap your agent before you fund it

Chainalysis published its 2026 Geography of Cryptocurrency Report this week, and one figure in the North America chapter changes how you should deploy an agent that holds money: the median wallet now makes its first x402 payment 18 minutes after being funded. In late 2025 that same number was 73 days (report, reported by Blockhead on 15 October 2026).

The number that matters

The full picture:

• More than 138 million payments have gone through Coinbase's x402 protocol on Base.
• More than 87% of them were worth between $0.0001 and $0.10.
• The median wallet made its first payment 18 minutes after funding, down from 73 days in late 2025.
• The share of wallets that spent within an hour of funding rose from 4% to 67%.

x402 revives the HTTP 402 "Payment Required" status code so an API can ask for a stablecoin payment before it serves a request. An agent pays for a model call or a dataset without a human entering card details. The 18 minute figure is the deployment pattern flipping: wallets are now spun up, funded and put to work in the same sitting.

What breaks

The old habit was to fund a wallet, watch it for a few days, then tighten the controls. That review window is gone. If an agent is going to overspend, misuse its key or send to the wrong address, it will do it in the first hour, not the first quarter. "Check it later" now means "check it after it already spent."

This is not a reason to keep agents offline. It is a reason to put the guardrail in the same step as the funding. The cap has to exist before the money lands, because the first spend comes almost immediately after.

The two calls that matter

On OpenClawCash the policy check runs server side before anything is signed: daily, weekly and monthly spending limits and address allowlists are evaluated first, and a denied request never reaches the chain (openclawcash.com/docs). The agent authenticates with an X-Agent-Key API key, never a private key, so a leaked environment is a revocable key rather than a drained wallet.

Before you fund, read every wallet the key can reach and confirm the limit is in place:

curl "https://openclawcash.com/api/agent/policies" \
  -H "X-Agent-Key: occ_your_api_key"

The response comes back hydrated with current usage, so spent and limit arrive together:

[
  {
    "wallet": { "id": "Q7X2K9P", "label": "Trading Bot" },
    "policies": [
      {
        "id": 31,
        "type": "daily_spending_limit",
        "config": { "amount": "100" },
        "usage": { "spent": "45.00", "limit": "100.00", "symbol": "USD", "window": "24h" }
      }
    ]
  }
]

After you fund, watch the first hour. GET /api/agent/transactions returns the merged on-chain and app-recorded rows, scoped to Base with network=base-mainnet:

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

A transfer that would cross the limit is denied before it reaches the chain, so the log you read back is bounded by the cap, not by the wallet balance.

The practical rule

Set the daily limit the same day you create the wallet, before you fund it. Then read the policy before the first send, and read the transaction log after the first hour. The 73 day review window is gone. The cap has to arrive first, because the first payment will be 18 minutes behind it.

Where this is still rough

The public API reads policies and their usage. It does not create or change them: limits are set on the wallet in the dashboard. An agent cannot raise its own ceiling, which is the point, but that step is manual today. Both calls above, and the rest of the agent surface, are documented at openclawcash.com/docs.