The ERC20 standard is one of the most known standard in the Ethereum ecosystem. It provides basic functionality to create and transfer the fungible tokens. But here I don’t want to focus on the details of ERC20 standard and a way how to implement it, because on the Internet there is a plenty of that kind of information. I would like to focus on the extension that we can add to the vanilla ERC20 standard to make it more fitted to the various different use cases.
Extensions
All extensions that I will describe here come from the OpenZeppelin’s github.
ERC20Burnable
The standard ERC20 implementation has only internal function _burn, which is not used in any implemented function. This extension give us two new public functions: burn and burnFrom. Both of them allow token holders to their own tokens and the tokens that they have an allowance for. If token holder will burn tokens by one of these functions, there will be emitted the event Transfer, which will be recognized off-chain.
ERC20Capped
This extension give us one small additional function — it set upper limit of the amount of minted tokens. Simple, isn’t it? Aaa, did I mention that this limit is immutable? So, if you once set the value, there is no chance to change it.
ERC20FlashMint
This one is very interesting. It’s implementing of the ERC3156 FlashLoan extension. Thanks that our contract creating tokens also is able to give flashLoan, what with adding non-zero fee of the loan makes our token deflation. But by default, the fee is set to zero.
Let’s check how it works step by step. When someone would like to borrow tokens from our contract, there is a need to use a flashLoan function. The arguments of this function are:
- the address of the contract where the tokens should be transfer
- the address of the token that he want to borrow
- the amount, how much of them he wants
- additional data, that will be sent to the receiver’s contract
When the amount will be not greater than the maximal amount of token available for loan, the contract will mint as many tokens as someone want to borrow. Then the contract call the function onFlashLoan from the receiver’s contract. It’s the space when the borrower uses the borrowed money. At the end, the onFlashLoan function has to return bytes32 value equal to keccak256(“ERC3156FlashBorrower.onFlashLoan”). When everything went right, the contract at the end will burn all previously minted tokens.
ERC20Pausable
This extension implement to the standard ERC20 contract the emergence stop mechanism, that could be fired by authorized address. It’s made by adding two new modifiers: whenNotPaused, whenPaused and by modifying the _beforTokenTransfer function from ERC20. This modifying pause the work of the _transfer, _mint and _burn.
This extension is useful in the scenario when we would like to stop all transfer of tokens during the evaluation process or when will be found a critical bug in the code. It’s just an emergence big red button, that pause working everything.
ERC20Snapshot
Giving access to the efficient storage of past token balances and total supply. By using this extension, we are able to create safe mechanism based on the amount of token or create efficient ERC20 forking system.
How does it work? Similarly to the ERC20Pausable, the _beforTokenTransfer function is changed. Here always before transaction, the contract call function _updateAccountSnapshot that save our current amount of tokens and also this function is changed to save current balance of the address where we send tokens. If we mint or burn tokens, the function to update the total supply amount is fired. All snapshots have their own id number that we can use to find that we are looking for.
ERC20Permit
Next very interesting extension of standard ERC20. The main reason why it exists is allowing to token holders transfer their own ERC20 tokens without having the Ether. This improvement could significantly improve the user experience of using tokens.
How do we avoid the necessary of paying in Ether? The answer is off-chain signing the approving transaction. What do I mean by that? This extension adds new function permit. This function allows users to modify the allowance mapping using a signed by them message, instead using msg.sender as always we do. As a result, we are able to make it off-chain and avoid the obligatory to pay in Ether. It sounds great, doesn’t it?
ERC20Votes and ERC20VotesComp
Here we have two similar extension. Both of them allow use ERC20 as a token to vote. They track the votes and allow for vote delegation. The mechanism of voting propose by these extensions are simple, the voting power of each account is connected with possessing this token. Moreover, to prevent double voting, both of them use something similar to the snapshot extension described previously. The extensions track the historical balances of each account, so there is possibility to retrieve voting power from the past. The small drawback of these extensions is the need of making minimum one transfer to record account balance in the snapshot and to get the voting power.
So where is the difference between these extensions? The difference is in the limit of the token supply. The ERC20Votes support supply bigger than 2⁹⁶, which is the upper limit of the ERC20VotesComp, and thanks that it is more flexible. Why is there so upper limit in the ERC20VotesComp? This extension fits to the interface of the COMP token used by GovernorAlpha and GovernorBravo.
ERC20Wrappper
It’s a simple extension that allow to change one ERC20 token to another (wrapped tokens). We can define how many tokens of the first type is equal to one token of the second type. Typically, this number is equal to 1. In this extension, the sender sends an amount of token which is deposit in the smart contract, and a matching number of the wrapped tokens are sends to the sender. When he would like to get back his tokens, he simply has to deposit wrapped tokens to this contract. This is useful in conjunction with other modules, like voting.
ERC4626
It’s a tokenized standard of vault, but what is the vault? Vault is the smart contract where can you deposit your token, and then the vault do something with this token to provide the token rewards. It’s a multi-sig contract that can manage and store crypto. Each vault always has the token that is generated as a return. These generated tokens could be exchange to the deposited tokens, so to the tokens that were locked in the vault. Vaults are more secure than wallets, and therefor many DeFi project use it to deposit their funds. These standard is compatible with the ERC20, therefor I wrote it here like an extension.
ERC4626 is important, especially for DeFi, because before this standard there was used many different approaches to store and manage of assets. And by these reason, it was very problematic to connect different project to each other. It was time-consuming and with a big risk of security gap. Moreover, the solution that fitted to one pair of DeFi project didn’t have to fit to the other pair. Thanks ERC4626 the work is faster and more secure.
ERC20 utils
In OpenZeppelin’s library, inside the catalog devoted to ERC20 is also a catalog named ER20 utils. When we open it, we will find two contracts that aren’t the extensions of the ERC20, but they give an additional feature.
SafeERC20
Not all developers use standard ERC20 token, but they use custom version of ERC20 interface implementation which sometimes doesn’t return boolean return value. When we would like to create smart contract that will be works with this kind of tokens, there could be some problems, bugs etc. To prevent it, we can use SafeERC20 (it’s a library) function to manage all tokens. Additionally, SafeERC20 provides helpers to increase and decrease allowance, to mitigate a possible attack with vanilla approve.
TokenTimelock
I think it is one of the simplest contract described here. It’s a token holder contract that won’t allow the beneficiary to get money out from it before the set release time. When the set time gets past, the beneficiary will be able to use the function to send to him all tokens. And it’s the all, this contract doesn’t make anymore.
Summarize
As we saw, the ERC20 has a lot of different extensions, that give possibility to fit this token standard to our purposes. Voting, flashLoan, vault etc.
I hope you find this post useful. If you have any idea, how could I make my posts better, let my know. I am always ready to learn. You can connect with me on LinkedIn and Telegram.
If you would like to talk with me about this or any other topic I wrote, feel free. I’m open to conversation.
Happy learning!
New to trading? Try crypto trading bots or copy trading
