supportsInterface

The primary purpose is runtime interface discovery. Before interacting with a contract, a client or another contract can call supportsInterface with an interface identifier to verify if the target contract supports a specific set of functions (e.g., ERC-20, ERC-721). This prevents errors from calling non-existent functions.

• Query: contract.supportsInterface(0x80ac58cd) checks for ERC-721 support.
• Response: Returns true or false.

An Interface Identifier is a 4-byte (32-bit) hash, calculated as the XOR of all function selectors in an interface. This creates a unique fingerprint for a standard.

• Calculation: IID = bytes4(keccak256('transfer(address,uint256)') ^ keccak256('balanceOf(address)') ...)
• Example: The ERC-721 IID is 0x80ac58cd.
• Purpose: This compact identifier allows for efficient on-chain lookups.

A compliant contract stores a mapping or uses logic to return true for the IIDs it implements. The typical implementation involves:

• A _supportedInterfaces private mapping of bytes4 => bool.
• A _registerInterface function called in the constructor.
• The public supportsInterface function that queries this mapping.

Core Logic:

solidityCopy
function supportsInterface(bytes4 interfaceId) public view returns (bool) {
    return _supportedInterfaces[interfaceId];
}

This mechanism is critical for safe composability in DeFi and NFT ecosystems. It allows protocols to:

• Verify token standards before attempting transfers or approvals.
• Build generic tools that adapt to different contract types.
• Fail early and predictably if a required interface is missing, saving gas and preventing transaction reverts deep in a call stack.

Major token standards mandate ERC-165 compliance.

• ERC-721 (NFTs): Must return true for 0x80ac58cd.
• ERC-1155 (Multi-Token): Must return true for 0xd9b67a26.
• ERC-721 Metadata & Enumerable: Optional extensions have their own IIDs (0x5b5e139f, 0x780e9d63).

Wallets and marketplaces use these queries to determine how to properly display and interact with tokens.

A marketplace contract accepting various NFTs must check for standard support.

solidityCopy
function listToken(address nftContract, uint256 tokenId) external {
    // Check if the contract is a valid ERC-721
    require(
        IERC165(nftContract).supportsInterface(0x80ac58cd),
        "Not an ERC-721 contract"
    );
    // Safe to call ERC-721 functions like ownerOf
    address owner = IERC721(nftContract).ownerOf(tokenId);
    // ... proceed with listing logic
}

The supportsInterface function is defined by the ERC-165 standard. It allows a contract to publish which interfaces it implements. The standard specifies:

• A standard method to query if a contract implements a given interface.
• How interface identifiers (bytes4) are calculated using type(Interface).interfaceId.
• That a compliant contract must return true for ERC165's own interface ID (0x01ffc9a7).

Protocols and user interfaces call supportsInterface to dynamically discover a contract's capabilities before interacting with it. This is critical for:

• Wallets & Explorers: To correctly display token types (e.g., distinguishing an ERC-721 from an ERC-1155).
• Integrating Contracts: A DeFi protocol can check if a token supports ERC-20 metadata or ERC-2612 permit() before making specific function calls.
• Proxy Upgrades: To verify a new implementation supports required interfaces.

In upgradeable proxy patterns (e.g., Transparent, UUPS), the supportsInterface function must be implemented carefully to reflect the logic of the current implementation contract, not the proxy's storage. Best practices include:

• Delegating the call to the implementation via delegatecall.
• Ensuring the proxy itself returns true for ERC-165's interface ID.
• This allows the system's external interface to remain consistent and discoverable across upgrades.

Contracts implementing multiple interfaces must correctly aggregate interface identifiers. The type(I).interfaceId is a bitwise XOR of the function selectors in an interface. For a contract implementing interfaces A and B:

solidityCopy
function supportsInterface(bytes4 interfaceId) public view override returns (bool) {
    return interfaceId == type(A).interfaceId
        || interfaceId == type(B).interfaceId
        || super.supportsInterface(interfaceId);
}

This ensures accurate responses for all supported interfaces.

While supportsInterface is a view function, frequent on-chain calls can be gas-intensive. Optimization strategies include:

