Payment Channels for High Frequency Agent Payments

How a channel works

Open. Both parties, or in the common asymmetric case just the payer, lock a balance into a contract. This is one on-chain transaction with an ordinary fee.

Transact. For each payment, the payer signs a message stating the new cumulative total owed: after ten calls at one unit each, the message says ten. These messages are exchanged directly between the parties and never broadcast. They cost nothing and are limited only by how fast the two sides can sign and verify.

Close. Either party submits the most recent signed total to the contract, which pays out accordingly and returns the remainder. One more on-chain transaction.

The elegance is in the cumulative total. Because each message supersedes the last, only the newest one has any value, so losing intermediate messages does not matter and there is no ordering problem to solve. The recipient simply keeps the highest signed figure they hold.

So the on-chain cost is two transactions regardless of whether one payment or a million happened in between. That is the entire argument, and it is what makes charges far below the per-transaction fee floor genuinely possible rather than theoretically possible.

What it costs you

Throughput claims about channels are usually accurate and usually omit three things.

Locked capital. The balance in the channel is committed and unavailable for anything else until the channel closes. Running channels with many counterparties means capital fragmented across all of them, and sizing each one is a forecast you will get wrong in one direction or the other.

A liveness requirement. The recipient must hold the latest signed total and be able to submit it. If they lose it, they can only claim the last one they still have. Some designs let a payer close with an outdated total, relying on the recipient to challenge within a window, which means the recipient has to be watching.

A dispute window. Closing is typically not instant, because the counterparty is given time to contest with a more recent state. Funds are not immediately available at close.

A relationship. Opening a channel is a commitment to a specific counterparty. That is a poor fit for an agent buying one thing from a provider it will never use again, which is a substantial share of agent purchasing.

None of these are objections. They are the shape of the tradeoff, and they explain exactly which workloads channels suit.

When to use one

Use a channel where the same two parties transact repeatedly over a period, the individual amounts are small, and the volume is high enough that per-transaction fees would dominate. A sustained metered relationship with one provider is the canonical case: an agent consuming an API continuously for hours.

Use direct settlement where purchases are occasional, counterparties vary, or the relationship is one-off. Opening a channel to buy one thing is more overhead than the payment, and most agent purchasing across many providers is this shape.

Use a prepaid balance with the provider as the middle option people forget. It captures much of the benefit, a single settlement covering many charges, with far less machinery, at the cost of the provider holding your money and you trusting their accounting.

The honest summary is that channels are a specialised instrument, not a general upgrade. They matter enormously for sustained high-frequency relationships and are the wrong tool for the long tail.

Which is why direct settlement on a network with a low fee floor and fast finality covers the majority of agent payments without any of this complexity. That is the design CryptoCadet takes: USDC on Base, where fees are low enough that per-call charges work directly, with bounded delegation through session keys so authority stays capped either way.