LIVE
ANTHROPICOpus 4.7 benchmarks published2m ago
CLAUDEOK142ms
OPUS 4.7$15 / $75per Mtok
CHATGPTOK89ms
HACKERNEWSWhy has not AI improved design quality the way it improved dev speed?14m ago
MMLU-PROleader Opus 4.788.4
GEMINIDEGRADED312ms
MISTRALMistral Medium 3 released6m ago
GPT-4o$5 / $15per Mtok
ARXIVCompositional reasoning in LRMs22m ago
BEDROCKOK178ms
GEMINI 2.5$3.50 / $10.50per Mtok
THE VERGEFrontier Model Forum expansion announced38m ago
SWE-BENCHleader Claude Opus 4.772.1%
MISTRALOK104ms
ANTHROPICOpus 4.7 benchmarks published2m ago
CLAUDEOK142ms
OPUS 4.7$15 / $75per Mtok
CHATGPTOK89ms
HACKERNEWSWhy has not AI improved design quality the way it improved dev speed?14m ago
MMLU-PROleader Opus 4.788.4
GEMINIDEGRADED312ms
MISTRALMistral Medium 3 released6m ago
GPT-4o$5 / $15per Mtok
ARXIVCompositional reasoning in LRMs22m ago
BEDROCKOK178ms
GEMINI 2.5$3.50 / $10.50per Mtok
THE VERGEFrontier Model Forum expansion announced38m ago
SWE-BENCHleader Claude Opus 4.772.1%
MISTRALOK104ms
Back to Originals

We Validated Agent Payments End-to-End on Base Mainnet

Ripper··6 min read

This morning I sent one USDC from a wallet on my laptop to a wallet I had published in four places, called a Python function, got back a token, asked a paid AI routing endpoint a question, and watched my balance tick down by exactly one credit. The whole thing took under two minutes. Every step worked first try.

That sentence is the difference between TensorFeed agent payments being a design and being a system. Until today, the architecture existed, the code was deployed, and the tests passed. But nothing had moved real money on chain. There is a particular kind of nervous you only feel the moment before you click confirm on an irreversible transaction to your own self-custodied wallet using software you wrote yourself.

I want to walk through what actually happened, because the parts that worked and the parts I braced for both teach you something about building payment-native APIs for AI agents.

The five-step loop

The flow we shipped is simple by design. An agent buys credits once, gets a bearer token, and uses that token on premium API calls. Each call decrements credits. When credits run out, the agent buys more. No accounts, no API keys, no Stripe, no chargebacks. Just USDC on Base mainnet and a token.

Here is what I ran, end to end, from a Python REPL with the freshly publishedtensorfeed SDK installed via pip:

Step 1. Quote

I called tf.buy_credits(amount_usd=1.00)and got back a quote: a wallet address, a memo nonce (tf-eb13b1a17c6811d6), 50 credits at base rate, and a 30 minute expiry. The memo lets the worker tie a specific on-chain transaction back to a specific quote so volume discounts apply correctly.

Step 2. Send USDC on Base

I opened Rabby, switched to Base, sent one USDC to the quoted wallet. The transaction landed on chain in a few seconds. The hash:0x13bc9e2378edae44685a63bdedd3ba802372e2e656961610b8c169ca60431c0e. Anyone can verify this on Basescan right now. That permanence is the whole point.

Step 3. Confirm

Back in Python, tf.confirm(tx_hash=…, nonce=…). The worker fetched the transaction receipt from a Base RPC, parsed the USDC Transfer event log, verified the recipient was our wallet, and verified the amount matched the quoted USD value. It then minted a bearer token (tf_live_eb0d0155…) and recorded the tx hash permanently for replay protection. The whole verification took maybe 200 milliseconds.

Step 4. Spend a credit

With a token in hand, I called tf.routing(task="code", top_n=3). The worker checked the bearer token, decremented the balance by one, ran the routing engine over live pricing and benchmarks and status data, and returned three ranked recommendations. The top three:

  • Mistral Large, composite score 0.83
  • OpenAI o3-mini, composite score 0.82
  • Claude Sonnet 4.6, composite score 0.81

Each recommendation came back with the full breakdown: quality from benchmarks, availability from live status, normalized cost across the candidate set, latency placeholder. An AI agent building a routing layer on top of this gets a complete decision in one paid call instead of stitching four free endpoints together.

Step 5. Verify the balance

One more call: tf.balance(). The response: 49 credits remaining. One credit charged, 49 left, total purchased 50. Math checks out. System works.

What I expected to fail

Honestly? Probably half of it. Building a payment system from scratch, even a simple one, has a lot of edges. Here is what I had braced for:

RPC flakiness. Base mainnet RPCs sometimes return stale data, sometimes time out under load. The verify step querieseth_getTransactionReceipt from a public RPC endpoint. I expected at least one retry. None needed. The call returned a fully formed receipt with the correct logs the first time.

Wei conversion bugs. USDC on Base is six decimal places, not eighteen like ETH. We treat the on-chain value as a BigInt and divide by ten to the sixth. Any off-by-one in that math and a one dollar payment becomes 0.000001 credits or 1,000,000 credits. I had unit tests, but the production path uses real numbers in a real receipt, not a mock. It worked exactly. Fifty credits minted, as quoted.

Replay protection. Once a tx hash is used to mint credits, we permanently record it under thepay:tx: KV prefix. If someone tries to replay the same hash, we reject. I considered testing that path with a deliberate replay, but the design feels right and the test suite covers it. Save it for a follow-up.

Token format. The bearer token is atf_live_ prefix plus 256 bits of random hex. The format is parseable, scannable in logs without leaking secrets via the prefix, and obviously different from any major LLM API key prefix. I worried briefly that the auth header would not survive HTTP round-tripping. It did. No surprises.

Why this matters

Less than one percent of APIs on the internet are machine-payable today. Almost every paid API still requires a human to fill out a signup form, attach a credit card, generate an API key, and copy it into a config file. That works fine when the consumer is a human. It does not work when the consumer is an AI agent making decisions in a loop at three in the morning.

The whole point of agent-native infrastructure is to remove the human from the credential loop. An agent should be able to discover a paid API, evaluate whether it needs to spend money, send the payment, and use the result. All in the same execution context, with no human approval step. That is what x402 was designed to enable, and that is what TensorFeed agent payments delivers today.

I did the test loop manually because I needed to feel each step. But everything I did from Python could be done by an autonomous agent. There is nothing about the flow that requires a human in any step. That is the entire bet.

What is live as of today

Thirteen paid premium endpoints across the API surface. A free preview tier on the routing engine for discovery. Daily snapshots of pricing, models, benchmarks, status, and agent activity that compound into a moat we cannot recreate after the fact. Webhook watches that fire on price changes and service status transitions, signed with HMAC. An enriched agents directory with a derived trending score. A human-facing dashboard at/accountfor people who want to see their balance without writing curl. SDKs for Python and TypeScript, and an MCP server that exposes every premium tool to Claude Desktop and Claude Code.

And one verified transaction on Base mainnet that proves all of it works.

If you want to try it yourself, theagent payments docshave the wallet address (cross-checked against four published locations), pricing tiers, payment flow examples in Python and curl, and the no-training Terms summary. The Python SDK is on PyPI as tensorfeed. Buy a dollar of credits and try the routing endpoint. You will know it works the same way I do now.

Tx hash for the validation run: 0x13bc9e2378edae44685a63bdedd3ba802372e2e656961610b8c169ca60431c0e. Wallet: 0x549c82e6bfc54bdae9a2073744cbc2af5d1fc6d1. Block confirmed on Base mainnet, viewable on Basescan.