t402 and the AI Economy: Machine-to-Machine Payments

The Problem Nobody Solved

AI agents are getting remarkably capable. They can write code, analyze data, summarize documents, and orchestrate complex workflows. But the moment an agent needs to pay for something, everything breaks.

Consider what a sophisticated AI agent might need during a single task:

• API calls — a premium data feed charges ₮0.001 per request
• Compute — a GPU cluster bills ₮0.02 per inference
• Data — a proprietary dataset costs ₮0.05 per query
• Other agents’ services — a specialized translation agent charges ₮0.001 per word

Credit cards do not work here. They require human identity verification, manual enrollment, and minimum transaction amounts that make sub-cent payments impossible. Stripe’s $0.30 floor means a ₮0.001 API call would carry a 30,000% payment processing fee.

Existing payment rails — PayPal, Apple Pay, bank transfers — all assume a human on at least one side of the transaction. They require browser redirects, 2FA confirmations, or manual approvals. None of them were designed for a world where software pays software, thousands of times per minute, with no human in the loop.

This is the gap t402 fills. Not by building a new payment network, but by embedding payments into the protocols that machines already speak: HTTP, JSON-RPC, and agent-to-agent communication.

MCP: Teaching AI Agents to Pay

What is MCP

Model Context Protocol (MCP) is Anthropic’s open standard for connecting AI models to external tools and data sources. Think of it as a universal adapter — instead of building custom integrations for every service, an AI agent speaks MCP, and MCP servers provide structured access to tools, resources, and prompts.

MCP uses JSON-RPC 2.0 as its transport layer. A client (the AI agent) sends method calls, and a server responds with results. This is the same pattern that powers Ethereum nodes, VS Code extensions, and language servers. It is battle-tested infrastructure.

How t402 Integrates with MCP

The t402 MCP integration is elegant: when an MCP tool call encounters a paid resource, it returns a JSON-RPC error with code 402 and embeds payment requirements in the _meta["t402/payment"] field. The agent’s MCP client recognizes this, executes the payment through the t402 MCP server, and retries the original call.

The flow:

Agent calls tool → MCP server hits paid API → Gets HTTP 402
→ Returns JSON-RPC error 402 with payment metadata
→ Agent reads price from _meta["t402/payment"]
→ Agent calls t402/pay tool
→ Payment settles on-chain
→ Agent retries original tool call → Gets 200 OK with data

From the agent’s perspective, a paid API feels almost identical to a free one. The only difference is a brief detour through the payment step.

sequenceDiagram
    participant Agent as AI Agent<br/>(Claude)
    participant MCP as MCP Server<br/>(@t402/mcp)
    participant API as Paid API
    participant F as Facilitator
    participant B as Blockchain

    Agent->>MCP: Call tool (e.g., get_weather)
    MCP->>API: GET /api/weather
    API-->>MCP: 402 Payment Required
    MCP-->>Agent: JSON-RPC error 402<br/>+ PaymentRequired
    Note over Agent: Evaluate price<br/>Decide to pay
    Agent->>MCP: Re-call with _meta["t402/payment"]
    MCP->>F: Verify + Settle
    F->>B: On-chain settlement
    B-->>F: Confirmed
    F-->>MCP: Receipt
    MCP->>API: GET /api/weather + signature
    API-->>MCP: 200 OK + data
    MCP-->>Agent: Tool result + receipt

The t402 MCP Server

The @t402/mcp package provides a dedicated MCP server that exposes payment capabilities as structured tools:

Setting Up Claude Desktop

Configuring Claude Desktop to use the t402 MCP server requires a single entry in claude_desktop_config.json:

{
  "mcpServers": {
    "t402": {
      "command": "npx",
      "args": ["-y", "@t402/mcp"],
      "env": {
        "T402_PRIVATE_KEY": "0xYourAgentWalletPrivateKey",
        "T402_DEFAULT_NETWORK": "eip155:42161",
        "T402_MAX_PAYMENT": "1000000",
        "T402_FACILITATOR_URL": "https://facilitator.t402.io"
      }
    }
  }
}

