Cra agent

Bringing x402 to AI agents on ARC

[Cra agent @Craagentarc]

CRA AGENT brings x402 to @arc: one tool call buys an API call for a fraction of a cent.
Price read, policy checked, USDC settled gas-free through @circle Gateway, receipt written.
Fully open source. MCP-native.

CA: 0x70857041fef0ced97f9e01e7ccc21889afe3f6f4

[Cra agent @Craagentarc]

This morning we had 6 APIs to sell, now we're at 21.

In the last 8 hours we've settled 200+ payments from 60+ wallets.

Agents can pay for a multitude of services, from:
• Arc wallets, tokens, transactions
• Any web page as clean text
• npm and PyPI with their CVEs
• DNS, whois, FX rates, Wikipedia.
• So much more coming soon

You're not paying for the data. You're paying to never sign up for anything again.

Every one of those payments, with its transaction: https://t.co/eJIL68Cwqu

[Cra agent @Craagentarc]

You can now buy a piece of live data about Arc from your browser wallet. Connect, sign once, it arrives.

https://t.co/70ywTldDKL

What's for sale, a third of a cent each: the euro to dollar rate on Arc taken from real trades, what a transaction costs right now, which contracts just got deployed, which public access points are fast and which drop calls.

No deposit, no gas, no signup. You sign for that amount, to that address, valid two minutes. Some wallets label it a "token approval": check it says 0.0030, not unlimited.

There's also one that fails on purpose. Sign it, watch it break, check your balance: nothing moved. You only pay if you get the data.

Behind it is our own x402 facilitator on Arc, open source. It checks the signature, runs the request, and only then submits the transfer and pays the gas. First settlement:
0x903a75fb579f4f6eb6b7ffb90ff3f7de405f117e9aed78d1f21c23a0f1fa0250

Every payment is now listed in public, with its result and its hash.

https://t.co/eJIL68D4g2

more updates incoming.
For now it settles payments to us and refuses everything else. If you build on Arc and want it to settle for you, tell us. We'd rather open it because someone asked.

[Cra agent @Craagentarc]

Almost 3k$ already sent to our holders , 1.75% supply bought back and burnt and also over 4k usdc injected to the LP .

A Big update incoming in a few hours .

$CRA

[Cra agent @Craagentarc]

Agreed, and that's why we keep them as separate states instead of one "error".

rejected: the policy said no, nothing was signed.
not_charged: the payment was valid, the handler failed, the authorization went unused.
failed: the handler was fine, settlement wasn't.

Three different problems with three different owners. Folding them into one error code is how you end up retrying a payment that was never the thing that broke.

[Cra agent @Craagentarc]

CRA AGENT is in the official MCP registry.

io.github.giupy997/cra-agent

What it gives an agent: one tool call to pay for an x402 API in USDC on Arc. The rail reads the price, checks the spending limits, pays with no gas on the buyer's side, and keeps the receipt with the settlement hash.

What it keeps away from the model: the key and the limits. Both are read from the environment before the conversation starts, so no prompt talks its way into a bigger budget.

npm i -g @cra-agent/mcp

$CRA

[Cra agent @Craagentarc]

Yes, exactly. A signed authorization is a promise, not a payment. Nothing moves until the facilitator verifies it and settles.

That gap is a feature. It's why a failing endpoint costs nothing: the handler runs between verify and settle, so if it throws, the authorization is simply never used. Our ledger records that row as signed but not charged.

It's also the risk. Until it's settled or it expires, a signed authorization is open exposure: the seller could still present it. With Gateway's batching the validity window is about a week, so we track those rows as exposure per counterparty rather than pretending they're gone.

[Cra agent @Craagentarc]

Close, with one distinction worth making: there are two signatures and they do different jobs.

What locks the payment is the authorization the rail signs to pay: amount, recipient and expiry are inside it, so the facilitator can't settle anything else. That's the one the chain cares about.

The signature on the receipt comes after. It doesn't move money, it's a statement: this is what was bought, under these limits, with this much already spent. Tamper-evident, checkable offline, but it's the rail describing its own decision.

So custody controls access, the authorization fixes the terms, and the receipt is the record. If you ever want to break it, it's one npm install and I'd genuinely like to hear what fails.

[Cra agent @Craagentarc]

Our rail stopped twice last week without crashing. Nothing died, so nothing restarted it, and we found out hours later by looking.

So now it pays itself. Every hour our server buys our own cheapest endpoint for $0.0005, checks the signature on its own receipt, then calls the endpoint that is supposed to fail and confirms it wasn't charged.

The result is on the home page, labelled for what it is: our own wallet, not a customer. If it stops, the tile goes stale where everyone can see it.

The key that does it runs under a policy of half a cent a day, to one host. Stealing it gets you half a cent a day.

First run: settled in 1.06 s, receipt signature valid, broken endpoint not charged.

https://t.co/sDxJj1WRL3 · https://t.co/rk0RHoOqxm

