ERC-165

ERC-165 is an Ethereum Request for Comments that defines a standard method for smart contracts to declare the interfaces they support. A contract publishes its supported interfaces by implementing a function called supportsInterface(bytes4 interfaceId) that returns true if the contract implements the interface identified by the 4-byte interfaceId. This mechanism allows other contracts and off-chain systems to query a contract's capabilities before interacting with it, preventing runtime errors from calling unimplemented functions. The standard is foundational for creating modular and composable smart contract systems.

The core of ERC-165 is the calculation of the interface identifier, or interface ID. This is a bytes4 value computed as the XOR (exclusive OR) of all function selectors in the interface. For example, the interface ID for ERC-721 is 0x80ac58cd. A contract can support multiple interfaces, and its supportsInterface function must return true for each valid identifier it supports. This design allows for efficient on-chain lookups and is a critical component of the Ethereum Name Service (ENS), upgradeable proxy patterns, and multi-facet Diamond Proxies (EIP-2535).

Developers implement ERC-165 to enable safe interactions in a decentralized ecosystem. Wallets and decentralized applications (dApps) can use it to verify if a contract is a legitimate ERC-20 token or an ERC-721 NFT before displaying it to users. Furthermore, it is a prerequisite for other major standards; ERC-721 and ERC-1155 both mandate ERC-165 support. By providing a reliable discovery mechanism, ERC-165 reduces integration errors and forms the backbone of Ethereum's interoperable smart contract landscape, ensuring that contracts can reliably communicate their functionality.

ERC-165 is an Ethereum Request for Comments standard that defines a method for smart contracts to publish and detect the interfaces they implement. At its core, it provides a lightweight, gas-efficient mechanism for on-chain interface discovery, solving the problem of determining a contract's capabilities without relying on off-chain data or brittle function signature checks. A contract that complies with ERC-165 is said to support the standard, and it does so by implementing a specific function: supportsInterface(bytes4 interfaceId). This function returns true if the contract implements the interface identified by the 4-byte interfaceId, and false otherwise.

The standard operates using interface identifiers, which are 4-byte function signature hashes calculated using the XOR of all function selectors within an interface. For example, the interface ID for ERC-721 is 0x80ac58cd, derived from hashing its core functions like balanceOf(address) and ownerOf(uint256). A contract declares support by returning true when its supportsInterface function is called with that specific bytes4 value. This creates a reliable, on-chain registry of a contract's advertised functionality, which is critical for wallets, marketplaces, and other contracts that need to interact with it safely and predictably.

Implementation involves two key steps. First, the contract must calculate and store the interface IDs it supports, often within the constructor. Second, it must expose the function supportsInterface(bytes4 interfaceId) external view returns (bool) function, which contains the logic to check the stored IDs. Many modern smart contract libraries, like OpenZeppelin Contracts, provide abstract base contracts that handle this logic automatically. When a contract implements multiple standards—such as both ERC-721 and ERC-2981 (royalties)—its supportsInterface function will return true for each of their respective interface IDs, providing a complete picture of its compliance.

The primary use case for ERC-165 is enabling safe interoperability within the Ethereum ecosystem. An NFT marketplace can query a token contract to verify it is a genuine ERC-721 before listing it. A decentralized application can check if a wallet contract supports ERC-1271 for signature validation. This prevents errors and potential loss of funds by ensuring that interacting contracts speak a compatible language. Without this standard, applications would need to use risky methods like low-level calls to probe for specific functions, which can fail silently or be exploited.

A critical nuance is that ERC-165 is itself an interface, with its own interface ID of 0x01ffc9a7. Therefore, a contract that implements ERC-165 must return true for 0x01ffc9a7 in its own supportsInterface function. This creates a recursive foundation: you can first check if a contract supports ERC-165, and if it does, you can then reliably query it for any other interface. This layered approach ensures backward compatibility and forms the bedrock for a composable and verifiable smart contract landscape, where capabilities are not assumed but proven on-chain.

ERC-165 is an Ethereum Request for Comments standard that defines a minimal, gas-efficient method for smart contracts to declare the interfaces they support, enabling other contracts and user interfaces to query this information programmatically. It solves a critical interoperability problem: without a standard detection mechanism, it is impossible for a calling contract to know if another contract supports a specific function, such as balanceOf for ERC-721 tokens or safeTransferFrom for ERC-1155, before attempting an interaction that could fail.

The standard's primary mechanism is the supportsInterface(bytes4 interfaceId) function. Each interface is identified by a unique four-byte function selector known as an interfaceId, which is typically calculated as the XOR of all function selectors within that interface. A contract compliant with ERC-165 returns true when queried with the correct interfaceId for an interface it implements. This allows for a simple, reliable check before proceeding with more complex interactions, preventing errors and wasted gas.

Implementation involves two key steps. First, a contract must implement the supportsInterface function itself. Second, it must register the interface IDs it supports, which is commonly done in the constructor using _registerInterface or by mapping the IDs in the function's logic. Many major token standards, including ERC-20, ERC-721, and ERC-1155, explicitly recommend or require ERC-165 compliance. This creates a foundational layer for the composable "money legos" of DeFi and NFTs, as contracts can safely discover each other's capabilities.

For developers, using ERC-165 is considered a best practice for any contract that implements a published interface. Wallets, block explorers, and decentralized applications (dApps) rely on this standard to correctly identify contract types and enable appropriate features. For instance, a marketplace can verify a contract is an ERC-721 before listing it for sale, and a wallet can show NFT holdings only for addresses that return true for the ERC-721 interface ID (0x80ac58cd).

Beyond basic detection, ERC-165 facilitates more advanced patterns like proxy upgradeability and diamond (EIP-2535) implementations, where a single contract address can support multiple, upgradeable facets. In these architectures, the supportsInterface function becomes the central lookup mechanism for routing function calls to the correct internal logic module. Its simplicity and low gas cost have made it an indispensable utility standard within the Ethereum ecosystem.