ERC-7811 is a draft Ethereum standard that adds one new JSON-RPC method, wallet_getAssets, so an app can ask a wallet for the user's full asset list across chains in a single call. The proposal was opened on November 7, 2024 by Luka Isailovic, Konrad Kopp, Derek Rein, and Chris Smith, and remains in Draft status as of April 2026. It depends on EIP-5792 (Wallet Call API), expects four optional filters, and explicitly allows wallets to surface assets that are not readable from onchain data alone. This article walks through what the standard says, how the RPC actually works, which wallets and SDKs have shipped support, where it sits inside the broader chain-abstraction stack, and what limitations remain open in the Magicians thread.
​

ERC-7811 standardizes a single JSON-RPC method on the wallet side. An app calls wallet_getAssets with an account address and up to three optional filters, and the wallet replies with a record keyed by chain ID, where each value is an array of assets the wallet knows the account holds. Each asset record carries an address (or the literal string "native"), a hex-encoded balance, a type classifier, and an optional metadata blob. The defined types are native, erc20, and erc721, with the spec leaving room for future ERCs to register additional kinds.
​

The proposal's stated motivation is concise. Apps today rely on onchain data to determine balances, and that limits what an app can offer the user. The wallet often knows more than any single chain RPC node does. It may hold custodial balances, sub-account balances, or cross-chain positions that no individual chain exposes through eth_getBalance. ERC-7811 lets the wallet report all of that in one place.
​

One subtle point gets lost in summaries: ERC-7811 is not an indexer specification. It does not tell the wallet how to discover or cache balances. It defines only the shape of the request and the response. A wallet that uses an external indexer behind wallet_getAssets is compliant; a wallet that maintains its own balance ledger is also compliant. The standard is about the interface between app and wallet, which is why it composes cleanly with the existing capability-discovery handshake in EIP-5792.
​

The companion explainer on ERC-7683 cross-chain intents covers the order side of the chain-abstraction stack. ERC-7811 covers the read side. The two are designed to be used together, not as alternatives.
​

The request takes one required parameter and three optional filters:

The spec is explicit that consumers SHOULD set these filters as narrowly as the use case allows. An app that only needs the user's USDC balance on Base should send assetFilter: { 8453: [{ address: "0x833...", type: "erc20" }] }, not an empty filter that asks the wallet to enumerate everything. The motivation is operational: under loose filters, the wallet's backend may have to fan out to many indexers, and the response payload can grow without bound.
​

The capability handshake is the other half of the design. Before calling wallet_getAssets, an app calls wallet_getCapabilities from EIP-5792 and looks for the assetDiscovery key. If the key is present, the wallet supports 7811 and the app proceeds; if it is absent, the app falls back to direct chain queries. This pattern is consistent with how 5792 handles batched calls and paymaster discovery, so apps never blindly invoke a method the wallet might not implement.
​

The response shape is a record keyed by chain ID. Calling with no filters might return:

Within each array, the wallet provides one entry per asset, each with the four fields above. The standard does not mandate ordering, deduplication strategy, or handling of zero balances; those are wallet-side decisions. The viem implementation in the next section adds an aggregated key 0 that rolls assets up across chains, but that aggregation is a client-library convenience, not a spec requirement.
​

Asset discovery has been a known gap since the multi-chain era began in earnest around 2021. Three patterns dominate the existing solutions, and each has a real defect.
​

The first pattern is direct chain RPC. An app picks a chain, queries the user's balance through standard methods like eth_getBalance or token-contract balanceOf, and shows what comes back. This is correct for the chain it asked about. It is silent about every other chain, and it has no way to surface custodial holdings the wallet may know about.
​

The second pattern is third-party indexers. Alchemy, Moralis, Covalent, QuickNode and similar services aggregate balance data across chains and expose REST or GraphQL APIs. This solves the multi-chain visibility problem at the cost of an external dependency. The indexer sees what the chain publishes; it does not see anything the wallet maintains internally. And every app integrates a different vendor with a different schema, which makes wallet-side privacy controls effectively impossible.
​

The third pattern is wallet-specific RPCs. MetaMask exposes its own helpers, Phantom exposes its own helpers, embedded-wallet SDKs expose their own helpers. Apps end up writing N adapters for N wallets. This is the situation ERC-7811 is trying to terminate. EIP-2256 attempted a similar fix in 2019 with wallet_getOwnedAssets, but stalled before reaching adoption; ERC-7811 is the second attempt.
​

