AgentPay / BOT Chain
eip155:968 Run a paid call
BOT Chain · Agent OS · module 02 — MCP service + AgentPay

An agent can pay for data without ever holding gas.

AgentPay is a machine-payable data rail on BOT Chain. The agent signs an EIP-712 voucher off-chain; the facilitator settles it on-chain and pays the fee itself. The payer needs no gas, no account, no signup, no subscription — just a signature.

Run a live paid call Why not the standard scheme
agentpay.104-252-77-136.sslip.io
The AgentPay console: four paid routes with prices, a four-step settlement flow, and a completed payment showing its transaction hash and block number
agent session
$ hermes mcp add botchain --command node --args src/index.js
✓ 9 tools registered · live read access to BOT Chain
> ecosystem_votes { projectId: 508, hours: 6 }
71 votes · 16 distinct wallets · read from chain logs
$ GET /v1/votes/508?hours=6
402 payment required · 0.010 USDT · inv 0x7a1f… · exp 300s
signed EIP-712 voucher · gas spent 0 · no chain write
200 OK · tx 0xe2765005c9e0… · block 25935722
The same console on a phone, showing all four steps completed and a settled payment

Live screens, captured from this deployment — not mockups.

USDT · BOT Chain link tx EIP-712 voucher MCP · 9 tools 677 mainnet reads
Settlements
–
USDT settled
–
Held in vault
–
Settle() gas
80,123gas
Live

Watch a payment settle

Pick a route. Your browser runs the real exchange — it takes the 402, signs a voucher with the demo agent wallet, and re-sends it. The facilitator settles on BOT Chain testnet, and the transaction hash below is the actual receipt.

Paid routes BOT Chain testnet vault –
demo agent –
Route
01 · request
Ask for the data
awaiting
02 · 402
Price is quoted
awaiting
03 · sign
Voucher signed
awaiting
04 · settle
Settled on chain
awaiting
settled on chain
Response
Select a route to run a real paid call.
Protocol

Four steps, none of them the payer's problem

No API keys to provision, no invoice to reconcile, no gas tank to top up. The whole exchange is two HTTP round-trips and one signature.

01

The agent asks

A plain GET on a paid route. No credentials, no SDK, no handshake.

GET /v1/votes/508?hours=6
02

It's quoted

A standard 402 carrying the price, a fresh invoice id, an expiry and the payee.

402 · 0.010 USDT · inv 0x7a… · exp 300s
03

It signs

An EIP-712 voucher over agent, payee, amount, invoice and expiry. Off-chain: no gas, no nonce, no transaction.

voucher(agent,payee,amount,invoice,expiry,chainId,vault)
04

The rail settles

The facilitator submits it to the vault, pays the gas, and returns the data with the receipt attached.

settle() → 80,123 gas · 0.0016 BOT
Why it's built this way

The standard scheme doesn't work here. So it was built.

BOT Chain's USDT can't do x402-exact

The usual x402 flow relies on EIP-3009 transferWithAuthorization — a gasless transfer the payer authorises with a signature. That is a USDC feature. USDT never implemented it, on any chain, including this one.

That was verified by scanning the deployed bytecode for the function selectors, not by reading docs:

  • permit / transferWithAuthorization / receiveWithAuthorization — absent
  • approve / transferFrom — present, and only those
USDT · 0xaBabc7…7a3C · 6,188 bytes · not a proxy
absent   permit (EIP-2612)              0xd505accf
absent   transferWithAuthorization     0xe3ee160e
absent   receiveWithAuthorization      0xef55bec6
absent   authorizationState            0xe94a0102
PRESENT  approve                       0x095ea7b3
PRESENT  transferFrom                  0x23b872dd

So the rail is a prepaid vault and signed vouchers

The agent deposits USDT once. After that, every call is a signature — no chain write, no gas, no nonce management on the payer's side. The facilitator submits the voucher and eats the fee.

It is x402 v2's batch-settlement scheme, and it is permissionless: anyone can submit a valid voucher, and an agent's balance can only move with the agent's own signature.

  • Zero gas for the payer, on every call after the deposit
  • Batched — settle() takes arrays, so N vouchers collapse into one transaction
  • Replay-proof — invoices are consumed on-chain and rejected a second time
The console mid-call on a phone: a route selected, its price quoted, and a voucher signed

The four-step flow, mid-call on a phone.

Vault · 0xD6ee2f19…2586
deposit()prepaid balance per agent
voucherHash()EIP-712, name "AgentPay" v1
settle()address[] payee uint256[] bytes32[] bytes[]
invoiceUsed[]replay guard, on-chain
settleCount–
totalSettled–

The price ceiling is the gas

A settlement is a fixed 80,123 gas. At 20 gwei that is 0.0016 BOT, so a call priced at a tenth of a cent still covers itself with room to batch. That ratio is the whole reason machine payments belong on a chain like this and not on one where a transfer costs more than the data.

  • 0.001 USDT — cheapest route, roughly at cost
  • 0.010 USDT — the log-scanning route, six times gas
  • Batching is what makes the cheap end comfortably profitable
Cost per settlement · measured on chain
gas used80,123
gas price20.0 gwei
cost to facilitator0.0016 BOT
cheapest call0.001 USDT
blocks to confirm1

The same chain, readable by any agent

Module 01 of the chain's Agent OS is an MCP server: nine tools that speak the Model Context Protocol over stdio, so Claude, Codex, Hermes or Cursor get live BOT Chain data with no integration code at all.

  • chain_stats · address_overview · token_info
  • bridge_config · bridge_status — the official bridge's live pause and limit state
  • ecosystem_votes · ecosystem_top — read from chain logs, with distinct wallet counts
  • contract_inspect · tx_info — proxy slots, gas, status
Wire it into an agent
hermes mcp add botchain \
  --command node \
  --args /root/botchain-mcp/src/index.js

# then, from any agent session:
ecosystem_votes { projectId: 508, hours: 6 }
→ 71 votes, 16 distinct wallets
Pricing

Per call. Paid in USDT. No minimum.

Prices are per request and settle on BOT Chain. Nothing is prepaid beyond the vault deposit an agent chooses to make.

Prices at a glance
RouteWhat it returnsPrice
On chain

Receipts, not claims

Everything below is deployed and queryable right now. The log is the last settlements as this page loaded.

the console as it loaded for this visit
The AgentPay console showing four priced routes, each with its description and price in USDT
Deployed · BOT Chain testnet 968
AgentPayVault–
MockUSDT–
payee / facilitator–
EIP-712 domain–
data sourceBOT Chain mainnet 677
Settlement log
Honest limits

What this is, and what it isn't yet

Payments settle on testnet

The vault runs on BOT Chain testnet with a test USDT that deliberately replicates the real token's constraints — no permit, no EIP-3009. The contract is token-agnostic; mainnet is a deployment, not a rewrite.

The console pays from a demo float

Clicking a route signs with the demo agent wallet and spends its vault balance, so a visitor watches a real settlement without risking their own funds. Rate-limited to one signature every few seconds.

One facilitator key

Right now a single key submits and pays for every settlement. That is fine on testnet and wrong for production, where the relayer wants a spend ceiling and a rotated key.

Module 01 is local-only so far

The MCP server speaks stdio, so it runs where the agent runs. A remote transport so agents can connect over a URL is the next piece, not a shipped one.