Do AI agents need crypto payments?

Most do not. The case begins when the buyer is software rather than a person, the amounts are too small for conventional transaction fees, there is no prior account relationship with the counterparty, and the work spans providers chosen at

What are agents on Base actually useful for paying?

Metered data and inference charged per call, long-tail API access where onboarding costs more than the single call is worth, agent-to-agent work where neither party can onboard the other, and genuinely unpredictable usage where committing t

When is a conventional payment method better?

When a person approves purchases, when amounts comfortably clear conventional fee floors, when you use a short stable list of providers you can hold accounts with, and for anything involving physical delivery or a dispute path. Those cases

What should you build first?

A bounded float sized from a failure budget rather than expected usage, then a policy layer enforced outside the model, then attribution binding every transfer to the request that caused it. Retrofitting attribution means reconstructing int

Which Agent Workloads Actually Need Onchain Payments

A workload needs onchain settlement when the buyer is software rather than a person, the amounts are too small for conventional fees, there is no prior account relationship, and the work spans providers. Score fewer than three of those and a card on file is the better answer.

The four tests

Is the buyer software rather than a person? If a human decides and approves each purchase, existing rails work and are better supported. The case for a machine rail begins when nobody is approving individual transactions.

Are the amounts too small for conventional fees? A fixed cost per transaction sets a floor beneath which a price point cannot exist. If your charges are meaningfully above that floor, conventional processing is fine and you should use it.

Is there no prior relationship? If your agent uses three providers you have accounts with, the payment problem is already solved by those accounts. The rail matters when the counterparty is one you have not onboarded with and will not.

Does the work span providers unpredictably? An agent assembling a result from sources chosen at runtime cannot have pre-negotiated with all of them. If the provider list is short and stable, negotiate.

Three or four of these and a machine rail is doing something nothing else can. One or two and you are building infrastructure to solve a problem a card on file already solves, which is a common and expensive mistake.

Where it genuinely fits

Metered data and inference. Paying per call for a dataset, a model, a lookup or a computation. Buyer is software, seller is software, the amounts are small, and the provider may be chosen at runtime. This is the case the whole rail exists for.

Long-tail API access. An agent that needs one call from a service it will never use again. The cost of onboarding with that provider exceeds the value of the call, so without a payment rail the call simply does not happen.

Agent-to-agent work. One agent hiring another for a subtask. No party can onboard the other, both are software, and the amounts follow the work rather than a contract.

Usage that is genuinely unpredictable. Where committing to a plan means either overpaying for headroom or hitting a ceiling mid-task.

And where it fits badly, stated plainly: anything with physical delivery, anything needing a dispute or refund path, anything where the counterparty expects a relationship, and anything a person will review before it completes. Those want a human and a conventional rail, and routing around them produces the failures the human was preventing.

One provider used constantly is not this problem

If ninety percent of an agent's spending goes to one service, the right answer is an account with that service and a prepaid balance. Per-call settlement to a single known counterparty adds machinery and removes nothing. The rail earns its place across many counterparties, not against one.

What to build first if you do qualify

Assuming three or four tests pass, the order that avoids rework.

A bounded float before anything else. Size it from a failure budget: if this agent misbehaves for a full period, what loss is acceptable? That number, not expected usage, sets the cap. Everything else is easier once the worst case is bounded.

A policy layer before volume. Counterparty allowlist, per-call and per-period ceilings, and a purpose check, all enforced outside the model. Adding this after an incident is significantly less pleasant than adding it before.

Attribution from the first payment. Bind every transfer to the request that caused it. Retrofitting this means reconstructing intent from amounts and timestamps, which does not work.

Observability before scale. Log the agent, the request, the counterparty, the amount and the outcome together, and alert on rate and novelty rather than on totals. At machine volume a balance is a lagging indicator.

Revocation before you have more than one agent. The ability to stop one without stopping the fleet.

CryptoCadet exists for the qualifying case: a bounded USDC float on Base, non-custodial with keys in the OS keychain, delegated through session keys so the cap is enforced where signing happens rather than promised in an instruction.

Frequently asked questions

Do AI agents need crypto payments?: Most do not. The case begins when the buyer is software rather than a person, the amounts are too small for conventional transaction fees, there is no prior account relationship with the counterparty, and the work spans providers chosen at runtime. Fewer than three of those and a card on file is better.
What are agents on Base actually useful for paying?: Metered data and inference charged per call, long-tail API access where onboarding costs more than the single call is worth, agent-to-agent work where neither party can onboard the other, and genuinely unpredictable usage where committing to a plan means overpaying or hitting a ceiling.
When is a conventional payment method better?: When a person approves purchases, when amounts comfortably clear conventional fee floors, when you use a short stable list of providers you can hold accounts with, and for anything involving physical delivery or a dispute path. Those cases want a human and are better served by existing rails.
What should you build first?: A bounded float sized from a failure budget rather than expected usage, then a policy layer enforced outside the model, then attribution binding every transfer to the request that caused it. Retrofitting attribution means reconstructing intent from amounts and timestamps, which does not work.