Skip to content
Merged
Changes from 5 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
78 changes: 78 additions & 0 deletions ERCS/erc-7996.md
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.
Copy link
Contributor

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.

Copy link
Contributor Author

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-165 specification, but I guess that was written a while ago.


## 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The rationale section should explain choices made within the document, not why we need the entire standard. For example, you could explain why you've chosen reverse domain names as the feature names.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved this sentence to the motivation section.

I added a new sentence that describes why a reverse domain name.


## 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).
Loading