Transaction Simulation vs Spending Permissions: What Actually Limits an Onchain AI Agent?

An onchain AI agent can research a route, prepare a swap and submit a transaction without asking the user to click through every step.

That sounds like a better interface. It also changes the signing problem.

When a person approves one transaction, the wallet can preview one request. When an agent receives delegated authority, the user is deciding what the agent may do later, how often, with which assets, for how long and under which limits.

Two controls are often discussed as if they solve the same problem:

Transaction simulation forecasts what a proposed action is likely to do.
Spending permissions constrain what an account or agent is allowed to do.

Both matter. They are not substitutes.

A simulation without enforceable limits can describe an action accurately while leaving the agent with too much authority. A permission without a readable preview can enforce a boundary the user never properly understood.

The stronger design uses prediction and policy together.

The market is moving from clicks to delegated execution

Recent wallet infrastructure is making delegated execution more practical.

On 27 August 2026, MetaMask published case studies about AI agents using its Smart Accounts Kit and Delegation Framework. The examples focus on agents that can perform onchain actions without receiving the user's private key, while operating inside restrictions attached to delegated authority.

That shift matters because the unit of consent changes. In a traditional wallet flow, the user sees a request and signs it. In a delegated flow, the user may sign a permission that authorises several future actions. The interface therefore has to explain both the immediate effect and the future authority being created.

This is not only an AI-agent issue. Auto-revoking approvals, recurring payments, session keys and smart-account automation raise the same question: what may act on my behalf, and what prevents it from doing more than I intended?

What transaction simulation answers

Transaction simulation runs a request against a selected view of network state without broadcasting the real transaction.

Go-ethereum's eth_simulateV1 documentation describes simulation of blocks and transactions without creating them onchain. Its configuration also shows why a result needs context: validation can be enabled or disabled, state can be overridden, and the outcome depends on the block state used for the run.

A useful simulation may reveal predicted balance changes, token transfers, approval changes, contract calls, likely success or revert and estimated resource use.

This evidence answers: if this request executes against these conditions, what is likely to happen?

That is valuable. It is still a forecast.

The result can become stale as balances, liquidity, nonces, gas conditions or contract state change. A successful preview cannot infer whether the destination is the one the user intended. It also cannot guarantee downstream cross-chain settlement after the source transaction succeeds.

Trust Wallet made this boundary unusually explicit in its Security Scanner explanation published on 13 August and updated on 14 August 2026: its scanner simulates effects, screens destinations and warns about risky approvals, but the result is a prompt to inspect more closely rather than a guarantee.

Simulation is evidence, not authority.

What spending permissions answer

A spending permission defines what another account, application or agent is allowed to execute on the user's behalf.

ERC-7715 specifies a way for applications to request permissions from wallets. The standard does not prescribe one enforcement system; it allows the wallet to return a permission context that different schemes can use.

MetaMask's Delegation Framework provides one current example. Its documentation describes scopes and caveats that can restrict delegated authority. A scope defines the broad action category. Caveats narrow it with conditions such as amount or time limits.

A useful permission may answer which agent can act, which asset it may use, the maximum amount it may spend, which contract or function it may call, how often it may act, when the permission expires, whether authority can be redelegated and how it can be revoked.

This answers a different question: even if the agent proposes another action later, what is it technically allowed to do?

That is policy, not prediction.

A forecast does not constrain authority

Imagine an agent simulates a 50 USDC swap. The preview shows the expected balance change, contract call and estimated fee. The simulation succeeds.

But the permission behind the agent allows it to spend up to 5,000 USDC for the next 30 days across any contract.

The simulated transaction may be accurate. The delegated authority is still far broader than the action the user thinks they approved.

Before the user delegates, the wallet should show the immediate action, future authority, maximum exposure, duration and revocation path. One green result cannot communicate all five.

A permission does not explain intent

Now reverse the problem.

An agent receives permission to spend no more than 50 USDC on one approved contract before the end of the day. Those limits are narrow and enforceable.

The current transaction sends the 50 USDC to a function the user did not expect.

The permission system may allow it because the call remains inside the authorised scope. The user still needs readable transaction context to judge whether this specific action matches their intention.

ERC-7730 addresses this broader clear-signing problem by defining structured context for displaying transaction data in a form people can verify. Human-readable action names, amounts, addresses and meanings remain necessary even when the underlying permission is constrained.

The wallet needs to answer both: is this action inside the rule, and is this the action the user meant to authorise?

Four layers a wallet should keep separate

A strong pre-sign interface can organise the decision into four layers.

Decoded: what the request says, including action, account, network, recipient, asset, amount and requested permission. Decoded information explains the request. It does not predict the result or enforce a boundary.

Simulated: what the preview observed, including predicted balance changes, approval or contract effects, likely success or revert, estimated resource use and a timestamp or block reference. Simulated information is conditional evidence.

Enforced: what the permission system will reject if exceeded, including maximum spend, allowed assets, permitted contracts or functions, frequency, expiry and redelegation boundary. Enforced information defines the available authority.

Unknown: what neither layer can responsibly promise, including future network state, final gas paid, quote movement, external service availability, downstream cross-chain settlement and whether a technically valid action matches an unstated human intention.

Unknown is not a defect. Hiding it is.

The cross-chain version is harder

An agent moving value from an EVM network toward Solana may coordinate approval, source execution, routing, settlement and a destination action.

A source-chain simulation can forecast the immediate call. A spending permission can constrain what the agent may spend on the source account. Neither, by itself, guarantees the complete journey.

Before authority is granted, the user should see the source and destination networks, intended route, total estimated cost, minimum received, estimated completion time, exact permission, expiry, revocation path and which downstream outcomes remain uncertain.

After execution begins, the interface should keep source submission, routing, destination settlement and recovery states distinct.

Constrain the authority, preview the current action and keep the journey visible.

Where Biti.pro fits

Biti.pro is being built around clarity before signing for self-custody users moving from EVM networks toward Solana.

The product is still pre-launch. Biti.pro does not currently claim support for AI agents, ERC-7715 permissions or delegated smart-account execution.

The relevant product principle is narrower: simulation should forecast expected effects before the request reaches the signer, while the interface explains the route, estimated fees, minimum received and estimated completion time.

As delegated execution becomes more common, that clarity standard needs to expand from one transaction to the authority behind it.

The user should be able to see what is requested now, what is predicted to happen, what authority remains afterward, which conditions are enforceable and what is still unknown.

Prediction plus policy

The discussion around agent wallets often starts with key custody: can the agent act without holding the user's private key?

That boundary matters. It is not the complete decision.

An agent that does not hold the key can still receive authority that is too broad. A permission that is technically narrow can still be presented in a way the user cannot understand. A successful simulation can still forecast an unwanted action.

The useful model is simple:

Simulation predicts. Permissions constrain. Clear signing connects both to human intent.

Before delegating authority, ask:

1. What is the agent proposing now?
2. What did the simulation observe?
3. What is the agent allowed to do later?
4. Which limits are enforced?
5. When and how can the permission be revoked?
6. What remains unknown across the route?

Automation becomes easier to trust when its authority is smaller than its ambition—and visible before the signature.