Ethereum coins representing multiple wallet-provider discovery

AI-agent dashboards often show a single Connect Wallet button even when a browser contains multiple extensions. This engineering checklist distinguishes wallet discovery from consent, signing authority and execution. The recommendations are derived from the EIP-6963 provider-discovery specification and EIP-1193 provider API; no smart-contract audit or wallet certification is implied.

The multiple-wallet failure mode is a product risk

A Web3 dashboard with an AI agent may guide a user toward payments, approvals or contract calls. If the interface assumes one globally injected wallet, a browser with multiple wallet extensions can create confusing provider precedence. EIP-6963 was proposed to support discovery of multiple injected providers through events, rather than depending on a single mutable window.ethereum object. This does not authorize an agent to transact; it solves the discovery layer. The user still needs to identify a wallet, connect an appropriate account and inspect each consequential operation. A product specification should explicitly distinguish discovered, selected, connected and transaction-approved states. Showing a provider’s logo or name at discovery time is not evidence of ownership or legitimacy. The risk is especially material for AI agents because conversational interfaces can obscure which account an instruction will actually affect. The wallet selection step therefore belongs in the visible, reviewable transaction path, not hidden behind an automatic first-provider choice.

Use EIP-6963 events without implicit selection

The standard describes provider announcement and discovery events designed for websites that may encounter more than one injected extension. An application should register listeners early enough to receive announcements, request fresh announcements when appropriate and keep a stable list keyed by a unique provider identifier. Render choices to the user with accessible names, and allow selection changes without reloading a financial workflow. A discovered provider can disappear or change capability during the session; treat discovery data as a starting point, not durable authorization. The UI should not initiate eth_requestAccounts or a signing request for every announced provider. Instead, wait for an explicit action on the chosen wallet. To test this, install two browser wallet extensions in a controlled environment, vary their startup order, reload the page and confirm that no silent connection or signature request occurs. EIP-6963 improves selection semantics but cannot replace a clear transaction-confirmation screen.

Pair discovery with EIP-1193 connection semantics

EIP-1193 specifies the Ethereum provider interface, including the request method and events such as accountsChanged and chainChanged. Its distinction between provider connectivity and account exposure is crucial. A wallet can connect to an Ethereum chain while the user has not granted the site access to an address. After choosing a provider, request only the account access needed for the pending task; validate the chain separately. Subscribe to chainChanged and accountsChanged and immediately invalidate any unsigned operation preview whose assumptions no longer match. If a user switches account midconversation, the AI agent must not silently reuse the previous account’s spending limit or destination list. Where a wallet reports unsupported methods or a chain disconnection, show a recoverable error instead of endlessly retrying. These rules follow the EIP-1193 event model and provide a defensible boundary between a natural-language request and actual on-chain authority.

Threat-model spoofed providers and visual trust

Provider metadata may include identifying information useful for a selection modal, but an untrusted webpage or compromised extension environment can influence JavaScript objects. EIP-1193’s security considerations recommend treating provider objects as potentially adversarial and protecting private data and authorization outside those objects. For an AI-agent dashboard, do not assume that a recognizable icon equals a certified wallet. Explain what chain is selected, show the currently connected account and avoid exposing additional addresses before user consent. The application’s security review should include fake provider names, duplicate provider identifiers, misleading icons, a provider that changes chains after a quote and a disconnected provider that resolves an old promise late. Keep the provider reference in transaction state so another injected extension cannot accidentally receive the wrong instruction. Review all outputs and errors from wallet APIs as untrusted input; never pass them verbatim into a high-privilege AI planning context.

Design a transaction handoff state machine

A practical state machine is DISCOVERED, SELECTED, ACCESS_REQUESTED, CONNECTED, CHAIN_VERIFIED, TRANSACTION_PREVIEWED, WALLET_CONFIRMATION and FINALIZED. Require a user-visible confirmation before entering the wallet-confirmation phase. Each transition should include a time, selected provider identifier, chain ID and account fingerprint, with unnecessary personal data redacted from logs. If the wallet changes account or chain, return to the relevant earlier state and rebuild the preview. If the user denies an access request, preserve a nontransactional chat experience rather than treating denial as a system failure. For batch operations, count distinct destination contracts, tokens and maximum value in the preview. A conversational summary alone is not sufficient because a model can omit details; the underlying call parameters must be rendered in deterministic UI. An operation should be aborted if the selected provider unexpectedly differs from the one that generated the quote.

Measure safety with six deterministic acceptance tests

Test two providers launching in different orders; a provider arriving after first render; a user changing the chosen provider; an accountsChanged event during AI planning; a chainChanged event before signing; and a provider returning an error after a request is cancelled. For each test, record the observed state, selected account, chain and whether any signing prompt appeared without explicit authorization. The invariant is that discovery never equals consent and a preview is invalidated whenever its signing context changes. Add telemetry for provider-discovery failures and task recoveries, but do not treat successful connection as a business conversion or a safe transaction. An AI-agent wallet integration should be optimized for informed user control. EIP-6963 provides a better provider-discovery mechanism, while EIP-1193 supplies the lifecycle events needed to keep that control technically coherent.

Sources

Featured photo: Traxer / Unsplash.