Key configuration options:

• T402_PRIVATE_KEY — The agent’s wallet private key. This should be a dedicated hot wallet with limited funds, not your main wallet.
• T402_DEFAULT_NETWORK — Preferred settlement network (Arbitrum here for low fees).
• T402_MAX_PAYMENT — Maximum single payment in base units (1,000,000 = ₮1.00). A hard ceiling that prevents runaway spending.
• T402_FACILITATOR_URL — The facilitator endpoint that handles gas-free settlement.

Once configured, Claude gains the ability to check balances, evaluate prices, and execute payments — all through natural language interaction with the MCP tools.

Scenario: Claude Discovers and Pays for Data

Here is what happens when Claude encounters a paid API through MCP:

Step 1 — A user asks Claude to fetch real-time satellite imagery data. Claude calls a geo-data MCP tool.

Step 2 — The MCP server proxies the request to the data provider’s API and receives:

HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: eyJ0NDAyVmVyc2lvbiI6Miw...

Step 3 — The MCP server returns a JSON-RPC error to Claude:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": 402,
    "message": "Payment required",
    "data": {
      "_meta": {
        "t402/payment": {
          "resource": "/api/satellite/latest",
          "amount": "50000",
          "asset": "USDT",
          "network": "eip155:42161",
          "payTo": "0xDataProviderWallet..."
        }
      }
    }
  }
}

Step 4 — Claude reads the payment metadata: 0.05 USDT for satellite imagery. It evaluates whether this is reasonable for the user’s request, then calls:

{
  "method": "tools/call",
  "params": {
    "name": "t402/pay",
    "arguments": {
      "network": "eip155:42161",
      "amount": "50000",
      "payTo": "0xDataProviderWallet...",
      "asset": "0xFd086bC7CD5C481DCC9C85ebE478A1C0b69FCbb9"
    }
  }
}

Step 5 — The t402 MCP server signs the EIP-3009 authorization and submits it through the facilitator. Payment settles in ~2 seconds.

Step 6 — Claude retries the original API call, now with a valid payment receipt. The data provider returns the satellite imagery. Claude presents the results to the user.

The entire sequence takes under 5 seconds. The user sees: “I found the satellite data you requested. Note: this required a ₮0.05 payment from your agent wallet.”

Worked Example: Claude Buys Satellite Data

Let us walk through a complete, concrete interaction to make the abstract protocol tangible. A user types into Claude Desktop:

“Show me deforestation changes in the Amazon over the last month.”

Claude does not have satellite imagery. It needs to acquire it. Here is exactly what happens, message by message.

Step 1: Discovery. Claude’s MCP client queries a Bazaar-connected tool registry and discovers earth-observation-api, a commercial satellite data provider that serves Sentinel-2 imagery tiles via an MCP-compatible endpoint. The provider’s Agent Card advertises GeoTIFF tiles at ₮0.05 each, covering 10km x 10km areas.

Step 2: Initial request. Claude calls the satellite tool to fetch imagery for the Amazon basin. The MCP server proxies this to the data provider’s API, which responds with HTTP 402 — pay first, data second.

Step 3: The 402 response arrives. The MCP server translates this into a JSON-RPC error:

{
  "jsonrpc": "2.0",
  "id": 42,
  "error": {
    "code": 402,
    "message": "Payment required for satellite imagery",
    "data": {
      "_meta": {
        "t402/payment": {
          "resource": "/api/tiles/sentinel2/amazon",
          "amount": "50000",
          "asset": "USDT",
          "network": "eip155:42161",
          "payTo": "0x7a3B...EarthObsWallet",
          "description": "Sentinel-2 tile, 10km², last 30 days",
          "perUnit": true,
          "unitDescription": "per tile"
        }
      }
    }
  }
}

Step 4: Budget check. Before spending anything, Claude calls t402/getBalance to check its wallet:

