ERC-7930 Interoperable Addresses: How Chain-Aware Addressing Works

One 0x address can appear valid on Ethereum, Base, Optimism, and many other EVM networks. The characters tell you the account, but not the intended chain. ERC-7930 interoperable addresses attach those two pieces of context so software can carry them as one value. It is a practical addition to blockchain infrastructure, but it cannot verify who controls an address or make a transfer reversible.

This guide explains the binary format, the human-readable ERC-7828 companion, where developers may use them, and the checks users still need. It describes standards under review, not an investment strategy.

What Problem Does ERC-7930 Solve?

A conventional Ethereum address identifies 20 bytes. It does not say whether an application intends Ethereum mainnet, an L2, a testnet, or another EVM-compatible chain. That ambiguity becomes more important when wallets, bridges, and intent systems operate across networks.

Think of a street address printed without a country. Local delivery may work because everyone shares an assumption. Once the parcel crosses borders, the same text is incomplete. ERC-7930 puts the destination account and its network into one machine-readable envelope.

The official ERC-7930 specification says the format is designed to:

• bind a chain identifier to the raw target address;
• remain compact enough for smart contracts, messages, and intent payloads;
• support non-EVM chains through namespace-specific profiles; and
• evolve through an explicit version field.

This matters beyond display. The Ethereum Foundation's 2026 protocol priorities identify interoperability as a high-leverage UX focus and cite ERC-7930 with ERC-7828 among standards that moved forward. A common address object gives wallets and cross-chain systems less room to invent incompatible chain + address conventions.

How the Binary Envelope Works

Version 1 is a length-prefixed byte sequence with six fields:

Length prefixes work like labeled compartments in a shipping crate. A parser knows where one variable-length component ends and the next begins instead of assuming every blockchain uses a 20-byte EVM address.

For the EVM eip155 namespace, the CAIP-350 profile assigns 0x0000 as the chain type. It serializes the chain ID as the shortest possible big-endian unsigned integer and stores the address as its native bytes. Ethereum mainnet therefore uses chain reference 0x01, while Optimism uses 0x0a.

The official ERC example encodes an Ethereum mainnet account like this:

0x0001 0000 01 01 14 d8da6bf26964af9d7eed9e03e53415d37aa96045
   │     │   │  │  │                    │
version type len chain len              address

Spaces and labels above are explanatory; the actual payload is contiguous bytes. A zero-length Address can represent a chain by itself. A zero-length chain reference can represent an address where the chain is intentionally unspecified, although applications should not silently treat that as a specific network.

ERC-7930 vs ERC-7828: Machine Layer and Human Layer

Raw binary is efficient for contracts and protocols but awkward for people. ERC-7828 Interoperable Names proposes a user-facing form:

<address>@<chain>#<checksum>

Examples in the specification include a raw address with @eip155:1, an ENS name such as alice.eth@ethereum, and non-EVM chain references. The address may be a native target address or an ENS name. The chain may use its CAIP-350 representation or a human-readable label resolved under the on.eth ENS namespace.

The optional eight-character checksum is derived from the canonical binary components, excluding the version field. ERC-7828 recommends it for raw addresses and advises against adding it to ENS names. That checksum checks the combined chain-and-address representation; it does not authenticate the recipient.

The division is deliberate:

• ERC-7930 is the compact canonical envelope for software.
• ERC-7828 is a readable name for interfaces and sharing.
• CAIP-350 profiles define how each chain family serializes its chain reference and address.

This is different from EIP-55 checksum addresses. EIP-55 adds typo-detection case to one EVM address but does not encode the network. ERC-7930 carries network context explicitly.

Where Interoperable Addresses Fit

Cross-chain intents and messaging

An order that says “deliver to this address” remains incomplete when several destination chains are possible. A chain-aware recipient gives cross-chain intents and message formats a consistent destination object. The current ERC-7683 specification depends on ERC-7930 for chain-specific addresses.

Wallet send and receive flows

A compatible wallet could parse one value, select or verify the intended network, and show the account plus chain at the final decision point. That can reduce a class of wrong-network mistakes, provided the wallet preserves the context instead of discarding it.

Contracts, registries, and APIs

Protocols can accept one byte field rather than separate fields with project-specific rules. OpenZeppelin's current Contracts utilities documentation includes functions for formatting and parsing version 1 interoperable addresses, showing how reusable libraries can reduce custom encoding work.

