Vesting Schedules: Are ICOs Actually Enforcing It?

Disclaimer: The information presented here on vesting schedules offered by this article should not be considered as investment advice. It may not be suitable for all investors. If you have any doubts as to the merits of an ICO, you should seek advice from an independent financial adviser.

Special thanks to Rene Fuchtenkordt for being able to explain the technical details.

What is a Vesting Period?

A vesting period is a period of time before shares in an employee stock option plan or benefits in a retirement plan are finally owned by employee.

Think of this as a lockup period before the founders or employees are able to do anything with those allocated shares (ie. claim, transfer, or dump on the secondary exchange).

You can also think of this vesting period as a contract written by lawyers to ensure that founders and employees alike are motivated enough to reach milestones on their projects that are funded by external investors.

Traditional companies would have three types of vesting schedules:

• Immediate vesting: Just as the name implies, employees with this type of vesting plan gain 100% ownership of their employer’s, matching money as soon as it lands in their accounts.
• Cliff vesting: Cliff vesting plans transfer 100% ownership to the employee in one big chunk after a specific period of service (for example, one year). Workers have no right to any of their matching contributions if they leave before that period expires. But the day they reach the landmark date, they own it all. Federal law requires that cliff vesting schedules in qualified retirement plans such as a 401(k) or a 403(b) not exceed three years.
• Graded vesting: Graded vesting gives employees gradually increasing ownership of matching contributions as their length of service increases, resulting in 100% ownership. For example, a five-year graded vesting schedule might grant 20% ownership after the first year, then 20% more each year until employees gain full ownership (100%) after five years. If the employee leaves before five years are up, she gets to keep only the percentage of the employer’s matching contributions in which she is vested. Federal law sets a six-year maximum on graded vesting schedules in retirement plans.

Basically, each vesting schedule implies different duration of how long your shares are with the company for. In a startup, most scenarios require a vesting period with a minimum of a one-year cliff with an upwards of 5–10 years before you are able to receive all the allocated shares.

What about ICOs?

Check out our previous blog to learn more about ICOs, how to identify the good ones from the scams and more.

In this predicament where hundreds of people invest small amounts of capital at different times, the process of having lawyers write contracts for each investor makes this process very redundant, tedious and expensive.

Luckily, with the emergence of smart contracts, vesting statements can be enforced automatically. the amount of individual investors and money received can all be handled through a couple lines of code.

When looking at an ICO that is having their crowdsale, you can also your own research in determining their vesting schedules.

Note: Since we are talking about vesting structures only for this and not about total allocations, it’s also important to understand that without vesting periods, the team would essentially have a liquid 45% of the tokens after the sale. This would be very scary in the eyes of the public sale investor as the founders could easily liquidate all their shares on the exchange if the team had malicious intentions.

You should always check the whitepaper or the website to see if the project has a vesting period.

1. Read the Whitepaper and Crowdsale Details

You should always check the whitepaper or the website to see if the project has a vesting period. We can use Nucleus Vision as an example.

In the whitepaper on page 52 it states that:

“25% of the tokens will be allocated to the founding Nucleus Vision team […]. The team tokens will be locked in a smart contract with a 24-months vesting period and six-months cliff.”

The token supply is 10 billion nCash, so 2.5 billion nCash goes to the team over 2 years. So we have two tranches of 1.25 billion nCash with a cliff of 6 months.

From the whitepaper:

Vesting length = 24 months

Cliff length = 6 months

The private sale started in November 2017, the vesting period should start somewhere around this date :

Start date = November 2017

Transform our dates into timestamps suitable for programming.

2. Transform the Dates

Before we can check the blockchain, we need to transform our dates into timestamps suitable for programming:

Human readable dates are impractical to use in code, so dates are transformed into either seconds or milliseconds passed since the so called unix epoch. The epoch is defined as 1st of January 1970 midnight GMT. A unix timestamp is expressed by milliseconds passed since the epoch (1st of January 1970).

Timestamps on the solidity documentation: [link]

block.timestamp (uint): current block timestamp as seconds since unix epoch

Note: Vesting duration and cliff are to be measured in seconds on the Ethereum Blockchain.

Transform months to seconds: [link]

Vesting length = 24 months = 63.070.000 seconds

Cliff length = 6 months = 15.770.000 seconds

Transform date to Unix Timestamp: [link]

Start date = 1st of November 2017 = 1509494400

now that we have the times we are looking for, we can check the event log.

3. Event Log on the Smart Contract

