What Should a Wallet Show Before a Smart Account or AI Agent Can Act?

The familiar wallet prompt asks a narrow question: **Do you approve this transaction?**

That question assumes a person is present, a single action is ready and the authority ends when the transaction is signed.

Smart accounts and delegated execution change that model.

A user may approve a batch of actions. They may allow a dApp to act within a spending limit. They may authorise activity for a period of time. An AI agent may help find a quote, monitor status or prepare an action that still needs to be signed elsewhere.

The promise is compelling: fewer repetitive prompts, more flexible gas payment, batched actions and workflows that continue without forcing the user to supervise every technical step.

But the consent problem becomes larger.

**A transaction is a moment. A permission is a time window.**

If wallets make accounts more capable, they also need to make authority more understandable.

## Why this debate matters now

Several current developments point in the same direction.

[MetaMask](https://support.metamask.io/configure/accounts/what-is-a-smart-account/) now describes smart accounts as automatically enabled for new users. Its documentation highlights capabilities such as batching, sponsored or flexible gas payment and, as standards mature, scoped permissions that can reduce manual approvals. MetaMask also notes that not every possible smart-account feature is available yet—a useful distinction between present capability and future potential.

Ethereum's [ERC-7715](https://eips.ethereum.org/EIPS/eip-7715) proposes a method for a dApp to request execution permissions from a wallet. The proposal allows transactions to be executed on a user's behalf within a permission context. Its security guidance is direct: permissions should be limited in scope, have a reasonable expiry and be clearly displayed to the user.

Cross-chain infrastructure is moving in a similar direction. [LI.FI](https://docs.li.fi/agents/overview) now documents agent-oriented workflows for requesting quotes, checking transfer status and handling errors. Its MCP integration is deliberately read-only: it can return unsigned transaction requests, but signing and broadcasting remain external. That boundary is important because assistance and authority are not the same thing.

[Solana](https://solana.com/news/solana-changelog-august-20-2026) is also preparing a V1 transaction schema. The change is technical, but the product implication is broader: transaction formats can evolve underneath the interface. Wallet clients need to support the new format, yet users should not need to learn a new mental model every time the underlying representation changes.

These are different developments across different ecosystems. Together, they raise one product question:

> When a wallet, smart account, dApp or agent can do more on a user's behalf, what must remain visible before permission is granted?

## The next prompt may approve authority, not one action

Traditional transaction review is already difficult. A useful confirmation screen may need to explain the network, recipient, asset, amount, estimated fee and expected result.

A permission request adds new dimensions:

- who receives authority;
- which account and network it applies to;
- which actions are allowed;
- which assets and amounts are covered;
- when the permission begins and expires;
- whether the authority can be reused;
- how it can be reviewed or revoked later.

Compressing this into a generic **Allow** button would make the interface shorter, but the decision less readable.

The goal is not to show every implementation detail. It is to expose the boundaries that materially change the user's risk and control.

## Seven questions a wallet should answer

### 1. Who can act?

The interface should name the requesting application, account or agent in a way the user can verify.

A shortened address alone is weak context. A brand name alone can be spoofed. A stronger prompt connects the verified origin, the technical recipient of the permission and the account that will be affected.

The user should be able to answer: **Who am I trusting with this authority?**

### 2. Which account and network are in scope?

Smart-account capabilities can be network-specific. A permission on Ethereum does not automatically describe what will happen on Base, Arbitrum or another network.

The prompt should identify the account, network and relevant execution environment. If the same interface supports several networks, it should not hide the selected one behind a default.

The user should be able to answer: **Where can this permission be used?**

### 3. What actions are allowed?

“Access your wallet” is not a useful description.

Can the requester only prepare quotes? Can it submit a swap? Can it transfer a token? Can it call any contract? Can it batch several actions together?

The permission should be described in terms of consequences, not only method names. Technical detail can remain available for inspection, but the primary explanation should say what the authorised party can actually cause.

The user should be able to answer: **What can happen without asking me again?**

### 4. What are the asset and amount limits?

Scope is not complete without a boundary.

A permission may apply to one token, several assets or native currency. It may allow a fixed amount, a recurring allowance or an adjustable limit.

The interface should make the maximum exposure legible. “Unlimited” is not merely a technical value; it is a decision with a different consequence from approving a specific amount.

The user should be able to answer: **How much authority am I granting?**

### 5. How long does it last?

A signing deadline and a permission expiry are not the same thing.

The first tells the user when a request must be approved. The second tells them how long the resulting authority remains usable.

The wallet should show the start, expiry and whether the permission can be renewed. Human-readable dates are more useful than raw timestamps, but the exact value should remain inspectable.

The user should be able to answer: **When does this authority stop?**

### 6. What evidence is available before execution?

Some workflows can present a specific action for review. Others grant authority before the exact future transaction is known.

That difference should be explicit.

If a transaction can be simulated, the wallet should label the result as a forecast rather than a guarantee. If only a policy or range is known, the prompt should say which details are fixed, estimated or unavailable.

The user should be able to answer: **What do I know now, and what will only be known later?**

### 7. How can I pause, revoke or recover?

Permission management should not disappear after setup.

Users need a durable place to see active permissions, their scope, recent use and expiry. Revocation should be easy to find, and the interface should explain whether revoking requires an onchain transaction or fee.

If an execution fails or partially completes, the product should show what happened, whether the authority remains active and what action is safe next.

The user should be able to answer: **How do I take control back?**

## Fewer prompts can be better

This is not an argument for adding confirmation screens to every step.

Repeated prompts create fatigue. Users learn to click through them. Batching and scoped permissions can make onchain products easier to use while reducing redundant signatures.

The better trade-off is:

1. explain the authority clearly once;
2. limit it to the intended purpose;
3. keep its active state visible;
4. interrupt only when the action exceeds the agreed boundary;
5. make review and revocation easy.

Good abstraction removes operational work. It should not remove informed consent.

## Assistance is not authority

Agent-assisted crypto workflows make this distinction especially important.

An agent can help discover routes, compare quotes, monitor status or prepare an unsigned request without possessing the ability to move funds. LI.FI's read-only MCP design is a concrete example of that boundary: the tool can retrieve information, while signing remains external.

If an agent later receives execution permission, the interface should make that escalation visible. Moving from **help me understand** to **act for me** is not a minor settings change. It is a transfer of authority.

Products should name that transition instead of hiding it behind the language of convenience.

## A stable mental model across changing transaction formats

Underlying transaction formats will continue to evolve. Account abstraction, delegation standards, solvers and new chain-specific formats can make execution more capable.

The user-facing model can remain stable:

- **Intent:** What am I trying to achieve?
- **Authority:** Who can act, and within which limits?
- **Evidence:** [What is known, estimated or unknown?](https://biti.pro/blog/why-wallet-balance-not-enough-to-send)
- **Execution:** What is happening now?
- **Recovery:** [How do I stop, retry or revoke?](https://biti.pro/blog/how-to-read-a-block-explorer-after-sending-crypto)

This is the interface contract that should survive technical change.

## Where Biti.pro fits

Biti.pro is being built around [clarity before signing](https://biti.pro/blog/what-should-a-cross-chain-wallet-show-before-you-sign) for self-custody experiences. The product is pre-launch, and this article is not a claim that smart-account delegation or agent execution is currently supported.

The broader product principle is the relevant part: greater capability should increase explanation, not mystery.

Whether the user is reviewing one transfer, a batch, a cross-chain route or a future permission, the decision should make the consequence and boundary difficult to misunderstand.

## The next wallet prompt

The next generation of wallet UX will not be judged only by how many clicks it removes.

It will be judged by whether users can understand the authority they keep, the authority they grant and the path to take it back.

Before a smart account, dApp or agent can act, a wallet should answer seven questions:

1. Who can act?
2. Which account and network are in scope?
3. What actions are allowed?
4. Which assets and limits apply?
5. How long does the permission last?
6. What is known before execution?
7. How can the user pause, revoke or recover?

Fewer clicks can be better.

But when one click grants a time window of authority, that click deserves more explanation—not less.

---

## Sources

- MetaMask Help Center — What is a smart account: https://support.metamask.io/configure/accounts/what-is-a-smart-account/
- MetaMask Help Center — Switch to or revert from a smart account: https://support.metamask.io/configure/accounts/switch-to-or-revert-from-a-smart-account/
- ERC-7715 — Request Permissions from Wallets: https://eips.ethereum.org/EIPS/eip-7715
- EIP-7702 — Set Code for EOAs: https://eips.ethereum.org/EIPS/eip-7702
- LI.FI Docs — Agent Integration: https://docs.li.fi/agents/overview
- LI.FI Docs — MCP Server Overview: https://docs.li.fi/mcp-server/overview
- Solana Changelog — August 20, 2026: https://solana.com/news/solana-changelog-august-20-2026