This ERC proposes a standard presentation layer transformation for Ethereum addresses containing long sequences of identical hexadecimal digits. It defines two representation formats: a Unicode-based format using superscripts for graphical user interfaces (UI), and an ASCII-safe fallback format using bracket notation for logs and terminals. This standard aims to improve human readability and safety verification without altering the underlying address data.
As the Ethereum ecosystem matures, addresses with long repeating sequences are becoming increasingly common due to several factors:
Vanity Addresses & CREATE2: Factories and developers frequently generate "vanity" addresses with specific prefixes or suffixes for branding or identification.
Gas Optimization (EIP-7939): With proposals like EIP-7939 aiming to reduce gas costs for zero bytes in calldata, there is an economic incentive to deploy contracts at addresses containing large sequences of zeros to optimize cross-contract call costs.
Security Risks: The human eye struggles to distinguish between long sequences of identical characters (e.g., counting 10 zeros vs. 11 zeros). This creates a "homoglyph-like" vulnerability where users may skim over the middle of an address, missing subtle differences in a phishing scam.
Current truncation methods (e.g., 0x1234...5678) obscure the internal structure of the address. A standardized compression format allows users to verify the magnitude of the repeated sequence (e.g., "exactly 11 zeros") at a glance.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
The compression transformation applies only to the visual representation of the address.
Compression SHOULD be applied if a sequence of identical hexadecimal nibbles has a length $L$, where $L \geq 6$.
The standard defines two modes of display. Implementations must preserve the first character of the repeating sequence to indicate which character is being repeated, followed by a count of the total length of the sequence.
Recommended for Wallets, Block Explorers, and Mobile Apps.
Syntax: 0x + [repeating_char] + [superscript_count] + [remainder]
Encoding: The count integer is converted to Unicode Superscript characters (U+2070 to U+2079).
Example:
0x00000000000000000044... (Eighteen 0s)0x0¹⁸44...Recommended for Developer Consoles, Logs, and Copy-Paste operations.
Syntax: 0x + [repeating_char] + { + [count] + } + [remainder]
Example:
0x00000000000000000044...0x0{18}44...To preserve the checksum integrity defined in EIP-55 and EIP-1191:
aAaA cannot be compressed).Regex Alignment (ASCII Mode): We selected the curly brace syntax Byte{n} (e.g., 0{8}) because it aligns with the universal Regular Expression standard for quantification. Developers intuitively understand {n} as "repeat n times."
Divergence from IPv6: Unlike IPv6, which uses :: to represent "fill the gap with zeros," EVM vanity addresses rely on the specific count of characters for identity. Therefore, an explicit count ({8}) is safer than an implicit gap (::).
While subscript notation (e.g., $H_2O$) implies component count in chemistry, this ERC selects Superscript (0⁸) for the following reasons:
Legibility: Superscripts generally render more clearly on digital displays and do not conflict with text underlines (hyperlinks) or font baselines.
Metaphor: Superscripts serve as a visual metaphor for Scientific Notation, indicating the magnitude or length of the sequence, rather than a mathematical power operation.
With the introduction of logic similar to EIP-7939 (scaling gas costs based on calldata zeros), the ecosystem will see a proliferation of addresses engineered to have maximum zero bytes. A display format that handles these specific addresses gracefully is a necessary proactive measure for user experience.
This ERC is strictly a presentation layer standard.
Wallets: Must strip the compression formatting (convert back to full hex) before signing or broadcasting transactions.
Safety: The characters {, }, and Unicode superscripts are not valid hexadecimal characters. If a user blindly copies a compressed address into a legacy system, the system will reject the input as invalid rather than processing a wrong address. This acts as a fail-safe mechanism.
The following Python implementation demonstrates the logic for both Unicode and ASCII modes, covering full display and truncated variations.
Homoglyph Attacks: While this standard aims to reduce visual confusion, developers must ensure that the font used for superscripts is distinct enough that 0⁷ is not misread as 07.
Copy-Paste Validation: Applications accepting address input MUST prioritize standard hexadecimal parsing. If an input contains {} or superscripts, the application should strictly reject the input or explicitly offer to decompress it, rather than attempting to hash invalid characters.
Preservation of Entropy: This standard does not compress distinct characters. It only compresses low-entropy sequences (repeats), ensuring that the visually distinct part of the address (the high-entropy suffix) remains prominent.
Copyright and related rights waived via CC0.