We need to look for a reference for our dates in the nCash Smart Contract. nCash is an ERC20 Token so it lives on the Ethereum blockchain so let’s begin.

Search for Ncash’s smart contract (Nucleus Vision) on https://etherscan.io[Link]

This is the contract that is responsible for creating and managing the tokens. The contract holds all information about which addresses own the tokens and how many.

The token holders tab shows us a list of all token owners. Note the two addresses on top, each owning 25% and 21% of the total token supply respectively. It’s safe to assume that these are the team and company reserve tokens stated in the Nucleus whitepaper. It appears that they have liquidated 4%, and this is consistent in their whitepaper for liquidating small amounts to get work done.

one has 25% and the other probably had a small liquidity event resulting in that 21%

Under TokenTracker Summary click on “ERC Contract” [Link]

Every smart contract has an owner. This owner can either be a wallet tied to an individual (person) or the smart contract itself. Its recommended that ICOs have it so the owners are the smart contract itself because it defers the responsibility of a bad actor as we are only acting on code. Therefore we need to check if the supply is locked by any sort of vesting mechanism.

Go to Misc > Contract Creator and click the first [Link]

we see the owner contract. Instead of auditing the whole code (rule of thumb should be quicker than a whole audit) so we can search for the vesting section only.

Click on the Events tab [Link]

All internal transactions within the smart contract can be seen here. We’re looking for a method that says vesting.

The first event in the log says:

NucleusVisionTimeVestingTokensMinted (address beneficiary, uint256 tokens, uint256 start, uint256 cliff, uint256 duration)

This looks promising. What we see here is that a function named:

NucleusVisionTimeVestingTokensMinted

was called, and that it received five parameters:

address beneficiary

uint256 tokens

uint256 start

uint256 cliff

uint256 duration

That is the data we are looking for.

The values are stored as hexadecimal, but etherscan can translate them for us.

Set correct variable type in the dropdown next to the parameter.

This is the variable types in the dropdown menu

The right ones are:

Address

Number

Number

Number

Number

Now we know what the variables contain

mintTokensWithTimeBasedVesting(address beneficiary, uint256 tokens, uint256 start, uint256 cliff, uint256 duration)

