ERC-7930 and ERC-7828: Interoperable Addresses for Safer Cross-Chain Transfers

Why a hexadecimal address alone is incomplete in a multichain world

Ethereum's account model popularized 20-byte hexadecimal addresses displayed with a 0x prefix. That format is now used by a large number of EVM-compatible networks.

This created excellent tooling portability. Wallet software, signing libraries, smart-contract tooling, block explorers and applications can often reuse the same address-handling logic across chains.

It also created ambiguity.

A value such as 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 does not contain a field saying Ethereum mainnet.

The same 20 bytes can be interpreted as an address on Base, Arbitrum, Optimism, Polygon, BNB Chain, Linea, Scroll and other EVM environments.

Whether the same private key controls that address across several EVM chains depends on how the account was created. Even when one key does control the same address everywhere, the balances, approvals, contracts, transactions and operational context remain chain-specific.

Address equality does not mean state equality

Suppose one externally owned account uses the same 0x address on Ethereum and Base.

The address bytes are identical.

The ETH balance on Ethereum is independent from the ETH balance on Base.

An ERC-20 allowance granted on Ethereum does not automatically exist on Base.

A contract deployed at that address on one chain may not exist on another.

A transaction sent to that address on the wrong chain therefore interacts with a different state environment even though the visible recipient string looks identical.

Contract addresses make chain ambiguity even more dangerous

A contract address can exist on several chains with different code, different administrators or no code at all.

Cross-chain applications that pass a target address without chain context can therefore create more than a payment-routing mistake. They can cause calls to be executed against the wrong contract environment.

For smart-contract interactions, chain context belongs to the identity of the target.

Non-EVM chains add another dimension

Multichain systems increasingly need to represent addresses from chains whose native formats are not 20-byte Ethereum addresses.

Bitcoin, Solana and other ecosystems use different encodings and chain-identification methods.

A universal interoperability layer therefore needs more than an Ethereum chain ID placed beside an EVM address.

It needs an extensible way to identify a chain namespace, identify the chain inside that namespace, and serialize the target address according to that ecosystem's own canonical rules.

What ERC-7930 introduces

ERC-7930 defines an Interoperable Address as a binary payload that unambiguously associates a target address with a target chain where the required chain-specific information is present.

The design uses a versioned and length-prefixed envelope.

Versioning allows the format to evolve. Length prefixes allow chain references and addresses to have variable sizes. A ChainType field tells software which namespace-specific serialization rules should be used.

The standard relies on CAIP-350 profiles for the chain-specific serialization and interpretation rules associated with each namespace.

ERC-7930 is infrastructure, not a new wallet nickname

The binary format is intended primarily for machine-facing interoperability.

Smart contracts, cross-chain messages, intent protocols, APIs and wallet internals can pass one value that preserves both account identity and chain context.

The binary string itself is not intended to replace convenient user-facing wallet names.

That distinction is why ERC-7828 exists alongside it.

Anatomy of an ERC-7930 Interoperable Address

Version 1 of ERC-7930 contains six sequential components.

Version

The first field is a two-byte version identifier.

Version 1 is encoded as 0x0001 in big-endian form.

Versioning matters because address interoperability may need to evolve as new namespaces, address systems or application requirements emerge.

The specification requires future versions to preserve reconstructability of the Version 1 information when compatible evolution is intended.

ChainType

ChainType is a two-byte value corresponding to the namespace profile used to interpret the chain reference and target address.

For EVM chains, a relevant profile can define how EIP-155-style chain identifiers and Ethereum addresses are serialized.

For another ecosystem such as Solana, a different profile can define how the genesis-derived chain reference and 32-byte address are represented.

This namespace layer is what allows ERC-7930 to extend beyond EVM-only addressing.

ChainReferenceLength

The next field records the number of bytes occupied by ChainReference.

The chain reference can vary in length because different chain namespaces identify networks differently.

For Ethereum mainnet under an EVM profile, the chain reference can be compact.

For another chain ecosystem, the canonical reference may be substantially longer.

ChainReference

ChainReference contains the actual serialized identifier for the target chain.

Its meaning is governed by the associated CAIP-350 namespace profile.

That separation is useful because ERC-7930 does not need to hardcode the chain-identification rules of every possible blockchain.

It defines the envelope. Namespace profiles define the serialization details.

AddressLength