What is genuinely new in 7811 is the explicit allowance for off-chain balances. The spec language calls out that wallets MAY return assets not readable from onchain data: a custodian-held position, a centralized-exchange sub-account a wallet aggregator has linked, or a pending settlement the wallet's backend has booked but not yet finalized onchain. An indexer cannot see those by definition. A wallet can. The standard is the place where that gap closes.
​

Adoption in April 2026 is concentrated in chain-abstraction tooling rather than in mainstream consumer wallets. The pattern is that infrastructure providers ship 7811 first, then chain-abstraction apps consume it, and the consumer wallets follow once the spec stabilizes.
​

Table 1. Public ERC-7811 adoption as of April 2026. Chain-abstraction infrastructure has shipped; mainstream consumer wallets have not made public commitments to a release timeline.
​

Reown, the rebrand of WalletConnect, was the first major implementer. The Reown UX Roundup #4, published February 25, 2025, announced that the Chain & Stablecoin Abstraction demo at ca-demo.reown.com supports ERC-7811, with a video from February 12, 2025 showing a USDC transfer arriving on Base from a wallet that only held USDT on Optimism. The demo combines 7811 (read what the user holds anywhere) with a routing layer (move the right asset to the right chain). Reown's WalletKit SDK is the consumer-facing distribution channel, so apps integrating WalletKit get 7811 support without writing custom code per wallet.
​

Openfort, an embedded-wallet provider used in game and consumer-app stacks, shipped ERC-7811 support on November 11, 2025. Their write-up emphasizes the off-chain affordance: apps using an Openfort embedded wallet get a wallet-sourced view of balances without needing to choose an indexer.
​

The viem TypeScript library exposes walletClient.getAssets() in its experimental ERC-7811 module. The function signature accepts account, assets, assetTypes, and chainIds, the same four parameters as the underlying RPC, with parameter names slightly more idiomatic for JavaScript callers. The "experimental" namespace signals that the API is shipped to developers but not yet stable; this matches the spec's Draft status.
​

Public commitments from MetaMask, Coinbase Wallet, Phantom, Rabby, and Frame are absent from changelogs and release notes through April 2026. The pattern is consistent with how this category historically rolls out: infrastructure ships first, the apps that depend on it ship second, and the consumer wallets ship last once the integration burden is justified by app demand. ERC-7811 is roughly at the second-stage point of that curve.
​

The chain-abstraction stack splits cleanly into a read side and a write side. ERC-7811 is the read side: given an account, what does the user hold across chains? ERC-7683 is the write side: given an outcome the user wants, what is the structured cross-chain order, and which settlement filler can deliver it? Together they define a clean two-step app pattern.
​

The read step is one call. The app uses 7811 to read the user's distributed balance: $400 USDC on Optimism, $250 USDC on Arbitrum, $0 USDC on Base. The order step structures a 7683 CrossChainOrder that specifies the user wants USDC on Base, with source allowed from any chain the user holds. The settle step routes that order through a filler network. Across Protocol, Eco Routes, or another settlement layer fills the order against its own liquidity, with reimbursement handled by the protocol's settlement contracts.
​

EIP-5792's batching primitives connect to both. wallet_sendCalls from 5792 lets a wallet bundle approval and order submission into a single transaction, which removes the dual-popup pattern that characterizes most cross-chain UX today. ERC-7811's wallet_getCapabilities handshake is the same handshake that gates 5792 batched calls, so an app discovers both capabilities in the same JSON response.
​

Account abstraction layers on top. An ERC-4337 smart account or an EIP-7702-delegated EOA can hold balances on multiple chains and authorize a 7683 order without needing a per-chain key derivation. Particle Network's Universal Accounts and OneBalance's Credible Accounts are early examples of this combined pattern in production: one account, many chains, one app-side balance read.
​

The Magicians thread for ERC-7811 was opened on November 9, 2024 and remained active through August 2025. Five contributors, lukaisailovic, SamWilsn, montycheese, ajhodges, and kdenhartog, drove the discussion. Three concerns have produced concrete spec changes or are still open as of April 2026.
​

Filter naming. The original draft called the asset filter requiredAssets and paired it with a SHOULD-respect requirement. SamWilsn raised in December 2024 that "required" implied MUST semantics while the spec only required SHOULD. The field was renamed to assetFilter, which removed the contradiction.
​