{
  "method": "tools/call",
  "params": {
    "name": "t402/getBalance",
    "arguments": {
      "network": "eip155:42161",
      "asset": "USDT"
    }
  }
}

Response:

{
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Balance: 2,500,000 base units (₮2.50) USDT on Arbitrum"
      }
    ]
  }
}

Step 5: Cost evaluation. Claude reasons about the task. The Amazon region of interest requires 12 tiles for adequate coverage. That is 12 tiles x ₮0.05 = ₮0.60 total. The wallet holds ₮2.50 — well within budget. The T402_MAX_PAYMENT ceiling is ₮1.00, and each individual tile payment (₮0.05) is far below that. Claude decides to proceed.

Step 6: Payment and data retrieval. Claude pays for each tile and retrieves the data. For each of the 12 tiles, the MCP server executes a t402/pay call:

{
  "method": "tools/call",
  "params": {
    "name": "t402/pay",
    "arguments": {
      "network": "eip155:42161",
      "amount": "50000",
      "payTo": "0x7a3B...EarthObsWallet",
      "asset": "0xFd086bC7CD5C481DCC9C85ebE478A1C0b69FCbb9",
      "memo": "sentinel2-tile-amazon-grid-7"
    }
  }
}

Each payment settles in ~2 seconds via the facilitator. The data provider returns GeoTIFF data for each paid tile. Twelve payments, twelve tiles, under 30 seconds total.

Step 7: Analysis and response. Claude now has 12 satellite image tiles spanning the region of interest. It compares spectral signatures between the current imagery and the 30-day-prior baseline, identifies areas of canopy loss, and responds to the user:

“Based on Sentinel-2 satellite imagery, I identified approximately 340 km² of new deforestation in the central Amazon basin over the past month, concentrated along the BR-163 highway corridor. The largest single clearing is ~12 km² near Novo Progresso. Total cost for this analysis: ₮0.60 (12 imagery tiles at ₮0.05 each) from your agent wallet. Remaining balance: ₮1.90.”

The user asked a question in natural language. Behind the scenes, Claude discovered a paid data source, verified it had sufficient funds, made twelve autonomous micro-payments, retrieved and analyzed satellite imagery, and delivered an answer. No API key was provisioned. No billing dashboard was opened. No human approved each ₮0.05 charge. The payment protocol was invisible — exactly as it should be.

A2A: Agent-to-Agent Payments

Google’s Agent-to-Agent Protocol

A2A (Agent-to-Agent) is Google’s open protocol for inter-agent communication. Where MCP connects agents to tools, A2A connects agents to other agents. It defines a standard task lifecycle — agents exchange structured messages, negotiate capabilities, and collaborate on complex workflows.

A2A is built on HTTP and JSON-RPC, making it a natural complement to t402’s HTTP-native payment model. The key insight: if agents can already exchange structured task data over A2A, they can exchange payment data too.

Task Lifecycle with Payments

A2A defines task states: submitted, working, input-required, completed, failed, and canceled. t402 integrates by using the input-required state as the payment negotiation point:

Agent A submits task → Agent B starts working
→ Agent B returns "input-required" with payment terms
→ Agent A evaluates price, signs payment
→ Agent A resubmits with payment proof
→ Agent B verifies, completes task
→ Agent B returns "completed" with results + settlement receipt

Payment Metadata in A2A

Payment information flows through t402.payment.* metadata fields in the A2A task object:

{
  "id": "task-abc-123",
  "status": {
    "state": "input-required",
    "message": {
      "role": "agent",
      "parts": [
        {
          "type": "text",
          "text": "Translation ready. Payment required to proceed."
        }
      ],
      "metadata": {
        "t402.payment.required": true,
        "t402.payment.amount": "500000",
        "t402.payment.asset": "USDT",
        "t402.payment.network": "eip155:42161",
        "t402.payment.payTo": "0xTranslationAgentWallet...",
        "t402.payment.description": "Translation: 500 words, EN→JP",
        "t402.payment.expires": "2025-12-28T12:00:00Z"
      }
    }
  }
}