AddressLength records how many bytes of target-address data follow.

An EVM address commonly occupies 20 bytes.

A Solana public key occupies 32 bytes.

Length-prefixing allows one envelope to support different native address sizes.

Address

The final field contains the serialized target address according to the relevant namespace profile.

The important property is that software now receives that address together with the information required to interpret which chain it belongs to.

ERC-7930 examples and special cases

ERC-7930 is more flexible than a simple chain-ID-plus-address tuple.

Ethereum mainnet address

An Ethereum mainnet destination can include Version 1, the EVM ChainType, a chain reference representing Ethereum mainnet, an address length of 20 bytes and the 20-byte target address.

The specification's example produces a binary value beginning with the version and namespace information before appending the actual target address bytes.

This means the same 20-byte account on Base would not have the same complete ERC-7930 representation as the Ethereum destination because its chain reference would differ.

Solana address

The specification also demonstrates a Solana mainnet destination.

Its ChainType differs, its ChainReference is longer, and the target address is 32 bytes rather than 20.

The example illustrates why an extensible binary envelope is useful. Ethereum-specific assumptions about address length or chain IDs do not need to be imposed on every supported ecosystem.

Address without ChainReference

ERC-7930 permits ChainReferenceLength to be zero.

In that case the payload can identify an address within a namespace without committing to one specific chain reference.

This flexibility is useful for some internal workflows, but applications requiring a specific destination chain should not interpret a chainless value as equivalent to a fully chain-bound destination.

Chain Identifier without an address

AddressLength can also be zero when a valid ChainReference exists.

The resulting Interoperable Address identifies the chain rather than a specific account on that chain.

This lets the same envelope represent chain identity and chain-specific account identity.

The role of CAIP-350

ERC-7930 deliberately delegates namespace-specific serialization to CAIP-350 profiles.

This avoids turning one Ethereum ERC into a registry of every blockchain's internal address rules.

A profile can specify how a chain reference should be serialized, how native addresses are converted into binary form, and what special canonicity considerations apply.

Canonical serialization matters for checksums and storage

Two different human-readable strings can sometimes refer to the same underlying address.

Case differences are an obvious example in some address systems.

If software hashes or indexes the raw user-entered string rather than a canonical serialization, equivalent destinations can become different database keys or produce different checksums.

ERC-7930 tries to provide a common binary object, but its own security considerations acknowledge that true canonicity depends on the underlying namespace profile.

Canonical does not mean infallible

A blockchain ecosystem can have multiple identifiers that refer to the same network, or an address namespace can permit more than one valid representation.

Implementers using interoperable addresses as mapping keys, allowlist entries or deduplication identifiers need to review the relevant namespace profile rather than assuming every chain provides perfect one-to-one canonicalization.

What ERC-7828 adds for humans

ERC-7930 solves the machine-representation problem.

It does not solve the human-readability problem.

A long hexadecimal binary payload containing version bytes, chain namespace data, a chain reference and address bytes is not a practical destination string for ordinary users to recognize.

ERC-7828 defines Interoperable Names as a human-readable chain-specific address format.

The format makes the chain relationship visually explicit.

Instead of displaying one bare account string, software can show a destination such as a raw address at a particular chain or an ENS name at a readable chain label.

Raw target address

The address portion can contain a normal target address.

For an EVM destination, that can be a traditional 0x address.

The chain component then states where that address is intended to be used.

ENS name

The address portion can also be an ENS name.

An interoperable name can therefore express a combination such as a wallet name on Ethereum or another supported chain.

The ENS name must be resolved according to chain-specific ENS resolution rules rather than assuming one Ethereum mainnet address applies universally.

Canonical chain reference

The chain portion can contain a namespace-qualified identifier such as eip155:1.

This is relatively explicit for software and technically experienced users.

It is less friendly for users who recognize Ethereum or Base by name rather than numerical identifiers.

Human-readable chain label

ERC-7828 can also use readable chain labels that resolve under the on.eth ENS namespace.

A user-facing application can therefore display a label such as ethereum rather than requiring a user to memorize eip155:1.

This improves readability while adding an ENS-based resolution dependency.

How the ERC-7828 checksum works

ERC-7828 supports an optional eight-character checksum appended after a number sign.

The checksum is calculated from the canonical ERC-7930 representation after excluding the Version field.

