Allocations and vesting

What vesting means when the platform never holds the token — linear, cliff and milestone schedules, how tranches are generated and frozen at purchase, and the manual on-chain work it commits a creator to.

6 min readUpdated 3 August 2026vesting, tranches, allocation, delivery

Vesting splits a buyer's allocation into dated tranches instead of one transfer. A creator switches it on at launch, picks a shape, and every contribution to that offering gets its own schedule.

Before configuring any of it, understand what it is not.

The platform does not hold the token being sold, so there is no internal balance to lock and drip-release. What vesting creates is a dated list of promises: on each tranche date the creator owes an on-chain transfer, they make it from their own treasury, and they record the transaction hash against that tranche.

Nothing unlocks automatically. Nothing is credited to a wallet. If the creator stops sending, the tranches simply sit there marked pending, visible to both sides — and your only lever is escrow you have not yet released.

Two tables carry it. ico_token_vesting is one row per contribution — the whole promise. ico_token_vesting_release is one row per tranche.

Turning it on

Vesting is available to creators unless you switch it off platform-wide.

Let creators deliver a sale in dated tranches instead of one transfer

Duration pre-filled on the launch form when a creator switches vesting on

Turning icoVestingEnabled off blocks new launches from using vesting. It does not touch offerings that already vest, and it does not stop existing schedules — those obligations already exist and cancelling them would strand buyers.

The three shapes

Type	What a creator supplies	Tranches produced
`LINEAR`	A duration in whole months	One tranche per month, equal size, starting one month after purchase
`CLIFF`	A duration and a cliff, both in whole months	One tranche on the cliff date carrying everything accrued up to it, then one per month to the end
`MILESTONE`	A list of `monthsAfterPurchase` / `percentage` pairs	One tranche per milestone, on the month offset given

The validation is strict, and it runs before anything is written — a schedule that cannot be turned into tranches must never reach the database, because it would break the buy button for the whole sale rather than fail one launch.

Durations and cliffs are whole numbers between 1 and 120 months.
A cliff may not be longer than the total duration. With cliff equal to duration, the schedule correctly collapses to a single 100% tranche.
Milestones: at least one, at most 36; each monthsAfterPurchase a whole number from 0 to 120; each percentage above 0 and at most 100; and the percentages must sum to 100, within half a hundredth. They are sorted by date on save, so a creator can enter them in any order.

A milestone at month 0 releases on the day of purchase. That is the usual way to express "20% at TGE, then quarterly".

How the tranches are computed

At purchase, the schedule is materialised against the amount that buyer bought:

Amounts are rounded to eight decimals, the precision the column stores.
Percentages are rounded to two decimals.
The last tranche absorbs all the rounding, on both the amount and the percentage. The tranche amounts always sum to exactly what the buyer bought. Nobody is short-changed or over-paid by a rounding remainder.
Month arithmetic clamps the day of the month. A purchase on 31 January vests on 28 or 29 February, not 2 or 3 March.

Each contribution stores both the config it was bought under and the exact list of tranches, alongside the wallet address supplied and the token symbol.

That means an administrator correcting an offering's vesting terms affects only future buyers. Everybody who has already contributed keeps the schedule they agreed to. It also means there is no screen anywhere that can rewrite an existing buyer's entitlement.

What the creator has to do

For a vesting sale the delivery workflow changes completely.

Wait for a tranche to come due. The hourly cron announces each tranche once, on its date, to both the creator and the investor. The creator's notification carries the amount, the buyer's wallet address and a link straight to the release screen.
Send the tokens on-chain from the project treasury to that address.
Record the hash on /ico/creator/token/<id>/release, against that specific tranche. The hash is format-checked against the offering's blockchain — a full explorer URL is accepted and the hash extracted from it.
Repeat. Once per tranche, per buyer, until the schedule completes.

The schedule's releasedAmount is recomputed from the recorded tranches each time rather than incremented, and the schedule closes itself the moment its last tranche is recorded.

A creator cannot mark a vesting contribution delivered in one go. The route that records a single delivery hash rejects it with:

This contribution vests. Record each tranche on the Vesting tab as you send it, rather than releasing the full allocation here.

Without that guard, one hash would settle an entire multi-year allocation.

When the creator gets paid

The contribution still has to travel PENDING → VERIFICATION → RELEASED for the escrowed money to reach the creator, and that happens on the first tranche, not the last.

Recording the first tranche flips the contribution to VERIFICATION and puts it on your desk. Verify it and the full purchase amount leaves escrow for the creator's wallet — with the rest of the schedule still outstanding.

There is no partial escrow release. Once you verify, the platform is no longer holding anything against the remaining tranches, and the only pressure left on the creator to keep delivering is reputational.

Waiting for the last tranche instead would hold a creator's funds for the entire vesting period, which no project can finance — so this is a deliberate trade, not an oversight. Treat verification of the first tranche of a long schedule as the decision it is, and check the hash on a block explorer before you take it.

Subsequent tranches do not change the contribution's status. They only update the schedule.

Submitting a hash for a future tranche is refused with the date it unlocks. Otherwise the schedule would be a formality — a creator could record all twelve months on day one.

What the investor sees

/ico/dashboard carries a vesting view listing every schedule the user holds: total amount, released so far, the shape, and every tranche with its date, amount, percentage and status.

Tranche statuses are PENDING, RELEASED, FAILED and CANCELLED. A RELEASED tranche shows the transaction hash the creator recorded, so the buyer can verify the transfer themselves on a block explorer — which is the only verification that exists, because the platform never checks a hash against a chain. It only checks its shape.

Cancellation

A vesting schedule is withdrawn whenever the contribution behind it is undone — a rejection, a manual refund, or a failed sale. Every pending tranche is marked CANCELLED with the reason, and the schedule itself is cancelled.

Left alone, those tranches would keep telling the creator to send tokens for money that has already gone back to the buyer.

The hourly sweep is a safety net for the same thing: schedules whose contribution has disappeared or been handed back are cancelled, and schedules past their final tranche date with everything settled are closed.

Advising a creator

Vesting is the right answer for a project that wants to avoid a day-one sell-off. It is the wrong answer for a project without the operational discipline to make hundreds of transfers a month for a year.

Do the multiplication before you approve. A twelve-month linear schedule with 200 buyers is 2,400 transfers and 2,400 hashes to record. A quarterly milestone schedule with four milestones is 800. The second is a job; the first is a department.