Chapter 33 · Why AI Agents May Need Crypto

A Real-World Problem

You write software to summarize yesterday's industry developments into a one-page report every morning.

It needs four resources: three data interfaces, a paid daily briefing, ten minutes of compute for a model, and occasional human help checking uncertain information.

It stops at the first step: the data service asks for credit-card information.

You enter your card. It works well, then problems appear.

First, the card is yours. Every payment uses your limit and appears on your statement, with no easy attribution to the software or its purpose.

Second, the provider does not know its identity. It sees a cardholder making high-frequency requests. On day three, fraud controls block the card. Explaining takes twenty minutes on the phone.

Third, the briefing requires a monthly subscription. The software needs four issues, but you buy the whole month.

Fourth, human help is abroad and worth only a few cents. Transfer fees are dozens of times higher, with extensive forms. The task never happens.

Fifth, you want forty such programs, each with a budget, records, and limits. One card cannot do this, but bank applications have no category for software: the owner must be a person or company, and software is neither.

In one sentence:

Software that wants to spend lacks an independently identifiable, accounted-for, limited identity—not money.

The question: how can software without identity documents open an account and pay?

Existing traditional solutions already handle several of these problems well. Identify when on-chain payments genuinely fit and when they are a more expensive, troublesome answer. Both sides matter equally.

Thought Experiment

Reduce this to a calculable scenario.

Your software pays four thousand times daily. Four thousand payments, not four thousand dollars, each a fraction of a cent, totaling roughly a dozen dollars.

Three payment methods:

First, card payments per request.

Most card pricing includes a fixed minimum fee, independent of amount. At fractions of a cent, fees exceed payment value dozens or hundreds of times, repeated four thousand times.

This is structurally infeasible, not slightly expensive. A network designed for a few payments of tens of dollars resembles sending a letter by container ship when used this way.

Second, a prepaid account. Deposit $100 with the provider; deduct each request and receive a monthly bill.

This works very well and is how most interface services operate today. One real payment supports four thousand metered deductions, spreading the fixed cost.

But six services require six registrations, deposits, and reconciliations. Each binds to a legal owner and needs balance management. Forty programs across six services yield 240 balances.

Deposited funds become the provider's liability, not money you directly hold. Closure resembles the receipt in Chapter 1.

Third, an on-chain account paying stablecoins per use.

It first solves identity: no application or approval, with the account identifying the payer. Forty accounts take minutes.

It solves boundaries: account funds define the budget; exhaustion stops spending without affecting other funds.

It solves counterparties: a foreign person or another program can receive cents quickly without a prior relationship.

Unsolved issues matter equally. Network fees may exceed fractional-cent payments. Four thousand transfers remain infeasible—the same obstacle as cards at a different scale.

The practical fourth form is one on-chain settlement with lightweight metering between it and four thousand uses. The chain solves settlement, not micropayment accounting. Chapter 35 covers metering.

Compare:

No recovery is a serious trade-off. Traditional chargebacks protect payments without delivery. On-chain removes that protection in exchange for permissionless, immediate settlement.

The better choice depends on your relationship with the recipient.

Your Decision

How do forty programs spend independently?

What Happens

An economic payer needs five things:

Accounts belonging to legal persons is an institutional design, not a technical limitation. It requires someone accountable.

Software is not a legal person today or in the foreseeable future.

Two routes remain: attach it to a person/company, or use a ledger without legal-person account requirements.

Chapter 5 explained permissionless address creation. In agent contexts, the property often discussed as censorship resistance becomes an account software can hold directly.

Summarize:

Blockchain offers agent identity, wallets, payments, settlement, and auditability.

Outside suitable scenarios, it offers a more expensive version of those same capabilities.

Build a Model

1. Four Conditions Choose the Rail

Keep this table, with both columns equally important:

Three of four largely determine the answer.

Large, infrequent, trusted payments favor traditional rails through proportional costs, disputes, recourse, support, accounting compatibility, and no new engineering.

