Summary
This proposal introduces a standardized extension for ERC-20 tokens to support alias-based metadata resolution.
The goal is to enable tokens, contracts, or agents to expose human-readable or context-specific aliases that can be resolved in a consistent and interoperable way across applications.
Motivation
While ERC-20 provides a minimal interface for fungible tokens, it lacks flexibility in how tokens or associated entities can present contextual identity or metadata.
In many emerging use cases (e.g., agent-based systems, composable protocols, multi-context applications), there is a need for:
- Human-readable identifiers beyond static token names
- Context-aware aliases (e.g., per application, per environment, or per role)
- A standardized way to resolve these aliases on-chain
Currently, projects implement such mechanisms in ad hoc ways, leading to fragmentation and lack of interoperability.
This proposal aims to address that gap by introducing a common interface for alias metadata resolution.
Proposal
This ERC defines an optional extension to ERC-20 that allows:
- Associating aliases with tokens or related entities
- Resolving aliases dynamically based on context
- Providing a standardized interface for external consumers
The extension is designed to be:
- Backward compatible with existing ERC-20 tokens
- Lightweight and optional to implement
- Discoverable via standard interface detection (e.g., ERC-165)
Specification (Draft)
A working draft of the specification is available here:
Backward Compatibility
This proposal does not introduce breaking changes to ERC-20.
Existing contracts can adopt the extension without modifying core token behavior. Applications that do not support the extension will continue to function as expected.
Security Considerations
Potential concerns include:
- Misleading or spoofed aliases if not properly validated
- Ambiguity in alias resolution across different contexts
- Over-reliance on off-chain interpretation of alias meaning
Implementations should ensure:
- Clear rules for alias ownership and updates
- Deterministic resolution logic where possible
- Proper validation when used in security-sensitive contexts
Open Questions / Feedback Requested
I would appreciate feedback from the community on:
- Whether alias resolution should be tied strictly to ERC-20, or generalized as a standalone ERC
- The role of ERC-165 in interface discovery for this extension
- Standardization of context encoding (if applicable)
- Potential edge cases or attack vectors
- Naming and scope of the proposal
Looking forward to feedback and discussion.