Specifically, the relevant ChainType, chain-reference fields and address fields are hashed with Keccak-256, and the first four bytes of that hash are represented as eight uppercase hexadecimal characters.

Why the checksum excludes Version

Excluding the ERC-7930 version allows an Interoperable Name to remain useful across compatible upgrades to the underlying binary format.

If the semantic destination remains the same, changing the binary envelope version should not necessarily require every readable recipient identifier to change.

Checksum use with raw addresses

The checksum is optional but recommended when the address component is a raw target address.

It provides a compact integrity check over both chain and destination information.

This is an important distinction from an EVM address checksum that covers only the address itself.

An ERC-7828 checksum can help detect a mismatch where either the chain or target address has been altered relative to the canonical destination used to calculate it.

Checksum use with ENS names

ERC-7828 recommends not attaching the checksum when the address portion is an ENS name.

ENS resolution can legitimately change over time.

A checksum calculated against yesterday's resolved address could therefore fail tomorrow even though the ENS name is operating exactly as intended.

When ENS names are used, the user delegates part of identity resolution to ENS and its resolver model.

ERC-7930 vs ERC-7828 vs legacy formats

How ERC-7828 chain labels resolve

A readable label such as ethereum is more convenient than eip155:1, but software needs a canonical way to determine which chain that label represents.

ERC-7828 defines that process around ENS.

The on.eth namespace

If the chain component does not contain a colon, it is treated as a readable chain label under the on.eth namespace.

Software can query the resolver associated with that namespace for an interoperable-address data record corresponding to the requested chain label.

The result should be an ERC-7930 chain identifier.

This creates an on-chain source of truth for mapping a human-readable label to canonical chain metadata.

Aliases can exist

The system can support aliases.

For example, a shorter label and a fuller label could resolve to the same underlying chain identifier.

Reverse resolution is intended to return one canonical label.

This is useful for display consistency but creates another reason applications should resolve labels rather than compare raw strings.

Resolver integrity becomes part of chain identity

When an application accepts ethereum as a chain label, it is relying on the ENS resolution infrastructure associated with on.eth to return the correct canonical chain identifier.

If that resolver is compromised, misconfigured or replaced unexpectedly, a readable label could theoretically point somewhere the user did not intend.

Applications should therefore treat chain-label resolution as a security-sensitive operation rather than decorative UX.

How ENS recipient names resolve

If the address component contains a period, ERC-7828 treats it as an ENS name.

That name must be resolved with the target chain in mind.

This is crucial.

A multichain ENS name can have different destination addresses for different chains.

A wallet should not resolve the ENS name once on Ethereum and then reuse that result blindly for every other network.

Chain-specific ENS resolution

ENS specifications already support multichain and EVM-compatible chain address resolution.

ERC-7828 builds on those mechanisms rather than introducing a second unrelated naming system.

The chain component therefore influences how the address component is resolved.

An ENS name paired with Ethereum can resolve differently from the same name paired with another network.

Wildcard resolvers add flexibility and dynamism

ENS wildcard resolution can generate responses dynamically.

This is useful for advanced naming systems.

It also means the result a user receives is not always a static record permanently stored in one place.

Wallets should show the final resolved chain and address before confirmation rather than treating the human-readable name as sufficient evidence by itself.

Wallet use cases

Wallet software is one of the most obvious beneficiaries of chain-specific address standards.

Copy and paste

Today a user can copy a 0x address from a message and paste it into a wallet.

The wallet knows the selected network but usually has no cryptographic evidence that the person who supplied the address intended that network.

An interoperable name can transport the recipient and chain intention together.

If the wallet is currently on Base while the pasted destination specifies Ethereum, the mismatch can be surfaced immediately rather than being silently accepted.

QR codes

A QR code can encode a chain-specific destination rather than only an address.

This reduces the chance that a user scans a valid recipient but initiates payment from the wrong network.

It can also simplify payment requests for merchants or treasury operations because the requested destination chain remains attached to the recipient information.

Address books

A wallet address book should ideally distinguish Alice on Ethereum from Alice on Arbitrum where the operational destination differs.

Storing only one raw hexadecimal address and a free-form label can create ambiguity later.

ERC-7930 provides a more structured machine-facing key for chain-bound address-book entries.

Transaction confirmation

Wallets can present both the human-readable chain and final resolved recipient before the user signs.

