---
# System prepended metadata

title: Untitled

---

# Interop Addr vs 7828
> *What if we abstract 7828 even further? (bye bye 7785)*
 

**Good things about ERC-7828:**

- Simplest representation out there
- Sensible use of ENSIP-11 (which we borrowed)

**As for the shortcomings of ERC-7828 itself:**

- defines checksums are mandatory and cover the entire address, but doesn’t give them a place in the grammar, and only relies on erc-55 for checksumming the address component alone
- does not define the grammar to specify what name registry to use for the ‘address’ part (but is present in the examples)
- Addresses are hard-coded at the grammar level to 40 0-f characters, which hinders support for e.g. starknet
- Unclear path forward if ENS releases a name-specific rollup

**Why Yet Another Address Standard?** *(or a revamp of 7828)*

We chose to develop an interoperable address standard which evolves from ERC-7828. The main diff for it is its reliance in ERC-7785, which:

- Is not yet quite adopted and seems to have lost momentum. (has no active discussions, empty on Ethereum-magicians, unanswered questions on GitHub since December)
- It's not yet clear if it will support ALT-L1s (Sonic, Polygon, Gnosis) potentially requiring another further ERC specifying it.
- Does not support chains outside of the Ethereum ecosystem (which is required to have a single address standard for e.g. intent-based bridging as well)
- Does not have a fully defined migration path from the centralized lists (which will involve security-sensitive work on the EF part)