Pagination. ajhodges flagged in January 2025 that under loose filters, a power-user wallet with hundreds of NFTs across 80+ chains could exceed any reasonable RPC payload size. The current draft acknowledges the issue but does not yet require pagination. Apps shipping 7811 today should expect partial results when their filters are loose, and they should narrow filters when they detect truncation.
​

Privacy and fingerprinting. kdenhartog raised on August 5, 2025 that the response payload exposes a fingerprintable balance signature. A returning user querying an arbitrary app reveals which chains they use, which assets they hold, and at what scale. The proposed mitigation is user-side selection: the wallet asks the user which assets to share before responding, similar to how account-permission prompts work today. This concern is open as of April 2026 and spec text has not landed.
​

A fourth issue, collection-level NFT aggregation, was raised but is more cosmetic. The current spec returns NFTs at the token level; consumers asked whether the wallet should aggregate by collection. The decision was to leave aggregation to the consumer.
​

Stablecoin apps are the cleanest fit for ERC-7811. A stablecoin user typically holds the same asset across multiple chains: USDC on Ethereum for custody, on Solana for speed, on Arbitrum for DeFi, on Base for retail. An app that wants to route a payment, trigger a swap, or rebalance a treasury needs to know which chains hold a positive balance before it can plan an action. Without 7811 the app has to either ask the user, query an indexer, or skip optimization and bridge from a default chain. Each of those costs a click, a vendor dependency, or a bad route.
​

With 7811 the app reads the wallet directly, picks the cheapest source chain, and constructs an order. The order itself is where the settlement layer takes over. Eco Routes is the settlement layer for stablecoin movement specifically. Apps express the outcome (deliver USDC to address X on chain Y, source from any chain the user holds) and Eco Routes handles solver selection, finality, and atomicity across 15 supported chains. The pairing is direct: the wallet's 7811 response tells the app what is available; the routing protocol moves it.
​

This is the structural reason chain-abstraction infrastructure shipped 7811 first. Reown built the demo because it had a routing layer that needed a balance feed. Openfort built support because its embedded-wallet customers asked for cross-chain balance views. The standard is most useful at the seam between wallet and router, which is exactly where chain-abstraction products live.
​

Eco Routes is the cross-chain stablecoin execution layer that consumes a 7811-style asset-discovery view and turns it into atomic movement. An app integrating both standards reads the user's distributed USDC balance through wallet_getAssets, identifies the cheapest source chain, and submits a routing intent through Eco Routes' SDK. The router sources liquidity from any of 15 supported chains, including Ethereum, Solana, Arbitrum, Base, Optimism, Polygon, and HyperEVM, and either delivers the outcome end-to-end or reverts atomically. The full pattern is documented in the ERC-7683 explainer and the broader ERC-7811 sibling article. ERC-7811 closes the read gap; Eco Routes closes the write gap. The two together remove the chain-by-chain bookkeeping that has constrained stablecoin app design since multi-chain became the norm.
​

ERC-7811 is a draft Ethereum standard that adds a single JSON-RPC method, wallet_getAssets, so an app can ask a wallet for the user's complete cross-chain asset list, including balances the wallet may know about but the chain does not expose, in one call.
​

An indexer can only see what is published onchain. ERC-7811 lets the wallet return assets it knows about from any source, including custodial balances or sub-accounts that no chain RPC exposes. The wallet is the source of truth; the indexer is a derivative.
​

As of April 2026, public support has shipped in Reown's WalletKit and Chain & Stablecoin Abstraction demo (Feb 25, 2025), Openfort's embedded-wallet stack (Nov 11, 2025), and the experimental module in viem. Mainstream consumer wallets, including MetaMask, Coinbase Wallet, Phantom, Rabby, and Frame, have not made public 7811 commitments.
​

Yes. ERC-7811 is the read side of the chain-abstraction stack and ERC-7683 is the write side. An app reads the user's distributed balance through wallet_getAssets, then structures a 7683 CrossChainOrder that a settlement layer like Eco Routes or Across executes.
​

EIP-5792 defines wallet_getCapabilities, the handshake that lets an app discover what an arbitrary wallet supports before invoking it. ERC-7811 registers an assetDiscovery capability key under that handshake, so apps can fall back gracefully when the wallet has not implemented 7811.
​