This helps users notice a destination-chain mismatch that would otherwise remain hidden behind a familiar-looking address.

Smart-contract use cases

Cross-chain contracts frequently need to identify a recipient that lives on another network.

Ad hoc designs commonly store a chain ID in one field and an address in another.

That works, but every protocol must decide its own serialization and validation rules.

Cross-chain messages

A message that instructs a destination contract to release assets can carry one interoperable destination object rather than assuming the receiver knows how to combine separate namespace, chain and address fields.

This is especially useful when messaging systems want to support more than one blockchain family.

TokenToolHub's guide to cross-chain messaging examines how transported data, validator assumptions and destination execution interact in multichain protocols.

Mappings and allowlists

A protocol can use chain-specific destinations in registries where chain context matters.

However, ERC-7930's own security considerations warn that canonicity can depend on the namespace profile.

Developers using interoperable addresses as mapping keys should therefore verify whether multiple valid representations can refer to the same semantic destination.

Cross-chain permissions

A contract authorizing one destination should not accidentally authorize the same address bytes on every chain.

Binding the target chain into the representation can reduce this class of ambiguous policy.

Intent protocols and ERC-7930

Intent systems are another major use case.

A cross-chain intent can specify that a solver should deliver a particular asset to a particular recipient on a particular chain.

If the recipient is represented as only 20 address bytes, the solver needs another field to discover which chain those bytes belong to.

ERC-7930 allows the chain and recipient to travel together.

ERC-7683 uses interoperable addresses

The current ERC-7683 cross-chain intents specification uses ERC-7930 interoperable addresses in its solver-facing representation.

This is a strong example of why ERC-7930 exists.

A generalized solver can potentially execute actions across several chains and address namespaces. A target therefore needs to be more expressive than one EVM address.

Address standards do not solve settlement risk

Correctly representing the destination does not determine whether the cross-chain settlement protocol is safe.

Intent systems still depend on solvers, contracts, liquidity, validation mechanisms, messages, proofs and chain finality.

Address safety is one layer of the complete route.

Bridge and cross-chain transfer use cases

Wrong-chain transfers are one of the clearest practical problems chain-specific address formats are trying to reduce.

Withdrawal forms

An exchange or application asking for a recipient can accept a chain-specific destination rather than forcing the user to select network and address independently.

The application can reject a destination whose embedded chain does not match the selected withdrawal network.

Bridge destination fields

A bridge moving assets from one chain to another can preserve the destination chain as part of the recipient representation.

This is particularly useful when a user is bridging to another wallet or another address rather than the same account that initiated the origin transaction.

Route comparison

Correct destination addressing does not determine whether the bridge route itself is safe.

Before moving significant value, the TokenToolHub Bridge Helper can help organize route considerations, while the bridge security checklist provides a deeper framework for evaluating validator assumptions, wrapped assets, upgradeability, settlement and operational risk.

The security risks interoperable addresses do not automatically remove

Chain confusion remains possible

A safer format does not guarantee every application will use it correctly.

Software can ignore the chain

An application might accept an ERC-7828 value, parse out the address, and discard the chain because its internal transaction form supports only a legacy address field.

This is a dangerous compatibility pattern.

The user may believe the chain binding is being respected while the software has silently downgraded the destination.

Software can compare the wrong identifiers

Different chain-label aliases can resolve to the same canonical chain.

Applications should compare canonical chain identity rather than simple user-facing strings.

Users can override warnings

A wallet may correctly detect that the destination specifies Ethereum while the transaction is being prepared on Base.

If the user can dismiss that warning without understanding it, the standard cannot stop the transfer.

High-risk mismatches should be blocked or require a deliberate conversion rather than treated as ordinary informational notices.

Resolver compromise and naming infrastructure risk

ERC-7828 can turn a readable chain label into canonical chain metadata using ENS.

That improves user experience while creating dependencies on the resolver configuration associated with the relevant ENS namespace.

Chain-label resolver changes

If the resolver for a chain label changes, applications can begin receiving different data from the same readable string.

Wallets should validate resolver behavior and avoid indefinite caching when the underlying record is expected to remain dynamically updateable.

ENS recipient changes

An ENS owner can legitimately update a name to point to a new wallet.

This is a feature.

It also means a previously verified human-readable name does not guarantee the same destination months later.

Users making high-value payments should confirm the final resolved address at transaction time.

Wildcard resolution

