GuideCapital Raising & Tokenomics
How to design a token vesting and release schedule
A vesting schedule decides when each group of holders can first move its tokens, and therefore when supply can reach a market. Designing one well means starting from the allocation table, projecting circulating supply month by month, finding where releases cluster and spreading them out, and checking that emissions and staking rewards do not drain the treasury. This guide works through each step, with an illustrative schedule and the assumptions to write down.
On this page
- What a vesting schedule can and cannot do
- Building the monthly circulating-supply projection
- Cliff-and-linear, linear-from-launch and milestone release
- An illustrative schedule, worked through
- Finding release clusters and spreading them out
- Matching token vesting to equity vesting
- Emissions, staking rewards and the treasury runway
- Assumptions to write down for counsel and investors
- Vesting mistakes that surface after launch
- Questions and answers
- Sources
What a vesting schedule can and cannot do
A schedule does two jobs: it keeps the people building a network committed long enough to deliver it, and it controls how quickly tokens allocated before launch can reach a market. Done well, it shows later holders how much supply each group could sell, and when.
Vesting and release are different events. Vesting is when a holder earns tokens, usually by staying with the project; release is when earned tokens become transferable, often enforced by a smart contract or custodian. A contributor may vest monthly yet stay locked until a network milestone, while an investor's tokens may be earned at purchase yet locked for a period.
No schedule creates demand. Vesting manages the timing of supply; the reasons to hold come from the token's use, and agent-based simulation is where those reasons get tested.
Building the monthly circulating-supply projection
One row per allocation bucket, one column per month, running several years past the token generation event (TGE).
List every allocation bucket
Typical buckets are team, investors, foundation treasury, community incentives, liquidity and advisers. Give each a size, a holder type and a written reason to exist; a bucket nobody can explain is usually a reserve that will be spent without a plan.
Decide what is transferable at the TGE
Liquidity and some community tokens usually must be; team and investor tokens usually are not. Their sum is the initial circulating supply, the base against which every later release is judged.
Apply cliffs
A cliff is a period with no release, ended by a catch-up of everything that accrued during it. Record the cliff length and the catch-up size separately, because the catch-up is what produces a spike.
Apply the release curve
After any cliff, tokens usually release linearly by month or block; some buckets use milestone triggers. Write the formula, not just totals, so anyone can reproduce any month's figure.
Add emissions and rewards
Tokens created after launch, such as staking rewards, add to circulating supply without belonging to any pre-launch bucket. Model them from their own rules on a separate row.
Sum, chart and flag
Total each month, chart supply and the monthly change, and flag every month in which releases exceed an agreed share of what already circulates. Those flags are your release clusters.
Cliff-and-linear, linear-from-launch and milestone release
| Question | Cliff then linear | Linear from TGE | Milestone-based |
|---|---|---|---|
| How release works | Nothing for a set period, a catch-up, then equal monthly amounts | Equal amounts from launch | Tranches release on a defined event, such as mainnet launch |
| Shape of potential selling | A step at the cliff, then steady | Steady from the start | Hard to predict; can coincide with good news |
| Usually suited to | Team and early investors, mirroring equity vesting | Community programmes that need tokens in use early | Foundation reserves or grants tied to delivery |
| Main weakness | Large catch-ups when the cliff is long | Little retention effect for contributors | Disputes over whether the milestone was met |
| What to document | Cliff length, catch-up size, leaver treatment | Start date, duration, any staking lock | Milestone definition, verifier, fallback date |
Most schedules combine all three across buckets. Choose per bucket rather than applying one convention everywhere.
An illustrative schedule, worked through
Finding release clusters and spreading them out
A cluster is a month in which scheduled releases are large relative to what already circulates. A release that is small against total supply can be large against a thin early float, so measure each month's releases against the previous month's circulating supply, and note who receives them: a fund managing its exit timetable behaves differently from a contributor who also holds equity.
The remedies are simple. Offset cliffs so first releases fall in different months. Replace a catch-up with a linear start where the holder's rights allow. Lengthen release periods for the largest buckets. Tie part of a reserve to a milestone with a fallback date. Agree all of it before investors sign, because changing an investor's lock-up afterwards usually needs their consent. Then publish the schedule: one that is disclosed and kept is easier to defend than one that is discovered.
Matching token vesting to equity vesting
When a company has shareholders and a token, the two schedules interact.
- If
Team members hold both shares and tokens.
ThenUse the same start date, cliff and leaver treatment for both, unless there is a documented reason to differ.
Different rules for the same person invite disputes when someone leaves between two cliffs.
- If
Equity investors received token rights through a warrant or side letter.
ThenLock their tokens at least as long as the token investors' tokens, and show the bucket in the allocation table.
Otherwise equity investors can become the earliest sellers, which later buyers will notice.
- If
A key hire joins after the TGE.
ThenGrant tokens on a fresh schedule from a reserved team pool.
Topping up from the treasury makes the allocation drift from what was published.
- If
A contributor leaves before the cliff.
ThenReturn unvested tokens to a bucket named in the grant terms.
Returned tokens with no destination tend to be spent informally.
Emissions, staking rewards and the treasury runway
Emissions are often treated as free because no cash leaves the company. They are not: rewards either come from a pre-allocated bucket, reducing what the treasury can spend on development, or are newly created, diluting every holder. Either way they belong in the runway model as spending, valued across a range of token prices.
Compare the month each reward or incentive bucket runs dry with the month the treasury bucket starts releasing. If staking rewards end in year three and the treasury stays locked until year four, the schedule has a gap that needs an explicit funding source agreed in advance. Testing runway under price paths is covered in agent-based simulation.
Assumptions to write down for counsel and investors
Vesting mistakes that surface after launch
The deck and the contracts show different schedules
Early signalHolders compare published release dates with on-chain lock parameters and find differences.
MitigationGenerate the deck chart, disclosure figures and contract parameters from one table, and reconcile them before launch.
Milestone releases with no clear verifier
Early signalArgument over whether a milestone was met delays or brings forward a release.
MitigationDefine each milestone measurably, name who confirms it and set a fallback date.
Staking treated as permanently removed supply
Early signalCirculating supply rises faster than projected when staking yields fall.
MitigationModel staked tokens as their own state with exit rules, not as tokens that never return.
Questions and answers
How long should team tokens vest?
There is no single correct length. Team token vesting commonly mirrors equity vesting, a multi-year schedule with an initial cliff, so contributors earn tokens on the same timetable as shares. A better test is the roadmap: the schedule should run past the point at which the network should work without its founders. Apply the same leaver rules to tokens and shares.
Should investors' tokens be locked for longer than the team's?
Not necessarily. What matters more is that the two groups' first releases do not land in the same month and that neither can release a large share of circulating supply at once. Investors usually accept lock-ups that reflect their entry point and price; contributors need longer schedules because vesting also serves retention. Agree investor lock-ups before signing, since changing them later typically requires consent.
Can a vesting schedule be changed after launch?
Sometimes, at a cost. Contractual lock-ups usually need the affected holders' consent, smart-contract locks may need a governance vote or a contract migration, and changing a published schedule can trigger disclosure duties. In the EU, a significant new factor during an offer or while the token trades requires a modified white paper1. Testing the schedule before launch is far cheaper than renegotiating it afterwards.
Does the schedule matter before the token trades?
Yes. Investors and counsel assess it during the raise, any white paper describes the tokens the issuer retains and its future offers, and the schedule decides how quickly supply reaches markets once trading begins. Designing it after trading starts means designing it under pressure.
Sources
- Regulation (EU) 2023/1114 on markets in crypto-assets (MiCA), Article 12 — EUR-Lex · checked 10 October 2026