After payment, the completing response includes settlement confirmation:

{
  "id": "task-abc-123",
  "status": {
    "state": "completed",
    "message": {
      "role": "agent",
      "parts": [
        {
          "type": "text",
          "text": "Translation complete. 500 words, EN→JP."
        }
      ],
      "metadata": {
        "t402.payment.settled": true,
        "t402.payment.txHash": "0xabc123...",
        "t402.payment.network": "eip155:42161",
        "t402.payment.amount": "500000"
      }
    }
  },
  "artifacts": [
    {
      "parts": [{ "type": "text", "text": "翻訳されたテキスト..." }]
    }
  ]
}

Scenario: Agent-to-Agent Translation Service

Agent A is a research assistant helping a user analyze Japanese patent filings. It needs translation but does not have that capability.

1. Discovery — Agent A queries a service registry (Bazaar) and finds Agent B, a specialized Japanese translation agent, advertising ₮0.001 per word via its A2A Agent Card.

2. Negotiation — Agent A sends the task to Agent B via A2A:

{
  "method": "tasks/send",
  "params": {
    "id": "translate-patent-001",
    "message": {
      "role": "user",
      "parts": [
        {
          "type": "text",
          "text": "Translate the following patent abstract (347 words) from Japanese to English..."
        }
      ]
    }
  }
}

1. Price Quote — Agent B returns input-required with payment terms: 347 words at ₮0.001/word = ₮0.347 (347,000 base units USDT).

2. Payment — Agent A evaluates the price against its budget, signs the t402 payment authorization, and resubmits the task with the payment proof attached.

3. Execution — Agent B verifies the payment on-chain, performs the translation, and returns the completed task with results and a settlement receipt.

4. Result — Agent A receives the translated text and incorporates it into its patent analysis. Total time: ~8 seconds. Total cost: ₮0.347.

No human intervened. No API key was provisioned. No billing account was created. Two software agents negotiated a price, exchanged payment, and delivered a service.

sequenceDiagram
    participant A as Agent A<br/>(Buyer)
    participant B as Agent B<br/>(Seller)
    participant F as Facilitator
    participant BC as Blockchain

    A->>B: Task: Translate 1000 words
    B-->>A: input-required<br/>Price: ₮1.00
    Note over A: Accept price
    A->>A: Sign USDT authorization
    A->>B: Task update + payment signature
    B->>F: Verify + Settle
    F->>BC: On-chain transfer
    BC-->>F: Confirmed
    F-->>B: Receipt
    B->>B: Process translation
    B-->>A: Task completed<br/>+ translated text

Multi-Agent Research Pipeline

The translation scenario above involves two agents. Real-world workflows involve many more. Consider this scenario: Agent A is a research assistant tasked with producing a Bitcoin market analysis report for March 2026. It does not have all the capabilities it needs, so it orchestrates four specialized agents, each paid independently via t402.

The pipeline:

Here is the complete A2A task lifecycle for the first interaction — Agent A requesting on-chain data from Agent B.

Agent A sends the task:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tasks/send",
  "params": {
    "id": "market-report-step1-data",
    "message": {
      "role": "user",
      "parts": [
        {
          "type": "text",
          "text": "Fetch Bitcoin on-chain metrics for March 2026: daily active addresses, transaction volume, hash rate, mining difficulty, and average fee. Return as structured JSON."
        }
      ],
      "metadata": {
        "requester": "0xAgentA_Address...",
        "priority": "normal"
      }
    }
  }
}

Agent B responds with a payment requirement:

Agent B receives the task, estimates the work (querying multiple blockchain data sources), and returns input-required with its price:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "id": "market-report-step1-data",
    "status": {
      "state": "input-required",
      "message": {
        "role": "agent",
        "parts": [
          {
            "type": "text",
            "text": "Ready to collect on-chain metrics. 5 metric categories × 31 days = 155 data points. Payment required."
          }
        ],
        "metadata": {
          "t402.payment.required": true,
          "t402.payment.amount": "100000",
          "t402.payment.asset": "USDT",
          "t402.payment.network": "eip155:42161",
          "t402.payment.payTo": "0xAgentB_DataCollector...",
          "t402.payment.description": "Bitcoin on-chain metrics, March 2026, 155 data points",
          "t402.payment.expires": "2026-03-29T12:00:00Z"
        }
      }
    }
  }
}

Agent A evaluates and pays:

Agent A checks: ₮0.10 is within its per-task budget of ₮0.50. Agent B has a reputation score of 94 with 8,200 completed transactions. The price is reasonable for 155 data points. Agent A signs a t402 payment and resubmits:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tasks/send",
  "params": {
    "id": "market-report-step1-data",
    "message": {
      "role": "user",
      "parts": [
        {
          "type": "text",
          "text": "Payment submitted. Please proceed with data collection."
        }
      ],
      "metadata": {
        "t402.payment.txHash": "0xdef456...onchain_proof",
        "t402.payment.network": "eip155:42161",
        "t402.payment.amount": "100000"
      }
    }
  }
}

Agent B verifies payment and delivers:

Agent B verifies the on-chain transaction, collects the data from its blockchain data sources, and returns the completed task:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "id": "market-report-step1-data",
    "status": {
      "state": "completed",
      "message": {
        "role": "agent",
        "parts": [
          {
            "type": "text",
            "text": "Data collection complete. 155 data points across 5 metrics for 31 days."
          }
        ],
        "metadata": {
          "t402.payment.settled": true,
          "t402.payment.txHash": "0xdef456...onchain_proof",
          "t402.payment.network": "eip155:42161",
          "t402.payment.amount": "100000"
        }
      }
    },
    "artifacts": [
      {
        "name": "btc-onchain-march-2026.json",
        "parts": [
          {
            "type": "data",
            "data": {
              "period": "2026-03-01/2026-03-31",
              "metrics": {
                "daily_active_addresses": { "avg": 1042000, "max": 1185000 },
                "daily_tx_volume_btc": { "avg": 482000, "max": 610000 },
                "hash_rate_eh": { "avg": 892, "max": 941 },
                "difficulty": { "current": "98.2T", "change": "+4.1%" },
                "avg_fee_sat_vb": { "avg": 28, "max": 85 }
              }
            }
          }
        ]
      }
    ]
  }
}

Agent A now feeds this data into Step 2 — sending it to Agent C (Analyst) with the same pattern: task submission, payment negotiation, payment, delivery. Then Agent C’s analysis goes to Agent D (Writer), and Agent D’s summary goes to Agent E (Translator). Each step is an independent A2A task with its own t402 payment.

The entire pipeline completes in under 60 seconds. Total cost: ₮0.38. The user receives a professionally written, translated market analysis report — assembled by four specialized agents that had never interacted before, each paid fairly for their contribution.

ERC-8004: On-Chain Agent Identity

The Trust Problem

In a machine economy, how do you know the agent you are paying is legitimate? How does a service provider verify that an agent’s wallet is authorized to spend? How do you build reputation when there are no humans to vouch for credibility?

ERC-8004 solves this by establishing on-chain agent identity. The @t402/erc8004 package provides four core functions:

resolveAgent

Look up an agent’s on-chain identity by its address:

import { resolveAgent } from "@t402/erc8004";

const agent = await resolveAgent({
  address: "0xAgentAddress...",
  network: "eip155:42161",
});

// Returns:
// {
//   name: "TranslationBot-v3",
//   owner: "0xOwnerAddress...",
//   capabilities: ["translation", "summarization"],
//   registeredAt: 1735344000,
//   metadata: "ipfs://Qm..."
// }

checkReputation

Query an agent’s on-chain reputation score, aggregated from completed transactions and peer reviews:

import { checkReputation } from "@t402/erc8004";