• Caching Results: Contracts may store known interface support in a private mapping to avoid repeated delegatecall overhead in proxies.
• Minimal Overrides: Overriding the function only when adding new interfaces, relying on parent contract implementations where possible.
• Off-Chain Indexing: Front-ends often index interface support to reduce runtime blockchain queries.

Recognizing standard interface IDs is essential for developers. Key examples include:

• ERC-165: 0x01ffc9a7
• ERC-20: 0x36372b07
• ERC-721: 0x80ac58cd
• ERC-1155: 0xd9b67a26
• ERC-2981 (Royalties): 0x2a55205a
• ERC-5267 (EIP-712 Domain): 0x84b0196e These IDs are computed from the function signatures defined in each standard's interface.

A primary security function of supportsInterface is to prevent type confusion attacks. Without it, a calling contract might incorrectly assume another contract implements a specific function set (e.g., ERC-20, ERC-721). This can lead to failed transactions, lost funds, or locked assets when the expected functions are not present. Querying the interface ID before interaction is a mandatory safety check.

Correct implementation is non-negotiable for security.

• Explicit Returns: The function must explicitly return true or false; a missing return can cause a revert in the caller.
• Constant Gas Cost: Implementations should have a constant, low gas cost. Complex logic or storage reads introduce risk.
• Override Correctly: When inheriting multiple interfaces, ensure the overridden function uses the override keyword and correctly aggregates checks for all supported interfaces (e.g., override(ERC721, ERC2981)).

The interface ID is a 4-byte identifier calculated as the XOR (exclusive OR) of all function selectors in the interface. This deterministic calculation ensures a unique fingerprint. For example, the ERC-20 interface ID is 0x36372b07. Miscalculating this ID—such as using addition instead of XOR—will cause the contract to fail standard compliance checks, breaking interoperability with wallets and explorers.

In upgradeable proxy patterns (e.g., Transparent, UUPS), supportsInterface must be implemented carefully. The logic should reside in the implementation contract, not the proxy. However, the proxy must correctly delegate the call. A faulty setup can report incorrect interface support, causing dApps to break after an upgrade. Always test interface support through the proxy address, not the implementation address.

Before integrating with an external contract, perform these checks:

• Call supportsInterface: Verify the exact interface ID you depend on.
• Use staticcall: Perform the check as a view/pure call to avoid state changes.
• Handle false Gracefully: Your contract's logic should have a fallback or revert path for unsupported interfaces.
• Check for ERC-165 Itself: First, verify the contract supports ERC-165 (interfaceId: 0x01ffc9a7). If it doesn't, it cannot reliably report other interfaces.

Historical audits reveal recurring vulnerabilities:

• Incorrect Interface ID: Hardcoded or miscalculated IDs leading to false positives/negatives.
• Missing Override Statements: Causing one supported interface to hide another in complex inheritance.
• Gas Inefficiency in Loops: Implementing checks by iterating over an array can run out of gas.
• Proxy Storage Clashes: Storing interface support in a proxy's storage slot that conflicts with the implementation.

An Interface ID is a unique 4-byte identifier for a smart contract interface, calculated as the XOR of all function selectors in that interface. This deterministic calculation ensures consistency across implementations.

• Process: For an interface with functions functionA() and functionB(), calculate bytes4(keccak256('functionA()')) ^ bytes4(keccak256('functionB()')).
• Critical for ERC-165: The supportsInterface function checks against this calculated ID.

In upgradeable proxy patterns (e.g., Transparent Proxy, UUPS), the supportsInterface function must be carefully managed. The call must be delegated to the implementation contract to reflect its current interface.

• Challenge: The proxy and implementation have separate bytecode.
• Solution: The proxy's supportsInterface should use delegatecall to the logic contract or store the response directly in the proxy's storage.

Solidity provides the type(I).interfaceId expression to safely and correctly obtain the interface ID for a given interface I. This eliminates manual calculation errors.

• Usage: require(contract.supportsInterface(type(IERC721).interfaceId), "Not ERC721");
• Benefit: The compiler calculates the ID, ensuring it stays correct if the interface definition changes.