ERC-7930 is an Ethereum Improvement Proposal that defines a standard binary encoding for blockchain addresses that bundles the chain identifier alongside the account address itself, so a single address string unambiguously refers to a specific account on a specific network. The proposal was introduced in 2024 to solve a persistent UX problem: the same 20-byte hex address is valid on Ethereum, Base, Arbitrum, Optimism, and dozens of other EVM-compatible chains simultaneously, yet most wallets display it without any chain context, causing users to send funds to the correct address on the wrong chain.
​

By April 2026, the total stablecoin market has reached $318 billion (DeFiLlama, Q2 2026), with value flowing across Ethereum ($45B TVL), Base ($4.3B TVL), Arbitrum ($1.7B TVL), and other chains daily. At that scale, address ambiguity is no longer just a UX inconvenience; it is a structural risk for any application that routes funds across chains using human-readable or QR-coded addresses. ERC-7930 makes chain membership part of the address encoding at the data layer, not an afterthought in the UI.
​

ERC-7930 is a compact binary format for encoding blockchain addresses that includes the chain type, chain reference identifier, and account address in a single self-describing byte string. Any software reading an ERC-7930 address immediately knows which network it belongs to, without consulting external metadata. The standard targets wallets, payment SDKs, QR codes, and cross-chain identity systems.
​

The ERC-7930 specification defines a binary TLV (type-length-value) structure. Each address payload begins with a 2-byte magic prefix (0x23CE) that signals ERC-7930 encoding, followed by a 1-byte chain type field (distinguishing EVM chains, Solana, Bitcoin, and others), a variable-length chain reference (the numeric chain ID for EVM networks), and finally the raw account address bytes. The total overhead for a typical EVM address is 6-8 bytes on top of the 20-byte address, producing a compact identifier that can be base58- or bech32-encoded for human display and QR embedding.
​

The proposal emerged from a working group that also produced ERC-7828, the chain-specific ENS extension. Both address the same root problem from different angles: ERC-7930 handles the binary encoding layer for arbitrary address types, while ERC-7828 handles human-readable name resolution for ENS. They are complementary, not competing.
​

Before ERC-7930, developers working on cross-chain products either adopted CAIP-10 (a text-based addressing standard from the Chain Agnostic Improvement Proposals group) or rolled their own encoding, resulting in fragmented tooling and no shared parsing library. ERC-7930 brings the encoding into the Ethereum standards track, giving wallets a single implementation target. The ERC-7930 GitHub repository includes pseudocode for encode and decode functions that wallet implementers can adapt directly.
​

An ERC-7930 address encodes three data fields in sequence: a chain type byte identifying the blockchain family, a chain reference value identifying the specific network, and the address bytes for the account. The encoding is length-prefixed so parsers can read any field without knowing the full address length in advance, covering EVM 20-byte addresses, Solana 32-byte public keys, and Bitcoin addresses under a single spec.
​

The chain type field uses a registry of identifiers. EVM-compatible chains use chain type 0x01, and the chain reference is the decimal chain ID as a varint: Ethereum mainnet = 1, Base = 8453, Arbitrum One = 42161, Optimism = 10, BNB Chain = 56. Non-EVM chains are assigned distinct chain type values to prevent namespace collision. A Solana address uses chain type 0x04 and a chain reference corresponding to the Solana cluster (mainnet-beta = 1).
​

The full byte string is typically base58check-encoded for display, producing strings that look visually distinct from bare Ethereum hex addresses. A wallet can scan any ERC-7930 string, immediately call a parser to extract the three fields, display the chain name to the user, and route a transaction to the correct RPC endpoint, all without additional user input. This is the core mechanism that eliminates the "wrong network" send error.
​

Encoding and decoding libraries for the standard are being developed in TypeScript and Rust as part of the Ethereum ecosystem tooling effort. The reference pseudocode defines the varint encoding rules for chain IDs above 127, where a single byte is insufficient and multi-byte encoding applies. Wallet teams building ERC-7930 support should pay attention to the varint edge cases for high-value chain IDs like Base (8453, 2-byte varint) and Arbitrum One (42161, 3-byte varint).
​

CAIP-10 and ERC-7930 both encode a chain identifier alongside an account address, but differ in format and intended use layer. CAIP-10 is a text-based colon-delimited string (e.g., eip155:1:0xAbc...) designed for APIs and human-readable configuration. ERC-7930 is a compact binary encoding designed for QR codes and payment payloads where byte size and parse speed matter.
​

The table below summarizes the key differences across five dimensions.
​

In practice, the two standards are complementary. A wallet may use CAIP-10 internally when communicating with a WalletConnect session and ERC-7930 when generating a payment QR code for a user to scan. Applications that need to embed addresses in QR codes or compact URIs benefit from ERC-7930's binary efficiency; applications that expose addresses in JSON APIs or human-readable configuration files are better served by CAIP-10's plain-text format.
​

The CAIP-10 specification from the Chain Agnostic Standards Alliance documents the text format and namespace registry. Both specs share the design goal of making addresses self-describing, differing primarily in the transmission medium each optimizes for. A single application codebase may legitimately use both: CAIP-10 at the API layer and ERC-7930 at the QR/payment-URI layer.
​

ERC-7930 enables any software that generates, displays, or transmits blockchain addresses to embed chain context without a separate metadata field. The four primary use cases are wallet UX for multichain accounts, cross-chain identity systems, NFT provenance tracking across chains, and QR-code-based payments that carry the destination network in the scan itself.
​

A user holding ETH on Ethereum mainnet, USDC on Base, and SOL on Solana mainnet has three conceptually different "receive" addresses. Today, most wallets display the 20-byte hex address without chain context, asking the user to track which network they switched to. With ERC-7930, a wallet generates three distinct encoded strings, one per network, that a sending wallet can parse and validate before the user confirms the transaction. The MetaMask team has explored ERC-7930 integration as part of its multichain account roadmap, and Phantom's unified wallet experience for Solana and EVM chains represents exactly the class of problem ERC-7930 is designed to solve.
​