Wildcard resolvers can return data according to logic rather than one static record.

This creates powerful naming systems but requires wallets and applications to treat resolution code as an active component of destination identity.

Lookalike names and homoglyph attacks

Human-readable names remove one type of cognitive burden while introducing another.

People are better at recognizing names than long hexadecimal strings, but human writing systems contain characters that can look nearly identical.

Unicode spoofing

An attacker can attempt to register a name containing characters that visually resemble a legitimate destination.

ENS normalization specifications are designed to constrain dangerous forms of ambiguity, but wallet developers still need to implement naming rules correctly.

Chain-label spoofing

A malicious application can display text resembling a recognized chain label while resolving something else internally.

The final canonical chain should therefore be derived from the interoperable representation, not trusted from arbitrary UI text.

Visual branding should not replace canonical identity

A familiar chain logo can be copied by any website.

Wallets should bind displayed chain branding to the actual resolved chain identifier rather than allowing applications to supply both independently.

Address poisoning still matters

ERC-7828 can include a raw address.

Raw addresses remain difficult for humans to compare.

Attackers exploit this through address poisoning by creating or selecting addresses whose beginning or ending resembles an address the victim has previously used.

The attacker then generates transactions or transfers that place the lookalike address into recent history.

A user copying from history and checking only the first and last few characters can send funds to the attacker.

A chain suffix does not solve lookalike addresses

An attacker can create a poisoned address on the correct chain.

Adding @ethereum or @base prevents some chain confusion but does not prove the account portion is correct.

Checksum helps integrity, not identity

An ERC-7828 checksum can help detect modifications to a specific canonical chain-and-address pair.

An attacker can still create a completely different address and present a valid checksum for that malicious destination.

A checksum answers whether the identifier is internally consistent.

It does not answer whether the recipient is the person or protocol the user intends to pay.

Unsupported-format fallback is a major adoption risk

Interoperability standards create the most value when many independent systems preserve their semantics.

During adoption, users will encounter software that understands the new format and software that does not.

Safe fallback

A wallet that cannot process an ERC-7828 destination should clearly reject it or ask the user to convert it through a verified resolution path.

The wallet should not pretend it fully understood the destination.

Unsafe fallback

A dangerous implementation strips everything after the @ symbol and submits only the raw address on the wallet's currently selected chain.

The syntax has been accepted, but the security property has been destroyed.

Downgrade attacks

An attacker may intentionally try to force an application into a legacy path that ignores chain binding.

Developers should therefore treat chain information as mandatory once the user supplies a chain-specific destination.

Loss of that information should cause failure rather than silent fallback.

Canonicity and duplicate representations

ERC-7930 aims to provide a canonical binary format, but the specification explicitly acknowledges that real-world chain namespaces can complicate canonicity.

Multiple chain identifiers

A network may have more than one identifier used in different ecosystems.

If two identifiers refer to the same semantic chain, naïve software can treat them as separate destinations.

Multiple address encodings

A chain can support several textual encodings that resolve to the same underlying account.

CAIP-350 profiles are responsible for defining canonical serialization rules where possible.

Mapping-key risk

Smart contracts and databases often use binary identifiers as keys.

If two different interoperable values can refer to the same semantic destination, an allowlist or deduplication system can behave unexpectedly.

Builders should understand namespace-specific edge cases before relying on byte equality as proof of semantic inequality.

A safe cross-chain recipient verification workflow

Interoperable addresses improve the information available to users and applications, but the transaction process still needs a deliberate verification sequence.

Step 1: verify how the recipient was obtained

A chain-specific address received from a verified application or authenticated communication channel is stronger evidence than an address copied from a random reply, search result or recent transaction list.

Interoperable formatting preserves destination context but cannot authenticate the person who sent it.

Step 2: resolve human-readable components

If the chain component is a readable label, resolve it to canonical chain metadata.

If the recipient is an ENS name, resolve it for that chain.

Do not resolve the name on one chain and then substitute that address into another network manually.

Step 3: inspect the final resolved representation

The wallet should be able to tell the user what chain and account the readable identifier ultimately means.

For a high-value transfer, users should confirm the full destination rather than only the name.

Step 4: verify the receiving system supports the selected network

A valid destination address does not guarantee a centralized exchange credits deposits on that network.

It does not guarantee a merchant accepts the asset there.

