ERC20 token lock-up status
Most blockchain companies have already released digital currencies. In order to reflect the confidence and determination of the team, the white paper will mention that the tokens held by the team should be locked (add a freezing period to the tokens, usually 1-4 years) .
But in the end, did these tokens really lock up? Who will supervise the lock up?
Judging from the current release of ERC20, the lock-up mentioned in most of the domestic ERC20 token white papers is not reflected in the smart contract, but the team self-restrains to realize the human flesh lock-up, which is obviously very unscientific.
Lock positions through smart contracts
The scientific lock-up method is of course realized through smart contracts, which is the best way to be more credible, open, and non-collaborative
The basic idea of technical realization is as follows
- Release ERC20 token smart contract
- Configure the parameters of the hedging contract and release the smart contract for hedging
- Transfer the ERC20 tokens to be locked into the locked smart contract
1, 3 is relatively simple This article will not cover, the key is 2, how to write a smart contract for hedging.
Currently there are two types of smart contracts for lock-up
The following two lock positions are introduced separately
1. TimeLock locking method
Code reference: ERC20/TokenTimelock.sol
The contract accepts 3 parameters
- ERC20Basic _token: The ERC20 contract address of the locked position
- address _beneficiary: the contract address of the beneficiary
- uint256 _releaseTime: lock-up time (in seconds)
This TimeLock locking method is concise and clear
After the _releaseTime is up, calling release() will release the token to the _beneficiary account.
However, the TimeLock method has limitations
For example, the demand is: lock the warehouse for 4 years, unfreeze 25% at a time after 1 year, and then unfreeze linearly according to time.
Such a complex lock position requires TimeLock to be unsolvable, and Vesting is needed at this time.
2. Vesting lock-up method
Code reference: ERC20/TokenVesting.sol
The Vesting lock-up method mainly solves the lock-up scenarios with cliff time and continuous lock-up time.
Contract initialization accepts 5 parameters
- address _beneficiary: beneficiary address
- uint256 _start: start time
- uint256 _cliff Cliff means one year in " warehouse for 4 years, and unfreeze 25% at a time after 1 year"
- uint256 _duration, continuous lock-up time
- Whether bool _revocable is recyclable (the main scenario is that the company gave employee A 10K tokens to lock the warehouse for 4 years, and A resigned after working for a year, and whether the remaining part of the company is recyclable)
To make it easier to understand _cliff, let's look at the following example
If _cliff=half a year, _duration=1 year, the specific thawing situation is as follows
- Month 1: I get 0 tokens
- Month 2: I get 0 tokens
- Month 3: I get 0 tokens
- Month 4: I get 0 tokens
- Month 5: I get 0 tokens
- Month 6: I get 0 tokens --- End of cliff
- Month 7: I get 700 tokens (7/12th)
- Month 8: I get 100 tokens (8/12th)
- Month 9: I get 100 tokens (9/12th)
- Month 10: I get 100 tokens (10/12th)
- Month 11: I get 100 tokens (11/12th)
- Month 12: I get 100 tokens (12/12th)
In this way, the requirements we mentioned above are achieved through _cliff
The above is the implementation principle of ERC20 lock-up that I shared. I hope to help you understand ERC20 tokens and Ethereum smart contracts better.