One of the most important cross-chain security problems is also one of the easiest to overlook:
A blockchain address can be valid while the intended chain is wrong.
This matters because many networks use similar address formats.
A standard EVM address such as 0x123... can exist on Ethereum, Base, Arbitrum, Optimism, BNB Chain, Polygon and other EVM-compatible networks.
The address bytes may look identical across those networks, but the balances, contracts and transaction histories are completely independent.
That means an address alone does not always describe the full destination.
The chain is part of the destination too.
ERC-7930 and ERC-7828 are designed to make that context harder to lose.
What ERC-7930 Introduces
ERC-7930 defines an Interoperable Address format.
The goal is to represent both blockchain identity and address data inside one canonical binary structure.
Instead of passing only a raw address, the format can include fields such as:
• version
• chain type
• chain-reference length
• chain reference
• address length
• address data
The result is a machine-friendly representation that can tell software not only which account is intended, but also on which chain that account should be interpreted.
Why This Matters
Today, users often copy a destination address and select the chain separately.
That creates a split security model.
The recipient is one field.
The chain is another field.
If either is wrong, the transfer can fail or go somewhere unintended.
Interoperable addresses aim to bind those two concepts together.
A wallet, bridge, intent system or smart contract can then process the recipient and chain context as a single object instead of assuming the chain from surrounding UI state.
ChainType and ChainReference
ERC-7930 separates chain namespace information from the chain-specific identifier.
ChainType describes the relevant blockchain namespace.
ChainReference identifies the specific chain within that namespace.
The standard is designed to work with CAIP-350 profiles.
That is important because interoperable addressing should not be limited only to EVM networks.
The same framework can support additional blockchain ecosystems if the relevant chain and address serialization rules are defined.
ERC-7930 Is Mainly for Machines
ERC-7930 is primarily a binary format.
That makes it useful for smart contracts, protocols, APIs and backend systems.
It is not intended to become a long string that ordinary users memorize and manually type.
For user-facing applications, a more readable representation is useful.
That is where ERC-7828 comes in.
What ERC-7828 Adds
ERC-7828 defines Interoperable Names.
The idea is to give users a readable way to express a recipient together with chain context.
A conceptual structure can look like:
address@chain#checksum
The address portion may be a raw destination address or an ENS name.
The chain portion identifies the intended blockchain.
The checksum can provide an additional integrity check in certain cases.
Human-Readable Chain Labels
The chain section can use a canonical reference such as:
eip155:1
or a human-readable label such as:
Human-readable labels are easier for users, but they introduce resolution requirements.
If a label must be resolved through ENS or another naming system, then resolver correctness becomes part of the security model.
That means software needs to validate the correct namespace, normalization rules and canonical chain data.
ERC-7828 Checksums
When a raw target address is used, ERC-7828 can include a checksum derived from the canonical ERC-7930 representation.
This can help detect some data-entry or transmission errors.
However, checksums should not be misunderstood.
A checksum can help detect corruption.
It does not prove the recipient is trustworthy.
It does not prove the recipient controls the address.
It does not protect against every address-poisoning attack.
And it does not guarantee the transfer route itself is secure.
ENS-Based Recipients
ERC-7828 can also use an ENS name as the address component.
This improves readability, but ENS-based resolution introduces dynamic behavior.
A name can resolve differently over time.
Resolvers can change.
Records can change.
That is why the security model for names differs from the security model for raw addresses.
Applications should resolve the final destination carefully and show the resolved chain and recipient before signing.
Why Silent Fallback Is Dangerous
One of the most important implementation risks appears when interoperable formats meet legacy software.
Imagine that an application receives a chain-aware ERC-7930 or ERC-7828 recipient.
The software understands only a traditional address field.
Instead of rejecting the unsupported format, it extracts the raw address and silently discards the chain context.
The user may believe the full interoperable destination is being preserved.
It is not.
The system has just removed the exact information the standard was designed to protect.
Unsupported-format fallback should therefore be handled explicitly.
If chain information cannot be preserved, the software should not silently continue as if nothing changed.
Address Poisoning Still Matters
Interoperable addressing does not eliminate address poisoning.
Attackers can still create lookalike addresses.
Users who verify only the first and last few characters of an address can still be deceived.
Chain-aware formatting may reduce one category of error, but it does not replace complete recipient verification.
The same principle applies to human-readable names.
A chain label or ENS name can still be visually confusing or intentionally deceptive.
Lookalike-name attacks remain possible.
Wallets Need Better Confirmation Screens
A wallet supporting interoperable addresses should clearly show:
• the destination chain
• the destination recipient
• the resolved result
• the asset being sent
• the final authorization
The chain should not be hidden behind a small network icon while the address receives all the visual emphasis.
If the chain is part of the destination identity, it should be part of the confirmation identity too.
Cross-Chain Intent Systems
Interoperable addressing also fits naturally with intent-based protocols.
A cross-chain intent may specify that a user wants to receive a particular asset on a particular chain.
In that context, a plain address is not enough.
The resolver or solver needs unambiguous information about where the output should be delivered.
Binding chain context to recipient identity can reduce ambiguity inside solver-facing orders.
This is one reason interoperable addresses are relevant to standards such as ERC-7683 and broader intent frameworks.
Bridges and Messaging Systems
Bridges also benefit from explicit chain context.
A bridge transaction usually has at least:
• source chain
• destination chain
• destination asset
• destination recipient
If the recipient is passed independently from the chain, software needs to preserve their relationship correctly through every stage.
A chain-aware representation can make that association more explicit.
But again, the format does not secure the bridge itself.
Bridge contracts, validators, message relayers, liquidity providers and settlement logic retain their own risks.
Resolver Risk
Human-readable chain names introduce another important issue: resolver risk.
If software accepts a name such as ethereum rather than a canonical chain reference, something needs to determine what that label means.
That resolver becomes security-sensitive.
A compromised or incorrectly configured resolver could map a familiar-looking label to the wrong canonical chain context.
Applications therefore need explicit validation rules rather than blindly trusting readable names.
Canonicity Risk
Interoperable formats also need canonical representations.
If several different encodings describe what software believes is the same destination, comparison and verification become harder.
Canonicalization rules matter for:
• checksums
• signatures
• caching
• equality checks
• intent matching
• security policies
Two visually similar values should not silently resolve to different canonical destinations.
Current Status
As of September 2026, ERC-7930 and ERC-7828 remain in Review status.
That means users and developers should not assume universal support.
Support should be evaluated per wallet, protocol, library and application.
A sender may understand the format while the receiving application does not.
That interoperability boundary needs careful handling.
The Security Lesson
ERC-7930 and ERC-7828 address a real multichain problem.
Addresses increasingly need chain context.
A destination is not merely:
0x123...
It is closer to:
this recipient,
on this chain,
using this canonical interpretation.
That is a stronger foundation for multichain wallet UX.
But it does not eliminate recipient verification, resolver security, bridge risk, spoofing or address poisoning.
The standards reduce ambiguity.
They do not remove the need for due diligence.
The safest cross-chain workflow still requires verifying:
• destination chain
• destination asset
• full recipient
• supported address format
• resolved result
• final wallet confirmation
The most important takeaway is simple:
An address can be valid while the chain is wrong.
Full TokenToolHub analysis:
https://tokentoolhub.com/erc-7930-erc-7828-interoperable-addresses/