Contract Feature Detection | Ethereum Improvement Proposals

Abstract

Creates a standard method supportsFeature(bytes4) in the same spirit as supportsInterface(bytes4) to publish and detect what features a smart contract implements that lack a derivable ERC-165 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.

Defining a new standard avoids unnecessary pollution of the ERC-165 selector namespace with synthetic interfaces representing features.

Specification

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 and RFC 8174.

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:

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

Check if the contract supports the interface above according to ERC-165.

How to Detect if a Contract Implements any Given Feature

If you are not sure if the contract implements features, use the above procedure to confirm.
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.

Rationale

Since feature names cannot be derived from a contract interface, they are derived from a reverse domain name to reduce collisions and permit a human-readable representention that briefly describes its implication.

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.