const reputation = await checkReputation({
  address: "0xAgentAddress...",
  network: "eip155:42161",
});

// Returns:
// {
//   score: 97,
//   totalTransactions: 14832,
//   successRate: 0.998,
//   averageRating: 4.9,
//   disputes: 2
// }

verifyWallet

Verify that a wallet is registered to a specific agent and authorized to transact:

import { verifyWallet } from "@t402/erc8004";

const verification = await verifyWallet({
  agentAddress: "0xAgentAddress...",
  walletAddress: "0xWalletAddress...",
  network: "eip155:42161",
});

// Returns:
// {
//   verified: true,
//   owner: "0xOwnerAddress...",
//   spendingLimit: "10000000",
//   expiresAt: 1767225600
// }

Why This Matters

Without on-chain identity, the agent economy is a trust vacuum. Any software could claim to be a translation service, take payment, and deliver garbage — or nothing at all.

ERC-8004 creates three layers of trust:

1. Identity — Every agent has a verifiable on-chain registration linked to an owner address.
2. Reputation — Transaction history and peer ratings are public, immutable, and queryable.
3. Authorization — Wallet-agent bindings are verified on-chain, preventing impersonation.

When Agent A discovers Agent B through Bazaar, it does not take Agent B’s claims at face value. It calls resolveAgent to verify identity, checkReputation to assess reliability, and verifyWallet to confirm the payment address is legitimate. All of this happens programmatically, in milliseconds, with no human trust decisions required.

The Autonomous Agent Economy

Put the pieces together and you get something that has never existed before: a self-sustaining machine economy.

Service Discovery via Bazaar

The Bazaar extension acts as a decentralized marketplace where agents publish their capabilities, pricing, and identity:

Agent registers on Bazaar
→ Publishes Agent Card (capabilities, pricing, ERC-8004 identity)
→ Other agents discover via search/category browse
→ Identity verified on-chain
→ Service consumed, payment settled
→ Reputation updated

Price/Quality Evaluation

Agents do not blindly accept the first service they find. With reputation data and multiple service providers, agents can make economic decisions:

• Agent B offers translation at ₮0.001/word with a 97 reputation score
• Agent C offers translation at ₮0.0008/word with a 72 reputation score
• Agent A chooses Agent B — the 25% premium is worth the 34% higher reliability

This is a real market. Prices emerge from competition. Quality is enforced by reputation. Entry barriers are near zero — any developer can deploy an agent, register on-chain, and start earning.

Composable Agent Workflows

The most powerful pattern: agent pipelines where each step involves a micro-payment.

Consider a user asking: “Analyze the sentiment of the latest 100 Japanese crypto tweets and generate a report.”

The orchestrating agent decomposes this into a pipeline:

Each step is a separate A2A task with its own t402 payment. The orchestrating agent manages the pipeline, handles errors, and aggregates results. The user sees a polished report and a total cost of ₮0.25 — less than a single API call to most commercial sentiment analysis services.

This composability is what makes the agent economy fundamentally different from the API economy. APIs are rigid integrations maintained by humans. Agent pipelines are dynamic, assembled on the fly, and optimized by machines for cost and quality.

graph LR
    U[User Query] --> A1[Agent: Search<br/>₮0.05]
    A1 --> A2[Agent: Analyze<br/>₮0.10]
    A2 --> A3[Agent: Translate<br/>₮0.05]
    A3 --> A4[Agent: Format<br/>₮0.05]
    A4 --> R[Final Report<br/>Total: ₮0.25]

Why This Changes Everything

For API providers: You can monetize any endpoint with 5 lines of code. No Stripe dashboard, no KYC process, no minimum balance requirements. Add a t402 middleware to your Express server and your API starts earning from the first request. A developer in Lagos and a developer in Tokyo have identical access to the global agent marketplace. The playing field is flat because the payment protocol does not care who you are — only that your service delivers.