Non-EVM interoperability

The envelope does not assume every account is 20 bytes. Namespace profiles can define serialization for other chain families. That makes the format broader than a list of EVM chain IDs, while also making correct profile validation essential.

Security Risks and Limits

Review status and implementation drift

Neither proposal is final as of this article's publication date. SDKs, demos, and older explainers can implement different revisions. Pin the specification revision you support, use official test vectors, and plan migration before treating encoded values as durable identifiers.

Chain context is not recipient identity

An interoperable address can unambiguously say “this account on this chain.” It cannot say whether the account belongs to your intended person, whether a contract is safe, or whether malware replaced the entire value with another valid one.

Canonicalization can be namespace-specific

ERC-7930 calls canonical addressing a “leaky abstraction.” A namespace may permit more than one valid representation or have identifier collisions. Implementers using the bytes as database or mapping keys must review each CAIP-350 profile rather than assuming universal uniqueness.

Resolver and label trust

Human-readable ERC-7828 chain labels depend on ENS resolution. Applications need a clear failure state for unresolved, conflicting, or unexpectedly changed labels. They should display the resolved canonical chain before authorization, not hide it behind friendly text.

Compatibility gaps

If a wallet or application does not support the standard, it may reject the value or mishandle its context. Never paste an ERC-7930 byte string into a field that expects a plain account address. Confirm explicit support first.

Checksums have a narrow job

An ERC-7828 checksum helps detect corruption or inconsistency in the chain-address pair. A valid checksum does not certify the frontend, resolver, account owner, token, contract, or transaction outcome.

A Practical Integration Checklist

For developers:

1. Confirm the current ERC status and choose a documented revision.
2. Parse by declared lengths and reject truncated, trailing, or malformed data.
3. Validate the ChainType against a supported CAIP-350 profile.
4. Convert to a canonical native address before equality or key operations.
5. Preserve chain context through APIs, storage, signing, and display.
6. Show the resolved chain and full recipient immediately before authorization.
7. Fail closed when a checksum, namespace profile, or chain label cannot be verified.
8. Test EVM and non-EVM vectors, zero-length cases, unsupported versions, and hostile inputs.

For users:

• Check that the wallet explicitly supports the format.
• Confirm the full recipient, chain, asset, amount, and action separately.
• Treat a readable label as a convenience, then verify its resolved network.
• Use an independently trusted source for the destination.
• For an appropriate high-consequence transfer, test with an amount you can afford to lose.

Frequently Asked Questions

Is ERC-7930 a new wallet address?

No. It is an envelope that combines an existing target address with chain information. The underlying account does not change.

Does it prevent sending funds on the wrong chain?

It gives compatible software the context needed to detect or avoid that mistake. Protection depends on adoption and correct implementation; unsupported software cannot be assumed to preserve the chain field.

Is ERC-7930 only for Ethereum and EVM chains?

No. Its namespace and length-prefixed design supports other chain families through CAIP-350 profiles. The rules for each namespace still need to be implemented and reviewed correctly.

Can people share the raw binary string?

They can, but the specification positions it mainly for machine-readable contexts. ERC-7828 provides the intended human-facing address-plus-chain form.

Are ERC-7930 and ERC-7828 final?

No. Both official proposal pages show Review status as of September 30, 2026. Treat examples and APIs as evolving until the standards reach Final.

The Useful Mental Model

ERC-7930 is a labeled container: it carries both the account bytes and the chain needed to interpret them. ERC-7828 is the readable shipping label on that container. Together they aim to replace scattered multichain conventions with a common machine and interface layer.

That is meaningful infrastructure, not a guarantee of safe delivery. Applications still need strict parsing, current namespace profiles, transparent resolution, and a final recipient-and-chain confirmation. Users still need to verify the destination independently.

This article is educational and does not constitute financial advice. Crypto transfers can be irreversible and digital assets can lose substantial value. Verify current primary documentation, use only funds you can afford to lose, and do your own research (DYOR). NFA.

Primary Sources

• ERC-7930: Interoperable Addresses
• ERC-7828: Interoperable Names
• CAIP-350 eip155 namespace profile
• Ethereum Foundation: Protocol Priorities Update for 2026
• OpenZeppelin Contracts: Interoperable address utilities