It does not guarantee a smart contract implements the expected function there.

Recipient capability is separate from address validity.

Step 5: evaluate cross-chain transport separately

If value must move through a bridge, intent solver or messaging protocol, review that infrastructure separately.

A perfectly encoded recipient cannot protect funds from an insecure bridge validator set or compromised settlement contract.

Step 6: verify the final transaction

The wallet confirmation is the last opportunity to catch an incorrect chain, token or recipient before authorization.

If a completed transaction behaves unexpectedly, the TokenToolHub Transaction Decoder can help inspect supported EVM transaction methods, token movements, approvals, internal calls and execution results.

When recipient identity needs more than an address

Chain-specific addressing answers where an account exists.

It does not necessarily answer who controls it.

A business, exchange, treasury, bridge or protocol can operate many addresses across many networks.

Researchers may need broader on-chain context before sending significant value.

Where supported, Nansen can complement destination verification with address labels, entity context and multichain wallet activity. Labels remain contextual evidence rather than cryptographic proof that a particular person or organization currently controls an address.

Wallet implementation checklist

Smart-contract and protocol implementation checklist

What must happen before interoperable addresses become routine

ERC-7930 and ERC-7828 solve a coordination problem, which means their effectiveness depends heavily on ecosystem adoption.

As of September 2026, both proposals are in Review status rather than being universally deployed wallet conventions.

Users should not assume every wallet, exchange, bridge, dApp, explorer or protocol accepts them.

Wallet support

Wallets need parsers, chain metadata, ENS integration where applicable, safe fallback behavior and new confirmation UX.

Without wallet support, users cannot rely on interoperable names as universal payment identifiers.

Library support

Developers need reliable implementations for parsing, serializing, checksum calculation, CAIP-350 profile handling, ENS resolution and canonical comparison.

Duplicated hand-written parsing code increases the likelihood of inconsistent interpretation.

Protocol support

Intent protocols, bridges, messaging systems and account-abstraction applications need to preserve interoperable address information end to end.

A format provides little protection if one intermediate adapter strips the chain reference.

Exchange support

Centralized exchanges are an important source of wrong-network transfer mistakes because one deposit address may be reused across several EVM chains while deposit support differs by network.

Exchange adoption could allow withdrawal and deposit flows to carry recipient and network context more explicitly.

QR and payment standards

Merchant payments, donation links and invoices can benefit when the requested chain is inseparable from the recipient.

For broad adoption, QR encoders and payment-request libraries need to agree on how interoperable destinations are transported.

Explorer support

Block explorers can help users by recognizing chain-specific destinations and avoiding ambiguous links that display one address without making the chain explicit.

How software should behave during partial adoption

Worked examples

Example one: same EVM address, wrong network

A user asks a counterparty for a payment address.

The counterparty sends a bare 0x address and says the payment should arrive on Ethereum.

The user later pastes that address while the wallet is still connected to Base.

The wallet sees a syntactically valid EVM address and has no embedded evidence that Ethereum was intended.

If the payment is sent, it goes to the same 20-byte address on Base.

An ERC-7828 destination that explicitly identifies Ethereum could allow the wallet to detect the mismatch before signing.

Example two: same address controlled across both chains

The recipient happens to control the same account on Ethereum and Base.

The wrong-chain payment may therefore be recoverable.

That does not make the mistake harmless.

The recipient may not monitor Base, may require payment on Ethereum for accounting reasons, or may not support the token representation used on Base.

Chain correctness remains economically meaningful even when the private key is shared.

Example three: exchange deposit address

An exchange gives a user one 0x deposit address but accepts a particular token only on selected networks.

The address may technically exist on several EVM chains.

A transfer to an unsupported network can reach an address controlled by the exchange while still not being automatically credited.

An interoperable destination can communicate which network the deposit instruction actually supports.

Example four: contract recipient exists on only one chain

A protocol asks users to send assets to a contract address on Arbitrum.

The same hexadecimal address on Ethereum has no deployed contract.

A user who sends to that address on Ethereum has not interacted with the intended protocol even though the recipient string matches.

Binding Arbitrum into the destination identity helps prevent this confusion.

Example five: readable chain label

A wallet receives an interoperable name ending in @ethereum.

The wallet resolves ethereum.on.eth to its canonical ERC-7930 chain identifier and verifies that it represents Ethereum mainnet.