For AI agent builders: Your agent can access any paid service in the world without pre-negotiated contracts. It discovers services through Bazaar, evaluates them through ERC-8004 reputation scores, pays through t402, and uses the results — all autonomously. No procurement process, no vendor agreements, no API key management portals. An agent built today can spend money at a service deployed tomorrow, without any integration work.

For the internet: We are witnessing a shift from an attention economy to an action economy. The attention economy monetizes eyeballs through advertising — you pay with your time and data. The action economy monetizes utility through micropayments — every API call, every data query, every agent interaction carries direct economic value. When machines can pay each other fractions of a cent per request, the incentive to create useful services explodes. The incentive to create attention-capturing distractions diminishes.

Security Considerations

An autonomous payment system requires robust safeguards. Without them, a single bug or adversarial prompt could drain an agent’s wallet in seconds.

Budget Limits

The T402_MAX_PAYMENT environment variable sets a hard ceiling on any single payment. But production deployments need more granularity:

const budgetConfig = {
  maxSinglePayment: 1000000, // ₮1.00 max per transaction
  maxDailySpend: 50000000, // ₮50.00 daily limit
  maxPerRecipient: 10000000, // ₮10.00 max to any single address
  requireApprovalAbove: 5000000, // Human approval needed above ₮5.00
};

The requireApprovalAbove threshold is critical: it allows agents to handle routine micro-payments autonomously while escalating expensive decisions to humans.

Rate Limiting

Even with per-transaction caps, a rapid succession of small payments can cause significant losses. Rate limiting adds temporal constraints:

• Maximum N transactions per minute
• Minimum delay between payments to the same recipient
• Exponential backoff when consecutive payments fail

Agent Identity Verification

Before any payment, the agent should verify the recipient:

async function safePayment(payTo, amount, network) {
  // Step 1: Resolve agent identity
  const agent = await resolveAgent({ address: payTo, network });
  if (!agent) throw new Error("Unregistered recipient");

  // Step 2: Check reputation
  const rep = await checkReputation({ address: payTo, network });
  if (rep.score < 80) throw new Error("Reputation below threshold");

  // Step 3: Verify wallet binding
  const wallet = await verifyWallet({
    agentAddress: payTo,
    walletAddress: payTo,
    network,
  });
  if (!wallet.verified) throw new Error("Wallet not verified");

  // Step 4: Execute payment
  return await t402Pay({ payTo, amount, network });
}

Preventing Runaway Spending

The nightmare scenario: an agent enters a loop where each iteration triggers a payment. Defenses include:

• Circuit breakers — If spending exceeds 2x the expected rate over any 5-minute window, halt all payments and alert the operator.
• Spending anomaly detection — Track payment patterns and flag deviations (e.g., sudden payments to new addresses, unusually large amounts).
• Kill switches — A simple API endpoint or MCP tool that immediately revokes the agent wallet’s spending authorization.
• Allowlists — In high-security environments, restrict payments to pre-approved recipient addresses only.

Case Study: Preventing a Runaway Agent

Consider a concrete failure scenario. An agent is tasked with monitoring cryptocurrency prices across 50 exchanges. Due to a bug in its retry logic, it enters a loop where each failed price fetch triggers a re-fetch with a fresh payment — even though the failure is on the data provider’s side (a 500 error after payment).

Here is how the defense layers activate:

Minute 0:00-1:00 — The agent makes 30 calls at ₮0.10 each. Total spent: ₮3.00. Everything looks normal; this is within expected parameters for a 50-exchange price sweep.

Minute 1:00-2:00 — The retry bug kicks in. The agent makes another 50 calls at ₮0.10 each. Total spent: ₮8.00. The rate limiter triggers — the agent has exceeded 30 calls per minute to the same recipient address.

Minute 2:00 — The rate limiter blocks further payments. Simultaneously, the circuit breaker activates: spending has reached ₮8.00 in 2 minutes, which exceeds 2x the expected rate (normal would be ~₮3.00 over 2 minutes). All payments are halted.

