This is the third of a 4 part series on token standards. Here I am going to introduce token standards that are foundations and extend the ERC 20 and ERC 721 Standards.
To know more about token standards for Fungible and Non-Fungible Tokens refer to my previous post in this series.
Token Standards for Standard Interface Detection: ERC 165
The ERC 165 is really a standard for a method, instead of tokens. The ERC721 is dependent on this standard. Smart contracts interact with different tokens. There are different types of tokens which are based on different ERC standards and the tokens implement those specific standard functions. Developers need to know which interfaces a token implements in order to use the tokens and this information should be published.
This is an important foundation for other ERCs for the reasons below —
- Developers need to know which interfaces a smart contract implements
- ERC 165 defines a method to publish and detect interfaces that a smart contract implements
- It standardizes the identification of interfaces
Specification for the ERC 165
A contract that is compliant with ERC-165 shall implement the following interface
interface ERC165 {
function supportsInterface(bytes4 interfaceID) external view returns (bool);
}
The interface identifier for this interface is 0x01ffc9a7. The implementation contract will have a supportsInterface function that returns:
- true when interfaceID is 0x01ffc9a7 (EIP165 interface)
- false when interfaceID is 0xffffffff
- true for any other interfaceID this contract implements
- false for any other interfaceID
This function must return a bool and use at most 30,000 gas.
ERC 20 is a popular and widely used standard. However it has some limitations —
- If ERC 20 tokens are sent to a smart contract that doesn’t handle tokens, they are lost/burnt
- Token Supply is fixed as there is a single issuance event and is restricted to a single immutable value
- While invoking a smart contract, after the first transaction, the ERC 20 standard requires another transaction to verify whether the criteria are met. The smart contract is invoked only after this. This increases the number of transactions, effectively causing friction.
The following standards are extensions which aim to solve some of these shortcomings of the ERC 20
ERC223 : Prevents accidental burning of tokens. Provides Ability to Accept/Decline Tokens sent
ERC 621 : Provides 2 additional functions: increaseSupply & decreaseSupply. Can only be executed by contract owner or trusted users.
ERC777
- Proposes a set functions to identify receipt of tokens and start a smart contract immediately after the first transaction.
- While lowering the transaction overhead, it also allows a user to reject incoming tokens from a blacklisted address. It also enables ‘whitelisting’ of operators
ERC827
- Enables Token Transfer for A 3rd Party with approval to Spend It.
- It also enables tokens reuse, all parties agree on specific criteria for a 3rd party to spend a dynamic amount.
This standard defines a universal registry smart contract where any address (contract or regular account) can register which interface it supports and which smart contract is responsible for its implementation.
Features of the ERC 1820
- Defines a registry where smart contracts and regular accounts can publish which functionality they implement — either directly or through a proxy contracts
- Registry can be queried to ask if a specific address implements a given interface and which smart contract handles its implementation.
- ERC-1820 fixes the incompatibility in the ERC-165 logic which was introduced by the Solidity 0.5 update.
- ERC-165 which has the limitation that it cannot be used by regular accounts
- ERC-1820 is functionally equivalent to ERC-820 and must be used in lieu
- This standard is much simpler than ERC-672, and it is fully decentralized.
Specifications of the ERC 1820
- A contract that is compliant with ERC-1820 shall implement the following interface
interface ERC1820ImplementerInterface {
function canImplementInterfaceForAddress(bytes32 interfaceHash, address addr) external view returns(bytes32);
}
- The Official Registry Implementation ERC1820Register may be posted on any chain and shares the same address on all chains.
- This contract also acts as an ERC-165 cache to reduce gas consumption.
Tokens standards like ERC-20 and ERC-721 require a separate contract to be deployed for each token type or collection. This places a lot of redundant bytecode on the Ethereum blockchain and limits certain functionality by the nature of separating each token contract into its own authorized address.
ERC 1155 solves all the major issues of ERC 20 and ERC 721. It is one of the most advanced token standards. It applies to multi-token types and allows them to be described in a single contract.
Features of ERC 1155
- ERC-20 require deployment of separate contracts per token type.
- The ERC-721 standard’s token ID is a single non-fungible index and the group of these non-fungibles is deployed as a single contract with settings for the entire collection.
- ERC-1155 Multi Token Standard allows for each token ID to represent a new configurable token type, which may have its own metadata, supply and other attributes.
- With ERC 1155 Users can create multiple tokens in a single contract and can be used for fungible and non-fungible token use cases.
Specification of ERC 1155
ERC1155 interface.
- safeTransferFrom
- safeBatchTransferFrom
- balanceOf
- balanceOfBatch
- setApprovalForAll
- isApprovedForAll
Events
- TransferSingle
- TransferBatch
- ApprovalForAll
- URI
Smart contracts MUST implement all of the functions in the ERC1155TokenReceiver interface to accept transfers. Safe Transfer Rules as defined by the standard must be followed
Functions:
- onERC1155Received
- onERC1155BatchReceived