The user sees Ethereum rather than having to understand the chain identifier directly.

The readability benefit depends on successful and trustworthy resolution.

Example six: alias handling

Two different readable labels resolve to the same chain.

A wallet that compares only strings might believe they are different destinations.

A wallet that compares canonical resolved chain identifiers can correctly recognize that the labels refer to one network.

Example seven: ENS recipient changes

A user pays alice.eth@ethereum several times.

Alice later migrates to a new wallet and updates the ENS record.

The next payment resolves to a different target address.

This is legitimate behavior.

It is also why users should confirm the current resolved address for important transfers rather than assuming a remembered destination remains unchanged forever.

Example eight: address poisoning on the correct chain

An attacker creates a Base address resembling the victim's trusted recipient.

The attacker sends a dust transaction so the lookalike appears in recent wallet history.

The poisoned address can be encoded in a perfectly valid ERC-7828 destination for Base with a valid checksum.

The chain-specific format is working correctly.

The identity verification failed because the user copied the wrong account.

Example nine: unsafe fallback

A user pastes a destination containing a raw address and @ethereum into an old wallet.

The wallet recognizes the 0x prefix, discards the unsupported suffix and submits the transaction on Optimism because that is the currently selected chain.

This is worse than rejecting the format because the wallet gives the impression that the user's recipient request was understood.

Example ten: cross-chain intent solver

An intent solver receives an ERC-7683 resolved call whose target is represented with ERC-7930.

The solver can determine which chain hosts the call target without relying on an unrelated chain field supplied by application-specific code.

The interoperable address improves execution clarity.

The solver still has to evaluate the contract, token spending, settlement and bridge assumptions separately.

Example eleven: Solana destination

A generalized cross-chain protocol wants to support Ethereum and Solana destinations.

An EVM-only tuple of uint256 chain ID plus address cannot express the Solana destination naturally because Solana's address size and chain-reference conventions differ.

ERC-7930's variable-length namespace-based structure can represent both under one envelope.

Example twelve: chain identifier without recipient

A cross-chain application needs to express only that a particular operation belongs to Solana mainnet without yet knowing the final address.

An ERC-7930 Chain Identifier can represent the chain with AddressLength set to zero.

The same data model can therefore be reused for chain-only and chain-plus-address contexts.

Common misconceptions about ERC-7930 and ERC-7828

ERC-7930 creates new blockchain accounts

It does not.

It provides a standardized representation for identifying an account together with chain context.

ERC-7930 replaces Ethereum addresses

It does not replace the native address representation used by Ethereum transactions.

It wraps chain identity and serialized target-address information into an interoperable object for cross-chain contexts.

ERC-7828 replaces ENS

No.

ERC-7828 uses ENS as part of its readable chain-label and name-resolution architecture.

An ERC-7828 checksum proves the recipient is legitimate

No.

The checksum helps verify integrity of the chain-specific destination encoded by the name. A malicious recipient can still have a valid checksum.

The same 0x address always means the same wallet everywhere

The same key can derive the same address across EVM chains, but chain state remains independent.

Contracts, balances and supported services can differ completely.

Chain-specific addresses make bridges safe

No.

They can reduce addressing ambiguity while bridge validator, liquidity, proof and contract risks remain separate.

Readable chain labels can be trusted as plain text

No.

The label should be resolved to canonical chain metadata. Arbitrary UI text is not a secure chain identifier.

Every wallet supports ERC-7930 and ERC-7828

No.

Both standards remain in Review status as of September 2026, and support should be verified per product.

A chainless interoperable address is always unsafe

Not necessarily.

The format intentionally allows some chain-reference omission. Whether that is acceptable depends on the application.

A cross-chain payment that needs one exact destination network should require explicit chain context.

Adoption should preserve semantics, not just syntax

Standards can fail in practice even when software claims support.

The important question is whether every layer preserves the intended meaning.

Parser support

The application must parse the format correctly.

Canonicalization support

The application must interpret namespace-specific chain references and addresses according to the correct profile.

UI support

The wallet must communicate the resolved chain and recipient clearly enough for a human to verify them.

Transaction support

The application must ensure the transaction is actually submitted to the chain represented by the destination.

History support

Transaction history and address books should preserve chain-specific context so a user does not later copy only the raw address and lose the protection.

Cross-application support

