-
Notifications
You must be signed in to change notification settings - Fork 848
Add ERC: Contract Feature Detection #1146
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.
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
Changes from 5 commits
879f6a5
652accb
75e240e
6910232
afb9d62
f6ba2e9
ae79671
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,78 @@ | ||
| --- | ||
| eip: 7996 | ||
| title: Contract Feature Detection | ||
| description: Method to publish and detect contract features that lack an ERC-165 interface | ||
| author: raffy.eth (@adraffy) | ||
| discussions-to: https://ethereum-magicians.org/t/erc-7996-contract-feature-detection/24975 | ||
| status: Draft | ||
| type: Standards Track | ||
| category: ERC | ||
| created: 2025-07-07 | ||
| requires: 165 | ||
| --- | ||
|
|
||
| ## Abstract | ||
|
|
||
| Creates a standard method to publish and detect what features a smart contract implements that lack an [ERC-165](./eip-165.md) interface. | ||
|
|
||
| ## Motivation | ||
|
|
||
| Ethereum Name Service (ENS) has maintained backwards compatibility with contracts created in 2016 through extensive use of ERC-165. Unfortunately, not all contract capabilities can be expressed through an unique interface. | ||
|
|
||
| Features allow expression of contract capabilities that preserve existing interfaces. This proposal standardizes the concept of features and standardizes the identification (naming) of features. | ||
|
|
||
| ## Specification | ||
|
|
||
| ### How Features are Identified | ||
|
|
||
| For this standard, a *feature* is any property of a contract that cannot be expressed via ERC-165. | ||
|
|
||
| A feature name SHOULD be a reverse domain name that uniquely defines its implication, eg. `eth.ens.resolver.extended.multicall` is the multicall feature for an extended ENS resolver contract. | ||
|
|
||
| A feature identifier is defined as the first four-bytes of the keccak256-hash of its name, eg. `bytes4(keccak256("eth.ens.resolver.extended.multicall")) = 0x96b62db8`. | ||
|
|
||
| ### How a Contract will Publish the Features it Implements | ||
|
|
||
| A contract that is compliant with this specification SHALL implement the following interface: | ||
|
|
||
| ```solidity | ||
| interface IERC7996 { | ||
| /// @notice Check if a feature is supported. | ||
| /// @param featureId The feature identifier. | ||
| /// @return `true` if the feature is supported by the contract. | ||
| function supportsFeature(bytes4 featureId) external view returns (bool); | ||
| } | ||
| ``` | ||
|
|
||
| The ERC-165 interface identifier for this interface is `0x582de3e7`. | ||
|
|
||
| ### How to Detect if a Contract Implements Features | ||
|
|
||
| 1. Check if the contract supports the interface above according to [ERC-165](./eip-165.md#how-to-detect-if-a-contract-implements-erc-165). | ||
|
|
||
| ### How to Detect if a Contract Implements any Given Feature | ||
|
|
||
| 1. If you are not sure if the contract implements features, use the above procedure to confirm. | ||
| 1. If it implements features, then call `supportsFeature(featureId)` to determine if it implements the desired feature. | ||
|
|
||
| Note: a contract that implements features MAY implement no features. | ||
|
|
||
| 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](https://www.rfc-editor.org/rfc/rfc2119) and [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174). | ||
|
|
||
| ## Rationale | ||
|
|
||
| Defining a new standard avoids unnecessary pollution of the ERC-165 selector namespace with synthetic interfaces representing features. | ||
|
||
|
|
||
| ## Backwards Compatibility | ||
|
|
||
| Callers unaware of features or any specific feature experience no change in behavior. | ||
|
|
||
| ENS already implements this ERC. | ||
|
|
||
| ## Security Considerations | ||
|
|
||
| As with ERC-165, declaring support for a feature does not guarantee that the contract implements it. | ||
|
|
||
| ## Copyright | ||
|
|
||
| Copyright and related rights waived via [CC0](../LICENSE.md). | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your abstract is lacking a bit of technical meat. You should describe, at a high level, what the "standard method" actually is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a few more words, let me know if that is sufficient.
For reference, I was following the
ERC-165specification, but I guess that was written a while ago.