title: ERC Extensions
description: Establishes Naming Conventions, Metadata, and Procedures for ERC Extensions
author: Joey Santoro (@joeysantoro)
discussions-to: Add EIP: ERC Extensions by Joeysantoro · Pull Request #7875 · ethereum/EIPs · GitHub
type: Standards Track
This EIP Establishes a framework for ERC Extensions, or ERCs which directly extend or override the functionality of a prior ERC.
This standard includes a standardized definition for an ERC Extension. It includes a naming convention for the Title EIP header field, adds an optional
extensions EIP header field for referencing downstream ERC extensions, and extablishes procedures for specifying overridden functionality.
Ethereum application development uses a contract oriented programming paradigm which is similar to Object Oriented Programming (OOP). Because of this, many smart contract systems and high level languages have object like behavior with the possibility for overriden functionality.
ERC Standards also behave in a similar way, with logical extensions flowing from the necessity to standardize specific use cases on top of higher level standards. (e.g. ERC-2612 extends ERC712) and ERC-4626 extending ERC-20).
There should be a framework for handling these extension cases both retroactively and in the future to improve ERC accessibility.
Usage of the term Extension below is shorthand for an ERC Extension.
An Extension is any ERC which has all of the following properties:
- interface compatibility
- logically consistent
An Extension MUST require the implementation of at least one existing ERC.
It MUST add additional functionality or specificity.
An Extension MAY NOT define new functions or add functions to the extended interface. If an Extension does not define any new functions, it MUST specify functionality for a limited use case of the extended ERC.
An Extension MUST be fully compatible at the function interface level. I.e. all functions in the extended interface MUST implement the exact same function signature and selector.
An Extension MAY NOT have the same parameter names or state mutability.
An Extension MUST maintain the core logical functionality of the extended ERC. This MAY include some non-compliance at the implementation level specification, as long as the overriden behavior is fully specified.
Specifically, mutable functions MUST remain mutable and immutable functions MUST remain immutable. I.e. the state mutability between
non-payable MAY interchange and the state mutablity between
pure MAY interchange.
An Extension SHOULD include the ERC number of the extended ERC in the title (e.g. Non-transferrable ERC-721). If not in the title, the description MUST include the ERC number of the extended ERC.
Once an Extension becomes Final, the extended ERC MUST be edited to include the extension in a new header field called
E.g. ERC-4626 extends ERC-20, therefore ERC-20 must be edited to add:
Any breaking changes or non-compliance at the implementation level MUST be fully specified and justified in the
Rationale. An explicit
ERC-XXX Breaking Changes sub-heading must be included in the
Specification section for every extended ERC which has breaking changes. Omission of the Breaking Changes subheading MUST mean there are no breaking changes at the implementation specification level.
All breaking changes MUST be compliant with the properties of an Extension.
EIPs published before EIP-7539 MAY be edited to comply with some or all of EIP-7539.
This EIP was designed to provide a minimal framework for future Extensions without adding too much boilerplate. All features are designed to improve the utility and accessibility of Extensions and the ERCs they extend.
The header allows historical ERCs to reference future extensions cleanly. The
extensions header allows for forward navigation and the existing
requires header allows for backward navigation of ERC heirarchies.
Extensions may require certain breaking changes at the implementation, however those should be constrained to a well defined set of possible changes. Functions changing their mutability should not happen, and interfaces should remain fully compatible.
All breaking changes should be clearly specified in their own section with respect to each extended ERC for maximum legibility.
Each EIP should still have a canonical number following the EIP process. If instead derivative naming such as ERC-20b was used, EIPs become harder to place in a chronological context, Extensions which extend multiple ERCs become difficult to name, and many parts of the existing EIP process become unweildy or change significantly.
Instead, requiring the extended ERC to be named in the title or description allows for sufficient colloquial discussions to tie the Extension to the extended ERC.
This EIP is fully backward compatible with all EIPs.
It does not require editing historical ERCs, but does open the possibility of doing so in part or full.
Copyright and related rights waived via CC0.