ERC-7930 primary sources — 2026-05-15

Project status in this pass

• No standalone ERC-7930 whitepaper or litepaper surfaced.
• The clearest source of truth was the review-stage ERC itself, backed by the raw ERC markdown and the downstream ERC-7828 human-readable naming layer that depends on it.
• The sources consistently frame ERC-7930 as a canonical binary chain-specific address object, not as a wallet-only convenience string.

Primary-source snapshots

1) Canonical ERC page

• URL: https://eips.ethereum.org/EIPS/eip-7930
• Key excerpt/signals:
  • The abstract introduces a binary format for describing a chain-specific address using a versioned, length-prefixed envelope.
  • The motivation says current protocols usually combine chain and address through ad hoc separate fields and protocol-specific conventions.
  • The review draft explicitly says the format is meant to be compact for smart contracts, cross-chain messaging, and intent declaration.
• Why it mattered:
  • This is the clearest evidence that ERC-7930 belongs in the corpus as reusable addressing substrate rather than a product-specific formatting convention.

2) Raw ERC markdown

• URL: https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-7930.md
• Key excerpt/signals:
  • The raw markdown makes the full field layout explicit: Version, ChainType, ChainReferenceLength, ChainReference, AddressLength, and Address.
  • It ties ChainType and serialization behavior to CAIP-350 namespace profiles, which is the main signal that ERC-7930 is designed for cross-ecosystem portability.
  • The examples include Ethereum, Solana, EVM-without-chain-reference, and chain-without-address payloads.
• Why it mattered:
  • These details show that ERC-7930 is not merely another prefixed address string; it standardizes a general machine-readable envelope beneath many higher-level UX and interoperability systems.

3) Comparison section inside the ERC

• URL: https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-7930.md
• Key excerpt/signals:
  • The ERC contrasts itself with CAIP-10 and says CAIP-10 does not canonicalize target-address serialization.
  • It also argues CAIP-2’s 32-character chain-reference limit can fail to losslessly represent some chains such as Solana.
• Why it mattered:
  • This is the strongest evidence that ERC-7930 is solving a deeper canonicalization and compactness problem rather than reinventing a familiar text identifier.

4) ERC-7828 downstream dependency

• URL: https://eips.ethereum.org/EIPS/eip-7828
• Key excerpt/signals:
  • ERC-7828 says Interoperable Names must remain convertible to the corresponding ERC-7930 Interoperable Address binary format.
  • Its checksum definition is computed from fields of the canonical ERC-7930 payload rather than from a free-form string.
  • It treats human-readable chain labels and ENS-based chain discovery as a higher layer above the underlying binary address object.
• Why it mattered:
  • This is strong downstream evidence that ERC-7930 is becoming the lower machine-readable layer beneath later user-facing naming standards.

Working conclusion

ERC-7930 is best cataloged as the canonical binary chain-specific address primitive beneath multichain UX, ENS-based chain labels, intent payloads, and cross-chain messaging. The decisive evidence in this pass was the ERC’s explicit envelope format, its comparison against CAIP-10 and CAIP-2 limitations, and ERC-7828’s direct dependence on ERC-7930 as the authoritative underlying address object.