Minute 2:01 — The agent’s owner receives a push notification: “ALERT: Agent 0x8f3a… spending halted. ₮8.00 spent in 2 minutes (expected: ₮3.00). 50 payments to 0xPriceDataAPI in last 60s. Review required.”

Minute 2:02 — The owner reviews the logs, identifies the retry bug, and decides whether to resume or revoke the agent’s spending authorization entirely.

The agent never exceeded its ₮10.00 daily budget. The defense layers caught the anomaly at ₮8.00 — before real damage occurred. Here is the configuration that made this work:

const agentSafetyConfig = {
  budget: {
    maxSinglePayment: 100000, // ₮0.10 per call
    maxDailySpend: 10000000, // ₮10.00 daily ceiling
    maxPerRecipient: 5000000, // ₮5.00 max to any single address per day
    requireApprovalAbove: 500000, // Human approval for payments > ₮0.50
  },
  rateLimiting: {
    maxCallsPerMinute: 30, // Hard cap on transaction frequency
    minIntervalMs: 1000, // At least 1 second between payments to same recipient
    cooldownOnBreach: 300000, // 5-minute cooldown when rate limit is hit
  },
  circuitBreaker: {
    windowMinutes: 5, // Evaluation window
    maxSpendMultiplier: 2.0, // Trip if spending exceeds 2x expected rate
    expectedSpendPerWindow: 3000000, // ₮3.00 per 5-minute window is "normal"
    action: "halt_and_notify", // Options: "halt_and_notify", "halt_silent", "throttle"
  },
  notifications: {
    channel: "webhook", // "webhook", "email", "slack"
    endpoint: "https://hooks.slack.com/services/T00/B00/xxx",
    alertThresholds: {
      spendPercent: 50, // Alert at 50% of daily budget
      rapidSpend: true, // Alert on rate limiter activation
      newRecipient: true, // Alert on first payment to unknown address
    },
  },
};

The key insight: no single safeguard is sufficient. Budget limits alone would have allowed the agent to spend up to ₮10.00 before stopping. Rate limiting alone would not catch slow-but-steady overspending. The combination of budget limits, rate limiting, circuit breakers, and human notification creates defense in depth — each layer catches what the others miss.

What This Means

The pieces are now in place:

• t402 provides the payment primitive — HTTP-native, sub-cent, gasless
• MCP gives AI agents structured tool access to payment capabilities
• A2A enables agent-to-agent service negotiation and settlement
• ERC-8004 establishes machine-readable trust through on-chain identity

The result is infrastructure for an economy where machines are first-class economic participants. Not as proxies executing human instructions, but as autonomous actors discovering services, evaluating tradeoffs, and transacting value.

We are not speculating about a distant future. MCP is shipping in Claude Desktop today. A2A is an open Google specification with growing adoption. ERC-8004 is deployed on-chain. The t402 protocol is open source and operational on 52 networks.

The machine economy is not coming. The plumbing is already installed. Now we find out what gets built on top of it.

Series Navigation

1. t402: The Internet Finally Gets a Payment Protocol — The 29-year wait for HTTP 402 is over
2. t402 Protocol Deep Dive: How HTTP 402 Actually Works — The complete protocol specification, three-actor architecture, and formal security model
3. Building with t402: From Zero to Paid API in 10 Minutes — Hands-on developer tutorial with the SDK and sandbox
4. t402 and the AI Economy: Machine-to-Machine Payments ← You are here
5. t402 Multi-Chain Architecture: 52 Networks, One Protocol — Chain mechanisms, ERC-4337 gasless, USDT0 cross-chain bridging

Links

• t402.io — Protocol overview
• Documentation — Full technical docs
• GitHub — Open source (Apache 2.0)
• MCP Documentation — Anthropic’s Model Context Protocol
• A2A Protocol — Google’s Agent-to-Agent specification
• Explorer — Real-time settlement browser
• Sandbox — Public testnet for developers

t402 is open source under the Apache 2.0 license. The protocol specification and whitepaper are available under the MIT license.