One Approval Can Hide a Thousand Payments: What Agent Wallets Must Explain

An agent is about to make hundreds of small paid requests. Asking a human to approve each request would defeat the point of automation. Asking the human to approve everything once is faster—but it can also compress hundreds of later decisions into a single opaque signature.

That tension moved into the spotlight on 3 September, when Solana Foundation published a payment-channel design for high-frequency agent payments. The announcement leads with a striking benchmark: its open-source payment-channel proxy processed more than one million payments per second in testing.

Throughput is the headline. Permission design is the product problem.

If one approval can unlock a long sequence of later payments, the first approval must explain more than “Allow” or “Reject.” It must make the boundaries of that authority legible before the user signs.

What changed: from one payment to a spending session

In a conventional payment flow, each payment can involve a new transaction, a new wallet prompt and a new settlement. That may be acceptable for a single purchase. It becomes inefficient when an AI agent buys hundreds of small units of compute, data or API access in a loop.

Solana's payment-channel model separates the workflow into four parts:

1. Open: the user deposits a ceiling amount into onchain escrow.
2. Meter: the agent authorises usage with signed messages offchain.
3. Settle: the amount actually consumed is recorded onchain in one transaction.
4. Distribute: recipients are paid and unused funds return to the primary wallet.

This reduces repeated onchain work. It can also reduce the number of moments when a human is asked to review a decision.

That is not automatically a problem. Repetition is not the same as safety. Clicking “approve” 500 times would not create 500 informed decisions.

But removing those prompts makes the quality of the first decision much more important.

“Approve once” is not one decision

A spending allowance looks like a single number. In practice, it describes a bundle of permissions.

The user is deciding:

• Actor: which agent, application or contract receives authority?
• Asset: which token or balance can it use?
• Network: where does that authority apply?
• Limit: what is the maximum cumulative spend?
• Duration: when does the permission begin and expire?
• Purpose: what type of service or recipient is in scope?
• Settlement: when and how is actual usage recorded?
• Refund: what happens to the unused amount?
• Revocation: how can the user stop future spending?

If these fields are hidden, scattered or expressed only as raw contract data, the user is not approving a clear plan. They are approving an interpretation they cannot easily verify.

The signature may still be cryptographically valid. The consent may still be operationally unreadable.

Speed changes where trust must live

Fast infrastructure is valuable because it removes waiting. It does not remove uncertainty.

In fact, faster execution can shorten the period in which a user can notice a mistake and react. When hundreds of metered actions can occur after one approval, the wallet cannot rely on a final confirmation screen to explain each consequence.

Trust must move earlier in the journey.

The approval screen becomes a contract summary. The live session becomes a control surface. The settlement screen becomes an audit record.

Each stage has a different job:

• Before approval: explain the complete permission boundary.
• During the session: show cumulative usage, remaining allowance and active status.
• Before settlement: show the amount consumed, expected distribution and any unresolved condition.
• After settlement: show the final result, refund and revocation state.

Without those states, “autonomous” can become a euphemism for invisible.

What a clear approval should show

A useful wallet does not need to explain the entire protocol implementation. It needs to help the user answer practical questions.

1. Who can act?

Show a human-readable identity for the agent, application or contract. Displaying only a shortened address forces the user to trust the interface without understanding the counterparty.

2. What can it spend?

Name the asset and network. If several assets or routes are possible, the approval should not imply that the scope is narrower than it really is.

3. What is the maximum exposure?

The ceiling should be visually dominant. Users should not have to infer the cumulative maximum from a per-request estimate.

4. How long does the permission last?

“Until revoked” is materially different from “for this session” or “until 18:00 UTC.” Duration belongs beside the amount, not behind an advanced-details disclosure.

5. What remains variable?

The interface should separate fixed boundaries from estimated outcomes. A spending limit can be fixed while individual request costs, usage volume or settlement timing remain variable.

6. How can the user stop it?

Revocation should be visible before approval and accessible during the session. A permission is easier to understand when the exit is clear.

A live allowance should look like a meter, not a mystery

The bar-tab metaphor used in the Solana announcement is useful: set a cap, consume against it and settle when the session closes.

But a real bar tab is visible. You can ask what has been added. You know which venue holds the tab. You can stop ordering. You receive a final bill.

Agent payments need the same operational clarity.

A live permission view should show:

• authorised ceiling;
• consumed amount;
• remaining allowance;
• latest metered action;
• session expiry;
• settlement state; and
• revoke control.

This turns an invisible capability into an inspectable state.

Simulation helps, but it cannot explain an open-ended future

Transaction simulation can forecast the expected effect of the transaction being signed. It is useful evidence. It is not a safety certificate.

For a permission that enables later actions, simulation has an additional limit: it can inspect the opening transaction, but it cannot know every future request the agent will make.

That means wallets should distinguish:

• what the opening transaction is expected to do;
• what authority it grants;
• what later actions are allowed;
• what usage is currently observed; and
• what remains unknown.

The honest interface does not collapse these layers into one green checkmark.

The opportunity for self-custody wallets

Agentic payments create a familiar product temptation: remove every prompt and call the result seamless.

The better goal is not fewer decisions at any cost. It is fewer repetitive decisions and a clearer consequential decision.

At Biti.pro, our focus is clarity before signing: helping users understand the route, permission and expected consequence before the wallet prompt appears. We are applying that principle carefully as agent workflows make transaction authority more persistent and more complex.

This article does not claim that Biti.pro currently implements Solana payment channels. It identifies a design requirement the category will need to solve: an autonomous payment system should not require autonomous trust from the user.

A six-question checklist

Before approving repeated or delegated payments, ask:

1. Who can spend?
2. Which asset and network are in scope?
3. What is the maximum cumulative amount?
4. When does the permission expire?
5. How are usage and settlement shown?
6. How can I revoke it?

If the interface cannot answer those questions, the approval is not ready to be simple.

Payment channels may make machine payments dramatically faster. Wallets must make the human decision equally clear.

Biti.pro is building toward clearer self-custody decisions across EVM-to-Solana journeys. Join the waitlist. App and Chrome extension coming soon.