[Cra agent @Craagentarc]

You're right, it is a separate tracking system. Nothing on chain enforces the policy.

What ties it to the wallet is custody: the rail is the only thing that holds the key, so no payment can be signed without going through it, and it writes the ledger row before it signs. If the key exists anywhere else, the ledger means nothing. That's the assumption, stated plainly.

The hard ceiling is a different layer. The agent doesn't spend from the wallet, it spends from a balance deposited into Circle Gateway. You deposit what you're willing to lose. Ours holds half a dollar. The policy decides how fast that can go, the deposit decides how much can ever go.

And the two are reconciled after the fact: each settled row gets matched to its on-chain transfer, so a ledger that drifts from reality shows up.

[Cra agent @Craagentarc]

the reason is the limit doesn't live in the model at all.The limit belongs to the wallet, not to whoever is asking.
The rail is a separate process holding the key.
Every payment is counted in a ledger against that key: per payment, per seller, per rolling 24 hours.
Swap the model mid-conversation, run three different ones, it makes no difference.
They all ask the same rail, and the rail answers from the same ledger.

So the model can change on every call. What it can't do is see the key, or spend past what the ledger says is left.

[Cra agent @Craagentarc]

Fair question, but there's no model here, so no training data or eval protocol to publish. The MCP registry lists tool servers, not models. This is a server any MCP client can call so its agent can pay for an x402 API under a spending limit. The model is whatever you already run.

The entry carries what that registry asks for: the npm package and version, stdio transport, and the five environment variables it reads.

The closest thing to an eval protocol for a payment rail is tests and receipts: 105 tests, open source, and mainnet payments anyone can look up. https://t.co/9AexLEoHPL

[Cra agent @Craagentarc]

Receipts are now signed, and they say which limits a payment passed under, not only the one that would have blocked it.

Check one offline: cra-agent verify receipt.json. I changed one figure in a real mainnet receipt and it was rejected.

It proves the agent issued it and nobody altered it. The settlement on chain is the independent half.

npm i -g @cra-agent/mcp

[Cra agent @Craagentarc]

Fair points, and we're building both now.

Already in the receipt: resource, quoted price, payer, settlement hash, status, and the rule that refused a payment when one is refused. The key never reaches the chat, by design.

What's missing and going in: the limits a payment passed under and the budget left at that moment, not only the rule that blocked it. And a signature, so the receipt stops being a ledger row the agent can show and becomes something a third party can check.

[Cra agent @Craagentarc]

It holds the response until settlement. The order is verify, run the handler, settle, then respond. The handler's output is buffered while settle runs: if settlement fails the buyer gets an error and no data, and if the handler throws nothing is settled.

One caveat on my numbers: 713 ms and 2.7 s were the two facilitator calls measured on their own, no API in between. A real request pays both plus the handler, so about 3.4 s through that path.

You could answer on verify and settle in the background, but then the seller has delivered before being paid. For sub-cent calls I'd rather be slow than unpaid.

[Cra agent @Craagentarc]

Two fresh addresses, funded with 1 USDC each on Arc. Each one deposited into Circle Gateway, about $0.003 of gas, once. Then each bought an endpoint:

0x4F8C…49A3 → /v1/paid/fees/forecast, $0.001, 200 in 3.4s
0x8f58…7ad3 → /v1/paid/deploys/history, $0.002, 200 in 1.2s

Two different buyers, one settlement transaction:
0x340cfbac3829f75c265da4822501be84c56a7f282536bb5cf1133e68a3a8ee0c

Gas paid by the facilitator, $0.0013 per payment. The answer came back at once, the batch landed on chain eight minutes later.

It also found a bug. The first deposit died on a dropped RPC connection. Fixed the same day, and the fix had to be fixed again after review. Both are in the repo.

[Cra agent @Craagentarc]

Already integrating. x402 on Arc is where agent commerce actually starts.

[Circle @circle]

Agentic payments are live on Arc.

Our Facilitator Service gives x402 builders a hosted way to accept Circle-issued USDC on Arc, Base, and Polygon without running their own relayer or funding separate gas wallets.

You build the service. Agents pay for it.

https://t.co/vKU6AShrj6

[Cra agent @Craagentarc]

Proof it still works, three days in.

Two payments on Arc mainnet just now, from our own agent. Mine, not a customer's: same payer address as day one, so you can check it.

$0.0005 → /v1/paid/rpc/health, 200 in 1.98s
$0.001 → /v1/paid/fx/execution, 200 in 5.60s

Both settled in the same transaction:
0xa6fc188758ea1b72a78f242381b80bcef443c6be9c7e63972c617176afae133c

That is the batch doing its job. Two days ago one payment sat alone in a settlement that burned $0.0255 of gas. This one carried two for $0.0018 total, $0.0009 each. Twenty-eight times cheaper, partly the batch, partly a base fee back at the floor.