Skip to content

Update ERC-7930: Move to Last Call #1240

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 12 commits into
base: master
Choose a base branch
from
Open

Update ERC-7930: Move to Last Call #1240

Changes from 9 commits
Commits
Show all changes
12 commits
Select commit Hold shift + click to select a range
98a77a2
docs: change status to lastcall
euler0x Oct 6, 2025
31b0396
docs: add scope and delegation
euler0x Oct 6, 2025
012b3f6
docs: add reference implementation
euler0x Oct 6, 2025
e138e91
fix: typo **
euler0x Oct 6, 2025
91d7572
docs: add reference to 7828
euler0x Oct 6, 2025
b76e904
docs: add reference to 7828
euler0x Oct 6, 2025
ea106a6
docs: OZ reference implementation
euler0x Oct 6, 2025
62c1519
docs: add reference to 7828
euler0x Oct 6, 2025
1314455
Merge branch 'master' into 7930-lastcall
skeletor-spaceman Oct 9, 2025
00b90e9
fix: reference implementations external link
skeletor-spaceman Oct 10, 2025
799f89f
fix: sections are strictly defined
skeletor-spaceman Oct 10, 2025
6aad265
fix: use eth-magicians as ref impl
skeletor-spaceman Oct 10, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 16 additions & 6 deletions ERCS/erc-7930.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,8 @@
description: An extensible binary format to refer to an address specific to one chain.
author: Teddy (@0xteddybear), Joxes (@0xJoxess), Nick Johnson (@Arachnid), Francisco Giordano (@frangio), Skeletor Spaceman (@skeletor-spaceman), Racu (@0xRacoon), TiTi (@0xtiti), Gori (@0xGorilla), Ardy (@0xArdy), Onizuka (@onizuka-wl), Sam Kaufman (@SampkaML), Marco Stronati (@paracetamolo), Yuliya Alexiev (@yuliyaalexiev), Jeff Lau (@jefflau), Sam Wilson (@samwilsn), Vitalik Buterin (@vbuterin)
discussions-to: https://ethereum-magicians.org/t/erc-7930-interoperable-addresses/23365
status: Draft
status: Last Call
last-call-deadline: 2025-10-20
Comment on lines +7 to +8
Copy link
Contributor

@SamWilsn SamWilsn Nov 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
status: Last Call
last-call-deadline: 2025-10-20
status: Review

type: Standards Track
category: ERC
created: 2025-02-02
Expand All @@ -22,7 +23,7 @@
- Addresses do not include any indication of the chain to which the address applies. This means chain information must be expressed out of band, and introduces the risk of an address being mistakenly used on a chain it is not valid for. This risk is particularly pronounced for addresses that represent smart contracts.
- The existing address format provides no mechanism for extension, meaning that there is no natural method to add these features to the existing address format.

Interoperable Addresses build on insights from <!-- TODO: [ERC-7828] -->, [CAIP-10] and [CAIP-50], offering a unified format which combines:
Interoperable Addresses build on insights from [ERC-7828], [CAIP-10] and [CAIP-50], offering a unified format which combines:
- Binding chain specificity (via explicit chain identifiers) to the raw address.
- Compact & canonical binary format for use on cross-chain message passing and intent declaration.
- Checksums for name collision mitigation & user error prevention.
Expand All @@ -46,12 +47,18 @@

Interoperable Names are convertible to [CAIP-10] without even going through the binary representation, so backwards-compatibility with actors expecting [CAIP-10] identifiers should not be an issue.

CAIP-10 also depends on CAIP-2, which limits the chain reference to 32 characters. The binary format of this standard natively supports chain identifiers of arbitrary length, removing this bottleneck and making the standard more future-proof.

The interop roadmap is better served by having a standardized binary format for addresses first, which allows the message passing and intents verticals to move forward on a common interface, with a good-enough text representation which is familiar to users and useful for developers, and as a next step develop a chain & address name resolving standard on top of it, leveraging its uniformity and extensibility.


## Specification
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

### Scope and Delegation to CAIP-350

A versioned, length-prefixed binary envelope for interoperable addresses. The interpretation and serialization of the payload inside that envelope are not standardized here; they are intentionally delegated to chain-specific profiles maintained by the Chain-Agnostic Standards Alliance (CASA), notably [CAIP-350]. Implementations MUST consult the relevant [CAIP-350] profile for a target namespace/chain to obtain the authoritative rules for binary serialization, display, and round-tripping of addresses.

### Concepts
Interoperable Address
: A binary payload which unambiguously identifies a target address and allows conversion to a human-readable name.
Expand Down Expand Up @@ -208,6 +215,12 @@
keccak256 input for checksum: `0x00022045296998a6f8e2a784db5d9f95e18fc23f70441a1039446801089879b08c7ef000`.
Note the version field is removed before hashing.


## Reference Implementation
- [Interop-SDK](https://github.com/defi-wonderland/interop-sdk/tree/dev/packages/addresses): A TypeScript/JavaScript library for encoding, decoding, and manipulating Interoperable Addresses.

Check failure on line 220 in ERCS/erc-7930.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

non-relative link or image 

error[markdown-rel-links]: non-relative link or image
   --> ERCS/erc-7930.md
    |
220 | - [Interop-SDK](https://github.com/defi-wonderland/interop-sdk/tree/dev/packages/addresses): A TypeScript/JavaScript library for en...
    |
    = help: see https://ethereum.github.io/eipw/markdown-rel-links/
Copy link
Contributor

@g11tech g11tech Oct 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this link is not within the allowed list of links, you can refer this link in discussions-to comment/section and then add the section link here

- OpenZeppelin is developing a Solidity library contract for Interoperable Addresses.


## Security Considerations
While this standard aims to be a foundation to be able to canonically refer to addresses on different chains, that guarantee is going to be a leaky abstraction in the real world, given that e.g. a particular chain namespace might define a serialization scheme that can't guarantee canonicity of addresses, or a given network might have two valid [CAIP-2] ids referring to it.

Expand All @@ -216,14 +229,11 @@
## Copyright
Copyright and related rights waived via [CC0](../LICENSE.md).

<!-- TODO:

[ERC-7828]: ./eip-7828.md

-->

[ERC-55]: ./eip-55.md
[ERC-7785]: ./eip-7785.md
[ERC-7828]: ./eip-7828.md
[CAIP-2]: https://github.com/ChainAgnostic/CAIPs/blob/2a7d42aebaffa42d1017c702974395ff5c1b3636/CAIPs/caip-2.md
[CAIP-10]: https://github.com/ChainAgnostic/CAIPs/blob/2a7d42aebaffa42d1017c702974395ff5c1b3636/CAIPs/caip-10.md
[CAIP-50]: https://github.com/ChainAgnostic/CAIPs/blob/2a7d42aebaffa42d1017c702974395ff5c1b3636/CAIPs/caip-50.md
Expand Down
Loading