Creating constructor values for TokenVesting contract

Support Contracts
1

Understanding what values need to be put in the constructor.
:computer: Environment

Remix, Solidity 0.5.0
:memo:Details

I want to understand exactly the constructor values when using TokenVesting contract.

address beneficiary: I assume this is where the Tokens will be released to once vesting starts so it can be address of another wallet not necessarily the owner address that deployed TokenVesting contract? Person that will receive the Tokens once the vesting starts.

uint256 start: The start of the contract time? not sure about this one

uint256 cliffDuration: The duration of the cliff between the contract start time and the start of the vesting correct?

uint256 duration: How long the token vesting should last? not sure about this one either

bool revocable: what does this mean? I know we have to put a true or false value but what is this trying to achieve?

could you please explain in more details about all those points? because I assumed things, when I read the OpenZeppelin TokenVesting contract it doesn’t explain clearly those points. It needs more explanation.

Could you also verify if this scenario is correct:

Token locked from today for the period of 3 months, then vesting for a period of 3 months.
uint256 start: 1586388558 (current time using unix timestamp)
uint256 cliffDuration: 1594166400 (9th July 2020) - 1586388558 = 7777842
uint256 duration: 7777842 (The duration from the cliff end to the tokens fully vested, in this scenario its 3 months so it matches the cliff duration)

*What about how its vested? for example 25% of the locked tokens then 25% etc…
*How tokens will be locked in this contract I assume by sending tokens from any wallet address? of course they have to be ERC-20 tokens. Or do they have to be sent from the TokenVesting contract owner wallet specifically?

please check the example and let me know if its correct.

Thank you in advance!
:1234: Code to reproduce

pragma solidity ^0.5.0;

import "https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.0/contracts/drafts/TokenVesting.sol";

contract TestVesting is TokenVesting {
    constructor(address beneficiary, uint256 start, uint256 cliffDuration, uint256 duration, bool revocable) public 
        TokenVesting(beneficiary, start, cliffDuration, duration, revocable) {
    }
}
1 Like
2

Hi @ETHERC20,

You may also want to look at TokenTimelock which is simpler.

Good places to find information on how to use TokenVesting is
The documentation: https://docs.openzeppelin.com/contracts/2.x/api/drafts#TokenVesting

The contract: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/drafts/TokenVesting.sol

The tests for the contract: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/test/drafts/TokenVesting.test.js

The contract has the following comment for the constructor parameters which should answer some of your questions.

     * @param beneficiary address of the beneficiary to whom vested tokens are transferred
     * @param cliffDuration duration in seconds of the cliff in which tokens will begin to vest
     * @param start the time (as Unix time) at which point vesting starts
     * @param duration duration in seconds of the period in which the tokens will vest
     * @param revocable whether the vesting is revocable or not

With regards revoke Allows the owner to revoke the vesting. Tokens already vested remain in the contract, the rest are returned to the owner.

Typical vesting schemes could be a cliff period of a year and a duration of four years.
In your example, you could have a cliff of 3 months and a duration of 6 months. (Otherwise if all tokens vested after 3 months, you could just use TokenTimelock).

For the vesting calculation, see _vestedAmount function: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/drafts/TokenVesting.sol#L162
In summary, zero tokens are available for release until the cliff has been reached, then a proportion of the tokens can be released based on the current time and the vesting duration, taking into account any tokens already released.

ERC20 tokens can be sent from any address, and they need to be ERC20 tokens.

I suggest trying it out on a testnet with a start of now, a cliff of ten minutes and a duration of 30 minutes, then transfer some ERC20 tokens.

If you want to use this in production, your solution should have appropriate testing and auditing.

1 Like