Creates a standard method to publish and detect what interfaces a smart contract implements.
Herein, we standardize the following:
For some "standard interfaces" like the ERC-20 token interface, it is sometimes useful to query whether a contract supports the interface and if yes, which version of the interface, in order to adapt the way in which the contract is to be interacted with. Specifically for ERC-20, a version identifier has already been proposed. This proposal standardizes the concept of interfaces and standardizes the identification (naming) of interfaces.
For this standard, an interface is a set of function selectors as defined by the Ethereum ABI. This a subset of Solidity's concept of interfaces and the interface keyword definition which also defines return types, mutability and events.
We define the interface identifier as the XOR of all function selectors in the interface. This code example shows how to calculate an interface identifier:
Note: interfaces do not permit optional functions, therefore, the interface identity will not include them.
A contract that is compliant with ERC-165 shall implement the following interface (referred as ERC165.sol):
The interface identifier for this interface is 0x01ffc9a7. You can calculate this by running bytes4(keccak256('supportsInterface(bytes4)')); or using the Selector contract above.
Therefore the implementing contract will have a supportsInterface function that returns:
true when interfaceID is 0x01ffc9a7 (EIP165 interface)false when interfaceID is 0xfffffffftrue for any other interfaceID this contract implementsfalse for any other interfaceIDThis function must return a bool and use at most 30,000 gas.
Implementation note, there are several logical ways to implement this function. Please see the example implementations and the discussion on gas usage.
STATICCALL to the destination address with input data: 0x01ffc9a701ffc9a700000000000000000000000000000000000000000000000000000000 and gas 30,000. This corresponds to contract.supportsInterface(0x01ffc9a7).0x01ffc9a7ffffffff00000000000000000000000000000000000000000000000000000000.supportsInterface(interfaceID) to determine if it implements an interface you can use.We tried to keep this specification as simple as possible. This implementation is also compatible with the current Solidity version.
The mechanism described above (with 0xffffffff) should work with most of the contracts previous to this standard to determine that they do not implement ERC-165.
Also the ENS already implements this EIP.
Following is a contract that detects which interfaces other contracts implement. From @fulldecent and @jbaylina.
This approach uses a view function implementation of supportsInterface. The execution cost is 586 gas for any input. But contract initialization requires storing each interface (SSTORE is 20,000 gas). The ERC165MappingImplementation contract is generic and reusable.
Following is a pure function implementation of supportsInterface. The worst-case execution cost is 236 gas, but increases linearly with a higher number of supported interfaces.
With three or more supported interfaces (including ERC165 itself as a required supported interface), the mapping approach (in every case) costs less gas than the pure approach (at worst case).
PR 1640, finalized 2019-01-23 -- This corrects the noThrowCall test case to use 36 bytes rather than the previous 32 bytes. The previous code was an error that still silently worked in Solidity 0.4.x but which was broken by new behavior introduced in Solidity 0.5.0. This change was discussed at #1640.
EIP 165, finalized 2018-04-20 -- Original published version.
Copyright and related rights waived via CC0.