Identity protocols that map names to addresses (ENS, Lens, Farcaster) currently store a single address per resolver record, implicitly defaulting to Ethereum mainnet. An ERC-7930 identity record can store one encoded address per chain type, letting resolvers return the chain-specific address for the requesting network. This avoids the separate lookup step that today's cross-chain identity flows require and connects naturally to ERC-7828's chain-specific ENS resolution standard.
​

NFT metadata standards (ERC-721, ERC-1155) record the creator address without a chain field, because those standards predate widespread multichain deployment. An NFT minted by the same creator on Ethereum mainnet and Base has identical-looking addresses in its metadata but different chain contexts. ERC-7930 encoded provenance records let indexers and marketplaces like OpenSea and Zora resolve creator identity unambiguously across chains without chain-specific indexing workarounds.
​

Payment QR codes encode an address and an optional amount. Without chain context, a user scanning a QR code with a multichain wallet must confirm which network to send on. An ERC-7930-encoded QR eliminates that confirmation step: the wallet reads the chain type and chain reference from the payload and routes automatically. This matters in point-of-sale contexts where the merchant's network preference (e.g., USDC on Base at chain ID 8453) should be machine-readable, not manually selected by the customer. The ERC-681 payment URL standard is the closest prior art for QR-based payment encoding; ERC-7930 extends the address component of that URI scheme with explicit chain context.
​

ERC-7930 does not prevent the same 20-byte address from existing on multiple EVM chains. It makes the chain context explicit in any address string that conforming software produces, so receiving applications can warn users or refuse to complete a send when the encoded chain does not match the active network. Address reuse is an EVM property that ERC-7930 works around rather than eliminates.
​

The address-reuse problem is a direct consequence of how EVM chains derive addresses: an externally owned account (EOA) address is derived from the private key's public key using keccak256, with no chain-specific derivation step. Deploying the same private key on Ethereum, Base, Arbitrum, and Optimism produces identical-looking addresses on all four chains. Smart contract addresses are similarly predictable from deployer address and nonce (or CREATE2 salt), enabling intentional same-address deployments like Circle's USDC on Base (chain ID 8453) and USDC on Arbitrum One (chain ID 42161).
​

ERC-7930 addresses the confusion layer. When a wallet produces an ERC-7930-encoded receive address for a user's Base account, chain ID 8453 is embedded in the payload. A sending wallet that decodes the address before submitting the transaction can display "sending to Base (chain 8453)" and block the user from accidentally broadcasting to Ethereum mainnet. This is not enforced at the protocol level; it is a convention enforced by conforming wallet software. Non-conforming wallets that strip the encoding treat the payload as a bare hex address and lose the chain context entirely, which is why broad wallet adoption is necessary for ERC-7930 to eliminate the wrong-chain-send problem in practice.
​

For cross-chain products like Eco Routes, which orchestrates USDC and USDT flows across 15+ chains using Hyperlane and CCTP as settlement rails, explicit chain encoding in address payloads reduces the class of user errors that result in funds sent to the correct address on the wrong network. The stablecoin market's $318 billion size (DeFiLlama, Q2 2026) makes even a small reduction in this error class significant in dollar terms.
​

The ERC-7930 working group notes that the standard does not change HD wallet derivation paths; users retain the same private keys. The change is entirely at the address representation and application layers. Account abstraction wallets (ERC-4337 smart accounts) that deploy to deterministic CREATE2 addresses are the highest-risk segment for address-reuse confusion, since their addresses are intentionally identical across chains by construction. ERC-7930 encoded addresses for smart accounts are particularly valuable for these deployments, where a single counterfactual address exists on Base, Arbitrum, and Optimism simultaneously before any deployment transaction is confirmed.
​

No. CAIP-10 is a text-based colon-delimited format (eip155:1:0xAbc...) from the Chain Agnostic Standards Alliance, designed for API parameters and human-readable config. ERC-7930 is a compact binary format on the Ethereum standards track, designed for QR codes and payment payloads. They solve the same problem at different layers and can coexist in the same application.
​

Yes. The chain type registry in ERC-7930 includes non-EVM entries. Solana uses a distinct chain type byte and a 32-byte address field instead of 20 bytes. The binary TLV structure accommodates variable address lengths, so the same format covers both EVM and non-EVM addresses within a single encoding scheme.
​

ERC-7930 enables wallet software to detect and warn about chain mismatches, but it does not enforce this at the protocol level. A conforming wallet that decodes an ERC-7930 address before submitting a transaction can block sends to the wrong network. Non-conforming wallets will ignore the encoding. The standard's value depends on wallet adoption.
​

ERC-7930 handles the binary encoding of the address itself; ERC-7828 handles the human-readable ENS resolution layer. An ERC-7828 resolver resolves alice.eth@base to a Base-specific address, and that resolved address can be represented in ERC-7930 binary encoding for downstream use. The two standards are complementary and are being developed in parallel.
​

As of Q2 2026, ERC-7930 is in the Review stage of the Ethereum Improvement Proposal process. It is not yet a Final standard. Wallets and SDKs are beginning test implementations, but the specification may still change before finalization. Check the official EIP page for current status.
​

Sources and methodology. Chain TVL figures from DeFiLlama, April 29, 2026. Stablecoin market total from DeFiLlama, April 29, 2026. ERC-7930 specification details verified against the official EIP repository. CAIP-10 format verified against the Chain Agnostic Standards Alliance specification. Figures subject to change as the standard evolves.
​

By Eco research. Updated Apr 2026.
​