Sharing a chain-specific destination is useful only if receiving software either understands it or rejects it safely.

What safer multichain addressing could change

Today many cross-chain interfaces treat chain selection as a separate dropdown beside a recipient field.

That model allows the two pieces of information to drift apart.

A user can copy the right recipient and select the wrong network.

A merchant can send the correct account but forget to specify the chain.

A wallet can remember a recent recipient without remembering why that address was previously used on a particular network.

Chain-specific destination objects can make the pair atomic.

Wallet contacts can become destination-aware

Instead of saving Bob = 0x123..., a wallet can save Bob's Ethereum destination and Bob's Base destination as distinct entities even if the target address happens to be identical.

Payment requests can become less ambiguous

A payment request can contain asset, amount and chain-specific recipient without relying on several pieces of text copied separately.

Intent systems can become more general

Solvers supporting EVM and non-EVM destinations can consume one extensible address envelope rather than maintaining one target structure for Ethereum and another for every other ecosystem.

Cross-chain messaging can reduce ad hoc schemas

Protocols can converge on one chain-specific destination primitive instead of repeatedly designing custom chain-plus-address encodings.

This reduces integration fragmentation, although it does not standardize the security of the messages themselves.

Conclusion: a recipient is not complete without its chain context

ERC-7930 addresses a deceptively simple problem created by the expansion of the multichain ecosystem: an address alone is often no longer enough to identify where an interaction is supposed to happen.

Ethereum-style addresses are reused across many networks. Non-EVM ecosystems have their own address systems. Bridges, intent protocols, wallets and messaging systems increasingly need to communicate destinations across these environments.

ERC-7930 creates a binary envelope capable of binding version information, a chain namespace, a chain reference and target-address bytes into one interoperable representation.

Its length-prefixed design allows the structure to represent chains and addresses whose identifiers have very different sizes from Ethereum's familiar 20-byte accounts.

ERC-7828 then provides a human layer on top of that foundation.

An Interoperable Name can pair a raw address or ENS name with an explicit chain identifier or readable chain label and can include an optional checksum for raw chain-specific addresses.

This creates a better user-facing mental model.

The recipient is not merely 0x123....

The recipient is that account on a specific chain.

That distinction can help wallets detect wrong-network transfers, improve QR and payment requests, make address books more precise, give cross-chain smart contracts a standardized destination primitive and let intent systems such as ERC-7683 carry target-chain information without inventing another proprietary schema.

The standards do not eliminate recipient risk.

A chain-specific address can still belong to an attacker. A valid checksum can accompany a malicious destination. ENS records can change. Resolvers can be compromised. Lookalike names can mislead users. Raw addresses remain vulnerable to address poisoning. Unsupported wallets can create dangerous downgrade behavior. A correctly addressed bridge can still have an insecure validator model.

For that reason, safe use depends on preserving chain context from the moment a destination is created until the final transaction is signed.

Wallets should resolve names correctly, canonicalize chain identity, verify checksums where present, avoid silent fallback and display the final chain-specific destination. Protocols should preserve the complete interoperable address across cross-chain boundaries. Users should still verify the receiving network, asset, complete recipient and route before authorizing significant value.

When a transaction has already been submitted and execution needs to be investigated, the TokenToolHub Transaction Decoder can help inspect supported EVM calls and token movement. For planned cross-chain transfers, the Bridge Helper can provide route context, while the bridge security checklist and cross-chain messaging guide address the security layers that remain after the destination itself has been represented correctly.

The long-term value of ERC-7930 and ERC-7828 is therefore not that users stop thinking about recipient safety. It is that wallets and protocols can stop treating chain identity as disposable context around an address and begin treating it as part of the destination itself.

FAQs

References and further reading

The following primary technical specifications define the interoperable address and interoperable name formats discussed in this guide.

• ERC-7930: Interoperable Addresses
• ERC-7828: Interoperable Names
• ERC-7683: Cross Chain Intents
• ERC-55: Mixed-Case Checksum Addresses
• Chain Agnostic Standards Alliance
• Ethereum Name Service Documentation

This guide is educational security research. Interoperable address standards can reduce ambiguity but do not authenticate recipient ownership, guarantee wallet support, guarantee bridge safety or prevent users from authorizing an incorrect transaction. Confirm current standard status, wallet compatibility, destination-chain support, final resolved recipient and cross-chain route assumptions before moving significant value.