admin
An AI agent can plan several on-chain steps faster than a person can approve them, but the wallet must still define what its authorization covers. EIP-5792 introduces methods to submit wallet call batches and retrieve their status. This article develops test cases for partial execution and human review rather than treating batch submission as guaranteed atomic settlement.
Start with explicit capability discovery
An application that asks a wallet to batch token approvals and contract calls should first discover supported capabilities instead of assuming that every wallet behaves like a smart contract account. The EIP-5792 Wallet Call API, proposed in October 2022, defines wallet capability querying alongside methods for sending and tracking call batches. Build a matrix for supported, unsupported and optional capabilities, and test each with two wallet implementations. Never silently force a fallback that changes the transaction count or gas payer. The EIP-1193 provider API, created in June 2018, defines the request interface and relevant account and chain events; treat an account change as an invalidation of stale AI-generated approvals. The agent should present its intended on-chain actions in plain language before any signature. Capability discovery is a preparation step, not a grant of unlimited authority to act.
Separate a batch identifier from transaction finality
A batch request may return an identifier immediately even when execution remains pending. That identifier is not a blockchain receipt and does not prove all transfers succeeded. Represent each batch as proposed, user approved, submitted, observed on chain, confirmed or failed; attach separately recorded status to every component call. In a hypothetical workflow an agent submits three calls: revoke an old allowance, set a new scoped allowance, and deposit tokens. If the first settles but the deposit fails on a wallet implementation that splits operations, the user needs a precise account of what happened. The standard does not require every batch to be one atomic blockchain transaction. Build a status page that displays partial execution and offers a human-controlled recovery, avoiding a single green completed badge. Preserve chain IDs, expected contract addresses, amounts and semantic actions so support can reconstruct the outcome.
Verify user intent across the entire bundle
The agent should not convert broad language such as ‘rebalance my holdings’ into unknown wallet calls without a review surface. Show each destination contract, token, amount, approval scope, network and potential fee. Run a negative test where one address in a three-call plan changes after the user views it; the old confirmation must become invalid. Test cancellation before signature, cancellation after submission and a device disconnection in the middle. Distinguish the ability to cancel a local interface from reversal of an already accepted on-chain transaction. For safety, use test networks and disposable wallets for engineered failure cases rather than mainnet funds. If a dapp loses wallet connectivity, the agent should recover the actual chain state before presenting a new request. No language model estimate should replace receipt-based proof of executed state.
Design atomicity and fallback cases consciously
Batching lowers user friction but can hide failure ordering. For each supported wallet, ask whether transactions are aggregated atomically, submitted sequentially or merely tracked under one identifier. Create test fixtures in which the second operation intentionally reverts, gas runs out, the network changes and the user switches accounts. Assert expected balances and approvals at the end of each scenario. Test the specified fallback to individual transaction requests when batching is unavailable, and show the higher confirmation burden honestly. An important difference is whether later calls should proceed after an earlier failure. Do not let an AI agent automatically repair every revert by raising an allowance or gas limit without fresh authorization. Build a separate safe-retry matrix where no irreversible effects have been committed and where a new user decision is required.
Monitor expiry, status and duplicate intent
Delayed execution can create risk when token prices and destination addresses change. Tie the AI plan to a maximum age, a tolerance for changed balances and a monotonically increasing local intent identifier. The wallet specification contains an application-provided identifier mechanism for batch calls; store it separately from user-visible conversation identifiers. Repeated network requests must not trigger two independent batches for the same approved intent. When the wallet reports unknown status, query the authoritative transaction state rather than blindly resubmitting. Alert the person if the plan is stale or partially executed. Never store secret keys in agent prompts or analytics logs. Test accountChanged and chainChanged events in the provider, and verify that the UI invalidates cached contract and allowance data. An engineering success is no duplicate side effects across retries, not a perfectly smooth demo animation.
Publish a receipt-driven release checklist
Before deployment, record the supported wallet versions, networks, capability response shape, approval UX, batch status API, fallback behavior and negative test results. Include human-readable examples of pending, partial success and permanent failure. Require that every call’s outcome can be linked to a transaction or a documented wallet-level status, with private data removed from logs. Review smart-contract audit reports separately: a correct wallet RPC does not mean the target contract is secure. Track latency and failure distribution without turning a user-facing recommendation into an implicit financial guarantee. When a test network changes its rules, rerun the suite. AI-driven Web3 workflows should increase auditability as their planning gets faster. The user, not the conversational agent, retains authority for material transfers, contract approvals and unresolved failure recovery.
Sources
Original analysis and test scenarios; illustrative prices and volumes are not observed market statistics. Technical information is not financial advice.
