An agent buying on its own

Every page before this one describes a piece of the Router. This one runs the whole thing, start to finish, and shows the actual output — so you can see what an autonomous agent’s spending really looks like before you give one a budget. The question it answers:

Can you hand an agent an API key and a cap, and have it find services, pay for them, and be stopped — with no per-provider accounts, no protocol knowledge, and no keys of its own?

The run below is real. Every number, hash and error on this page came from one execution against live merchants on Base mainnet and Tempo mainnet. Total cost: $0.08.

The refusal is the interesting part. Anyone can demo a purchase. What makes an agent safe to leave running is a spend control that says no — and keeps saying no — without you being there. That’s step 6, and it’s the reason this page exists.

What the agent is given

Two things. That’s the whole grant:


An API key	Authenticates it to Nevermined. Never sent to any merchant. Must be for a live deployment — see below.
A Delegation	A hard cap in cents, plus an expiry. Here: 9¢, valid one hour.

It is not given: a wallet, a private key, a merchant account, an API key for any service it buys from, or any knowledge of which payment protocol a service speaks.

This run requires a live deployment. Every service below settles on mainnet — Base 8453 and Tempo 4217 — and a sandbox deployment funds testnets only. That split is the real-money firewall and an operator cannot widen it, so pointing $NVM_API_URL at api.sandbox.nevermined.app makes step 3 fail with 400 BCK.ROUTER.0001: no accepts entry survives the network filter.Watch for that code specifically. It is not the refusal in step 6 — that one is a 402 BCK.ROUTER.0003 and means the guardrail worked. A 400 here means the wrong deployment. See the x402 rail for the firewall itself.

1. Discover

The catalog is public. No key, no account, no signup:

curl -s "$NVM_API_URL/api/v1/catalog/services?search=crypto&limit=20"

search 'crypto' → 14 services, e.g.
  · Kraken Crypto Signals  [x402]  $0.01
  · 2s                     [x402]  $0.001–$0.144 per call (USDC)
  · CoinGecko via MPP      [mpp]   $0.06
  · Laevitas x402          [x402]  $0.001

142 services, listing their protocol, network and price up front. Each entry carries everything needed to place a call — targetUrl, the endpoint path and method, and a priceLabel:

curl -s "$NVM_API_URL/api/v1/catalog/services/coingecko-via-mpp"

{
  "slug": "coingecko-via-mpp",
  "title": "CoinGecko via MPP",
  "protocol": "mpp",
  "network": "Tempo",
  "targetUrl": "https://coingecko.mpp.paywithlocus.com",
  "priceLabel": "$0.06",
  "endpoints": [
    { "path": "/coingecko/simple-price", "method": "POST", "priceLabel": "$0.06" }
  ]
}

?search= matches titles, descriptions and categories — not slugs. To fetch one known service, use the by-slug route above. limit is capped server-side at 20, so paginating the whole catalog client-side isn’t the answer either.

The agent picked two services with deliberately different plumbing:

Service	Protocol	Chain	Price
CoinGecko via MPP	`mpp`	Tempo mainnet (4217)	$0.06
AgentOracle	`x402`	Base mainnet (8453)	$0.01

2. Set the budget

The cap is chosen so the third purchase cannot fit:

cap = 6¢ (CoinGecko) + 1¢ (AgentOracle) + 2¢ slack = 9¢

curl -sX POST "$NVM_API_URL/api/v1/delegation/create" \
  -H "Authorization: Bearer $NVM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"provider":"erc4337","currency":"usdc","spendingLimitCents":9,"durationSecs":3600}'

The 2¢ of slack matters. A merchant’s real charge can exceed its advertised price, because the Router converts the on-wire amount to cents and rounds up: CoinGecko’s $0.06 arrives as 60001 atomic units and costs 7¢, not 6¢. The slack absorbs that while staying far below the ~7¢ a third call needs — so the refusal in step 6 is arithmetic, not luck.

3. Buy over MPP

The agent sends a URL and a delegation id. Nothing else:

curl -sX POST "$NVM_API_URL/api/v1/router/route" \
  -H "Authorization: Bearer $NVM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "delegationId": "'"$NVM_DELEGATION_ID"'",
    "url": "https://coingecko.mpp.paywithlocus.com/coingecko/simple-price",
    "method": "POST",
    "body": { "ids": "bitcoin", "vs_currencies": "usd" },
    "requestId": "demo-mpp-1"
  }'

{
  "status": 200,
  "paid": true,
  "body": { "success": true, "data": { "bitcoin": { "usd": 64794 } } },
  "payment": {
    "status": "Settled",
    "txHash": "0xd25f25cc162f347e2e0374841a1270b61f7dff53d5c6af0fbcacdab2caaf5bb8",
    "settlement": {
      "scheme": "charge",
      "network": "tempo",
      "asset": "0x20c000000000000000000000b9537d11c60e8b50",
      "approxCents": "7"
    }
  }
}

One call in, the data and a settled on-chain payment out. Budget left: 2¢ of 9¢.

4. Buy over x402

Now the same call shape against a service on a different protocol and a different chain:

curl -sX POST "$NVM_API_URL/api/v1/router/route" \
  -H "Authorization: Bearer $NVM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "delegationId": "'"$NVM_DELEGATION_ID"'",
    "url": "https://aiagentoracle.ai/api/v1/tokens",
    "method": "GET",
    "requestId": "demo-x402-1"
  }'

