Summary: ERC-7930 is best cataloged as lower-layer chain-specific addressing infrastructure rather than as another wallet UX tweak, bridge helper, or alternative address string. Its core move is to define a versioned binary envelope that binds chain type, chain reference, and target address into one canonical payload, with namespace-specific serialization delegated to CAIP-350 profiles. The important categorization clue is that ERC-7930 tries to standardize the machine-readable address object beneath bridges, intents, account-auth systems, ENS-based chain labels, and cross-chain messaging stacks: not how users see addresses, but how protocols unambiguously refer to one address on one chain without falling back to ad hoc tuples and string conventions.
What it does:
Defines an Interoperable Address binary format with Version, ChainType, ChainReferenceLength, ChainReference, AddressLength, and Address fields
Uses a 2-byte chain-type field tied to CASA / CAIP-350 namespaces so the same envelope can work across EVM and non-EVM chains
Makes chain references and addresses variable-length, allowing longer chain identifiers and arbitrary address encodings instead of assuming one EVM-style fixed format
Allows representations that include both chain and address, a chain without an address, or an address scoped by chain-type rules even when chain reference is omitted
Establishes a compact canonical binary form intended for smart contracts, message passing, and intent declaration rather than only human-readable display
Treats text rendering as downstream/interface work, with ERC-7828 explicitly positioned as the related human-readable layer above it
Key claims:
The review-stage ERC says today’s protocols typically represent address-plus-chain combinations through ad hoc separate fields and protocol-specific conventions, which is the clearest reason to treat ERC-7930 as reusable address-object infrastructure rather than a product-level convenience feature.
The strongest mechanism signal is the binary envelope itself. ERC-7930 does not just prefix an address with a chain name; it standardizes a versioned payload with explicit namespace, chain-reference length, and address length boundaries so chain-specific addressing can be passed around as one canonical machine object.
The CAIP-350 dependency matters because it moves chain-specific serialization rules into shared namespace profiles. That makes ERC-7930 less like a standalone Ethereum-only format and more like a portability layer sitting above many chain families.
The comparison section is analytically valuable because it explicitly argues CAIP-10 is too text-oriented and CAIP-2’s 32-character chain-reference limit is insufficient for some chains such as Solana. That means ERC-7930 is not just a redundant reformatting of existing chain-address strings; it is trying to solve a lower-level canonicalization and compactness problem.
The examples showing Ethereum, Solana, no-chain-reference EVM addresses, and chain-without-address payloads make it clear that ERC-7930 is broader than wallet send forms. It is a general envelope for any protocol that needs to name a chain-specific destination, origin, registry, or network target.
ERC-7828’s design explicitly builds on ERC-7930 by requiring convertibility between human-readable address@chain#checksum strings and the underlying binary payload. That is strong evidence that ERC-7930 belongs in the corpus as the lower address layer beneath later naming and UX standards.
The deepest comparison question this adds is where canonical address meaning really lives in a multichain stack: in chain registries, in namespace-specific codec rules, in human-readable labels, or in whatever binary envelope downstream bridges, wallets, and registries end up treating as authoritative.
Whitepaper: No standalone ERC-7930 whitepaper or litepaper surfaced in this pass. The clearest current sources were the review-stage ERC, the raw ERC markdown, and the linked downstream human-readable layer in ERC-7828; see ../../whitepapers/erc-7930-primary-sources-2026-05-15.md.