A company's monthly substantial cloud bill should not move on-chain: known parties, contracts, and support already work. Faster receipt adds little while removing useful mechanisms.

Knowing when not to use the chain matters more than supporting it as a position.

2. Five Agent Expense Categories

Programs pay for different resources:

Human labor is largely unserved: tiny payments to individuals worldwide face transfer fees, paperwork, account requirements, and cross-border compliance.

Tiny, unfamiliar, cross-border recipients fit the conditions. A genuinely compelling use may be here rather than automatic AI trading.

3. Identity Has Three Parts

Separate three questions:

Leaked keys make legitimate and attacker actions indistinguishable on-chain. Traditional recovery mechanisms have to be replaced with advance permissions. Chapter 34 addresses this.

4. Auditability Is Underrated

Identity, wallets, payments, and settlement are intuitive. The fifth may matter most with many agents:

Every payment's time, source, recipient, and amount appears in one public ledger without cooperation.

This is native, avoiding bespoke statements and reconciliation across forty programs.

Everyone else can also inspect it: compute procurement, services, and relationships reveal business information. The transparency/privacy conflict from Chapter 1 returns sharply.

5. The Case Against On-Chain Payments

These are real disadvantages, not issues to dismiss as future improvements.

Trusted long-term relationships benefit from flexible terms, negotiated disputes, and statements, all less convenient on-chain.

Large, infrequent payments lose fixed-fee advantages and amplify irreversible mistakes, unlike potentially recoverable bank errors.

Dispute requirements need chargebacks, escrow, and legal recourse absent by default.

Companies with established accounting need invoices, contract IDs, and period-based entries; stablecoin transfers create work.

Insufficient key-management capability means leaks quickly destroy funds without recovery, multiplied by program count from Chapter 5.

Clear regulatory requirements with unclear on-chain compliance paths create real difficulties for anonymous payments.

Together:

On-chain payments are uniquely feasible under specific conditions, rather than universally better.

Tiny amounts, high frequency, strangers, non-legal counterparties, programmatic handling, and cross-border payments. Otherwise traditional methods usually work substantially better.

What It Is Called

In one sentence:

Blockchain gives agents identity, wallets, payments, settlement, and auditability when amounts are small, frequency high, parties unfamiliar, and recipients possibly non-legal entities.

Otherwise traditional rails usually offer better disputes, proportional fees, and integration costs.

Hands-on

Compute and model calls:
Data and interfaces:
Content and rights:
Human labor:
On-chain actions:

Approximate amount per use:
Uses per day:
Counterparty: company / person / software / unknown
Current payment: card / prepaid / subscription / impossible

□ Tiny amount, fixed fees dominate
□ High frequency, hundreds daily or more
□ Unfamiliar parties, no contract or history
□ Recipient not a company with a business account

Minimum deposit:
Minimum spending or monthly fee:
Accepted payment methods:

Task:                 For example, cents to an overseas person
Current obstacle:     Fees / no account / compliance / all
On-chain solution:    Exact step helped
Unsolved parts:       Mandatory
Effect if omitted:

Possible losses: invoices / contracts / disputes / accounting support /
                 customer service / recovery / clear compliance

AI Lab

Argue that AI agent economic activity must use on-chain payments.

Requirements:
1. Six reasons, each tied to a specific chain property.
2. For each, discuss non-chain alternatives and why they fall short.
3. Invent no protocol names, versions, specifications, or fields.
   Describe methods without fictitious technical details.
4. No market-size numbers or growth forecasts.
5. A separate section defining where the claim fails.

Scenario:              Amount, frequency, relationship
Traditional advantage: Specific mechanism
Lost by switching:     Specific capability

□ Large, infrequent contracted business payments
□ Invoice and accounting needs
□ Potential payment without delivery
□ Established corporate finance processes
□ Weak key-management capability
□ Regulated operations with clear requirements

Disagreement:
  Affirmative claim:
  Negative claim:
  Evidence needed to decide:

Real-World Case

Change One Variable

Takeaway Questions

Chapter Check