​ERC-7811 is a wallet RPC standard that lets dApps query a connected wallet for its asset balances across all chains it tracks. Authored by Lukas Rosario (Coinbase Wallet), Christian Rosenkilde, and Wilson Cusack and submitted to the ERC-7811 GitHub spec, the standard defines a single RPC method, wallet_getAssets, that returns a structured list of token holdings keyed by chain ID.
​

Without ERC-7811, every dApp re-implements multi-chain balance fetching against block explorers, indexer APIs, or aggregators — duplicating work and producing inconsistent UX. With ERC-7811, the wallet is the source of truth: it knows which chains the user has activity on, which tokens they hold, and what balances apply.
​

ERC-7811 specifies one wallet RPC method: wallet_getAssets. The dApp calls the method with a request struct containing the user's account address, optional chain ID filters, and optional asset filters. The wallet returns a list of Asset objects, each with chain ID, address, type (native, ERC-20, ERC-721, ERC-1155), balance, and metadata.
​

The standard treats wallets as the canonical source for which chains the user has interacted with. A user with positions on Ethereum, Arbitrum, Base, and Polygon has those chains tracked in their wallet's internal state. Without ERC-7811, the dApp doesn't know to query those chains; with ERC-7811, the wallet returns the full list in one call.
​

The original ERC-7811 explainer covers the multi-chain UX motivation in depth. This article focuses on the RPC method shape, security boundaries, and adoption.
​

The RPC method takes a request and returns a response. The request shape:

The response is a list of Asset objects:

The wallet is responsible for the underlying RPC calls: it decides whether to read directly from chain RPCs, query its own indexer, or use a third-party balance API. The dApp gets a single uniform answer regardless of how the wallet sources it.
​

Multi-chain UX is one of the worst remaining UX problems in onchain apps. A user with USDC on Arbitrum and USDC on Base sees them as one balance in Coinbase Wallet but as two completely separate token entries in any dApp that doesn't track multi-chain state. The dApp typically asks the user to "switch chain" to see balances on each chain individually.
​

ERC-7811 cuts the fragmentation. A swap dApp using wallet_getAssets can detect that the user has 5,000 USDC on Arbitrum and 3,000 USDC on Base and offer to source the swap from either, or to bridge first. A treasury app can show the user's full position without asking which chains to track. A payment app can detect available balance on the chain that matches the recipient's preferred network.
​

Without the standard, every dApp built its own multi-chain balance system. Aggregators like Zerion, DeBank, and Zapper offered APIs that scraped chains, but the dApp had to integrate, pay rate limits, and handle stale data. With the standard, the wallet's own state is the answer.
​

ERC-7811 is in Draft as of April 2026. The current spec on GitHub reflects active discussion. Production wallet adoption is early but accelerating.
​

Coinbase's Smart Wallet (the team that authored the spec) ships wallet_getAssets. Coinbase Smart Wallet API docs describe the implementation. Apps integrating with Smart Wallet through the Smart Wallet SDK can call the method directly.
​

MetaMask, Phantom, Rabby, and other major wallets are reviewing the spec but have not shipped support as of April 2026. Each has its own multi-chain balance system internally; integration requires exposing that data through the standardized RPC method.
​

dApp adoption tracks wallet adoption. A dApp can call wallet_getAssets with feature detection: if the wallet returns the standard response, use it; otherwise fall back to chain-by-chain balance fetching. EIP-1193, the wallet provider standard, specifies the error code for unsupported methods, making feature detection clean.
​

The wallet returns balance data; the dApp does nothing privileged. Still, two boundaries matter.
​

First, privacy. wallet_getAssets tells the dApp every chain the user has activity on, every token they hold, and the amounts. This is more than the dApp would learn from a single eth_getBalance call on one chain. The wallet should treat wallet_getAssets as a permissioned method — typically gating it behind the same connection prompt as other wallet RPC methods.
​

Second, accuracy. The wallet may cache balance data and return stale values. The standard doesn't specify a freshness guarantee. dApps that need real-time balance for a transaction should still call eth_getBalance or balanceOf directly on the relevant chain at execution time; wallet_getAssets is for discovery, not for the execution path.
​

Before ERC-7811, dApps that needed multi-chain balance pulled from indexer APIs. The tradeoffs:

The indexer APIs solve the same problem but introduce dependency on a third party. ERC-7811 keeps the dependency in the wallet — which the dApp already trusts for transaction signing. For dApps that already use indexer APIs, ERC-7811 doesn't replace them entirely; the wallet's view may be narrower (only chains the user has touched). For new dApps, starting with ERC-7811 is simpler.
​

Stablecoin orchestration platforms benefit when wallets advertise multi-chain balances at the protocol level. Eco's orchestration network builds intent flows on top of user-chosen sources — a user signing an intent to "send 1,000 USDC to Base" should have the option to source from any chain where they hold USDC. ERC-7811 makes that source detection trivial: query the wallet, get the multi-chain USDC balance, present the user with route options. Read the essential ERC standards reference for how cross-chain standards compose with orchestration.
​

No. As of April 2026, ERC-7811 is in Draft status on the ethereum/ERCs repository. Coinbase Smart Wallet ships an implementation; major wallets like MetaMask and Phantom are reviewing the spec but have not shipped production support.
​

Whichever chains the wallet tracks. Coinbase Smart Wallet's implementation covers Ethereum, Base, Arbitrum, Optimism, Polygon, and other major EVM chains. The wallet decides scope; the standard does not specify a minimum chain set.
​

Yes. The asset type filter accepts "erc721" and "erc1155". Wallets that index NFT holdings can return them. Implementations may scope NFT responses to recently-active collections to keep response size manageable.
​

eth_getBalance returns the native token balance on one chain (the chain the wallet is currently connected to). wallet_getAssets returns balances across all chains the wallet tracks, plus ERC-20, ERC-721, and ERC-1155 holdings. It's a multi-chain, multi-asset version of balance discovery.
​

For wallet-connected dApps doing balance discovery, partly yes. For analytics, portfolio tracking, or apps without an active wallet connection, indexer APIs remain necessary. The wallet view is narrower than a full chain index; ERC-7811 covers the discovery use case, not full historical analytics.
​