{
  "status": 200,
  "paid": true,
  "body": { "tokens": [ { "symbol": "BTC", "priceUsd": 64798 } ] },
  "payment": {
    "status": "Settled",
    "txHash": "0x44136dc5348e5442770ad1ebeb9cb4e641225f8d4abdcf9e4b2f82f33a054214",
    "settlement": {
      "scheme": "exact",
      "network": "eip155:8453",
      "asset": "USDC",
      "approxCents": "1"
    }
  }
}

This is the part worth pausing on. Steps 3 and 4 are the same request, to the same endpoint, differing only in the URL. The agent never named a protocol. The Router fetched each merchant, read WWW-Authenticate: Payment on one and PAYMENT-REQUIRED on the other, and chose the rail itself — signing an EIP-3009 authorization on Base for one and a native Tempo charge for the other. The agent does not know, and does not need to know, which chain it just paid on.

Because the Router picks the protocol in this mode, a merchant advertising both rails will be paid over MPP. If you’re specifically verifying x402 behaviour, pin a merchant that offers only x402 — otherwise a green run can be exercising the other rail entirely. Check with curl -sD - -o /dev/null "$URL" | grep -ci '^www-authenticate: *Payment' — it must be 0.

5. Report

One ledger, regardless of protocol or chain:

curl -s "$NVM_API_URL/api/v1/router/payments?delegationId=$NVM_DELEGATION_ID" \
  -H "Authorization: Bearer $NVM_API_KEY"

Protocol	Network	Asset	Amount	Status	Tx
`x402`	`eip155:8453`	`USDC`	10000	Settled	`0x44136dc5…`
`mpp`	`tempo`	`0x20c0…8b50`	60001	Settled	`0xd25f25cc…`

Both reconcile exactly against the chains: Base −0.010000 USDC, Tempo −0.060029 USDC.e (the 0.060001 payment plus 28 units of gas, which Tempo bills in the stablecoin itself).

On the MPP rail, network comes back as a bare name — "tempo" — with no chain id, so it does not distinguish Tempo mainnet (4217) from the Moderato testnet (42431). That makes the asset address the only field that tells you which chain a payment actually settled on. The two token addresses, and why they are easy to misread, are in the MPP rail.

Add &format=csv for a downloadable file. This is the same record whether you spent over one protocol or five.

6. Refused

The agent tries the CoinGecko call once more. It has 1¢ left; the call costs 7¢:

{
  "code": "BCK.ROUTER.0003",
  "message": "Delegation budget exceeded, expired, or inactive"
}

402. No payment minted, no credential issued, nothing to unwind — the ledger still holds exactly two payments. The cap is enforced server-side inside the same transaction that records the spend, so an agent cannot get past it by retrying, looping, or being confidently wrong about its own remaining budget. That is the property that makes an autonomous agent something you can leave running: the ceiling is not enforced by the agent’s good behaviour.

0003 covers exhausted, expired and revoked. Read remainingBudgetCents and expiresAt from GET /api/v1/delegation/{id} to tell them apart — a long-running agent that worked yesterday has very often just aged out rather than overspent. See Guardrails.

What this demonstrates

Discovery needs no account. The catalog is public and machine-readable, and carries enough to place a call.
One integration, many protocols. The agent wrote no protocol-specific code. Adding a rail is the Router’s problem, not the agent’s.
The agent holds nothing. No wallet, no private key, no merchant credentials. Funds sit in a custodial wallet it cannot reach except through a capped Delegation.
Spending is bounded by construction. The cap is checked server-side on every payment, and refusing costs nothing.
Everything is auditable. One ledger across every rail, with on-chain hashes that reconcile.

Reproducing it

The six curl calls above are the whole run. There is nothing else to install — a live API key, a Delegation, a funded wallet, and the requests on this page reproduce it end to end in any shell or language.

This spends real money. There is no testnet variant, and that is structural rather than an oversight: the catalog lists mainnet merchants, so a testnet run would have nothing real to discover. Sanity-check the price on each catalog entry before you buy — a legitimate service can charge over a dollar a call — and keep the Delegation cap tight enough that a mistake is refused rather than paid.

Before a first run, check the things that most often turn into a “Router bug” that was nothing of the sort:

Read the wallet address back from the live Delegation (providerPaymentMethodId), never from anything you wrote down — funding a stale address fails as 402 BCK.ROUTER.0009, which deliberately does not name the address it checked.
Fund it on both chains you intend to pay on. Base and Tempo are separate balances.
Confirm the merchant still answers 402 on the rail you expect. A service that stops charging is relayed with paid: false, and a run can otherwise “succeed” having bought nothing.
Check the catalog is loaded, not serving placeholder rows — compare total and look at the targetUrls.

Nevermined staff: a scripted version of exactly this run — the six steps plus a preflight covering every point above — lives in the internal nvm-monorepo repository at .claude/skills/nvm-router-demo/. It adds --dry-run (spends nothing) and --selfcheck (offline). It is not public, and nothing on this page depends on it.

Guardrails

Every check the Router makes before it signs, and every error code it can return.

Ledger

The unified payment record, its fields, and CSV export.

Learn

Build

Payments

Nevermined Router

Solutions

Organizations

Integrations

Payment Patterns

Components

Specs

What the agent is given

1. Discover

2. Set the budget

3. Buy over MPP

4. Buy over x402

5. Report

6. Refused

What this demonstrates

Reproducing it

Next

Guardrails

Ledger

​What the agent is given

​1. Discover

​2. Set the budget

​3. Buy over MPP

​4. Buy over x402

​5. Report

​6. Refused

​What this demonstrates

​Reproducing it

​Next

Guardrails

Ledger

What the agent is given

1. Discover

2. Set the budget

3. Buy over MPP

4. Buy over x402

5. Report

6. Refused

What this demonstrates

Reproducing it

Next