address beneficiary = [0x356df211c92d53a4e0ccfdd3125e87e8e570ef14](https://etherscan.io/address/0x356df211c92d53a4e0ccfdd3125e87e8e570ef14)

uint256 tokens = 2,5e+27

uint256 start = 1511481600

uint256 cliff = 15552000

uint256 duration = 63072000

To get the token value we have to deduct the decimals defined in the ERC20 contract:

Calculate the correct token amount [link]

uint256 tokens = 2,5e + (27 — 18) = 2,5e+9 = 2.500.000.000

The token supply matches the 25% proposed as team supply in the whitepaper.

Why “-18” ?

Note that an ERC20 contract defines decimals for the token supply, in case of nCash it is 18. So we have to deduct this from the value stored in the variable to get the correct number. From Stackexchange:

If I want 1 token with the ability to subdivide it with a precision of 2 decimal places, I represent that as 100.

tokenSupply = tokensIActuallyWant * (10 ^ decimals)

➡️ Transform Unix Timestamp to date: [Link]

uint256 start = 1511481600 = 24/11/2017

So the vesting started on the November 24th

uint256 cliff = 15552000 (seconds) = 6 months

uint256 duration = 63072000 (seconds) = 24 months

We can now calculate the exact vesting period

Use https://www.timeanddate.com/date/dateadd.html to add the dates:

Vesting start = 24/11/2017

Payout starts = 25/05/2018

Payout ends = 25/04/2020

We now know that the owner contract vesting function was initialized with the correct values. Now we can check with our supplied parameters what the function does.

4. Check the Code

We o_pen the code tab:_t logs that we are looking for \NucleusVisionTimeVestingTokensMinted in the contract

➡️ O_pen the code tab:_ [Link]

The smart contract is what controls the value flow and once active, it will never be stopped or updated once. We’re looking at a very critical code piece here, and the correct code comment is a must. That means you should be able to understand what occurs without coding knowledge. If the code isn’t correctly commented, you found the red flag.

Fortunately, in our case it is well done.

Press cmd+f (ctrl +f) and search for NucleusVisionTimeVestingTokensMinted

/**

* event for time vested token mint logging

* @param beneficiary who is receiving the time vested tokens

* @param tokens amount of tokens that will be vested to the beneficiary

* @param start unix timestamp at which the tokens will start vesting

* @param cliff duration in seconds after start time at which vesting will start

* @param duration total duration in seconds in which the tokens will be vested

*/

event NucleusVisionTimeVestingTokensMinted(address beneficiary, uint256 tokens, uint256 start, uint256 cliff, uint256 duration);

This is the event that we saw in the event logs. Events can be triggered by functions:

// member function to mint time based vesting tokens to a beneficiary

function mintTokensWithTimeBasedVesting(address beneficiary, uint256 tokens, uint256 start, uint256 cliff, uint256 duration) public onlyOwner {

require(beneficiary != 0x0);

require(tokens > 0);

vesting[beneficiary] = new TokenVesting(beneficiary, start, cliff, duration, false);

require(token.mint(address(vesting[beneficiary]), tokens));

NucleusVisionTimeVestingTokensMinted(beneficiary, tokens, start, cliff, duration);

}

This function checks that:

require(beneficiary != 0x0);

Beneficiary has an address that is not 0.

require(tokens > 0);

Vested token amount is bigger than 0.

vesting[beneficiary] = new TokenVesting(beneficiary, start, cliff, duration, false);

New instance of token vesting contract is created with the beneficiary address

require(token.mint(address(vesting[beneficiary]), tokens));

Check if beneficiary is registered

event NucleusVisionTimeVestingTokensMinted(beneficiary, tokens, start, cliff, duration);

Fire vesting event

That is how the event logs are created. From Stackexchange:

Each transaction has an attached receipt which contains zero or more log entries. Log entries represent the result of events having fired from a smart contract.

Now there is a separate function that checks the saved times against the current time, to determine if and how much should be payed out:

function vestedAmount(ERC20Basic token) public view returns (uint256) {

/**
   * [@dev](http://twitter.com/dev) Calculates the amount that has already vested.
   * [@param](http://twitter.com/param) token ERC20 token which is being vested
   */
  function vestedAmount(ERC20Basic token) public view returns (uint256) {
    uint256 currentBalance = token.balanceOf(this);
    uint256 totalBalance = currentBalance.add(released[token]);

if (now < cliff) {
      return 0;
    } else if (now >= start.add(duration) || revoked[token]) {
      return totalBalance;
    } else {
      return totalBalance.mul(now.sub(start)).div(duration);
    }
  }
}

Notice that now is an alias for block.timestamp which we discussed earlier

if (now < cliff)

Check if we are still before the cliff period

(now >= start.add(duration) || revoked[token])

Check if we are still before the vesting period

else { return totalBalance.mul(now.sub(start)).div(duration); }

If we are in the vesting period, return the amount of tokens relative to the passed time (e.g 50% after 1 year, 100% after 2 years)

Note that instead of having fixed tranches of say one year, the vested amount is paid out gradually

Since this is not a security audit, let’s ignore the rest of the code for now.

The parts we’ve discussed showed us that the correct data has been written on the blockchain, we also gained an insight into the internal mechanisms of the vesting functions.

Conclusion:

This portion was lengthy, but it should give you a great insight into the lengths of the due diligence process before investing into certain projects. Vesting periods are just one of the checks that are active when we are looking for projects to invest in.

This ecosystem is still very early stage, and while there are gradually some great projects coming out, we should be vigilant in identifying the scams in the market.

And this is why we have built a research platform for you to have an initial check before you dive deep into the vesting schedule…

We realized that we had the same problem that investors had performing their ICO research. Information can be scattered everywhere, and it was impossible to know if an ICO was honest or just a downright scam.

Try out our Basescore platform at https://basescore.co.

What is Basescore?

We have built an ICO reviews platform called Basescore to help you stay on top of ICOs and tokens. We do things a little differently; we aggregate ICO review scores and more from the leading ICO critics to give users a singular, weighted Base Score that truly reflects how an ICO actually fares.

Call us the “Metacritic of ICOs”. We’ve aggregated over 7,000 ICO reviews under one roof. We’re building the world’s biggest ICO database to serve investors with truth and transparency, and we’re making it happen right before your eyes. Learn more on Basescore today.

• Website: https://basescore.co/
• Facebook: https://www.facebook.com/basescore
• Twitter: https://www.twitter.com/basescore
• Reddit: https://www.reddit.com/r/basescore
• BitcoinTalk: https://bitcointalk.org/index.php?topic=5026116.msg45509802#msg45509802
• Email: support@basescore.co

Sign Up For Our Mailing List

We periodically send out information on the top recent ICOs, educational pieces and more. We aggregate the best data for you to read, so you don’t have to. Sign up here.