How Token Vesting Works on Robinhood Chain

Token vesting releases a grant gradually over time instead of all at once on a single date. Titan Locker vests ERC-20 tokens linearly between a start and end time, with an optional cliff before which nothing is claimable - and once created, the schedule is irrevocable: it cannot be changed, paused, or clawed back by anyone, including the grant's creator.

The vesting formula

The lock contract computes the vested amount at any timestamp with exactly this rule:

vested(t) =
  0                                    if t < cliff
  total                                if t >= end
  total * (t - start) / (end - start)  otherwise

Nothing is claimable before the cliff. At the cliff, everything vested up to that point becomes claimable at once, then accrual continues linearly toward the end date. From the end date onward, the full amount is vested.

Cliff vs. no cliff

A cliff is optional - leave it blank (equal to the start date) for pure linear vesting from day one. Set it later than the start for the common team-grant pattern: nothing releases for, say, the first 3 months, then the already-accrued portion unlocks at once and the rest continues vesting linearly to the end date.

Step by step: creating a vesting schedule

Open Titan Locker's Create page, switch to "Vesting schedule", select the token and amount exactly as for a token lock, then set start, an optional cliff, and end. The form enforces start < end and start ≤ cliff ≤ end before letting you continue.

Claiming vested tokens

There's no single unlock gate to wait for - instead, the owner calls release() at any time, which sends the vested-but-unclaimed amount and can be called repeatedly as more vests. The contract also exposes releasable(), a read-only check of exactly how much is claimable right now, which the lock's own certificate page shows.

Irrevocability - why it can't be undone

This is a deliberate design choice, not a missing feature. A vesting grant that could be revoked or edited by its creator isn't meaningfully different from a promise - the entire point is giving the recipient (and anyone watching) a guarantee enforced by the contract, not by whoever created the grant. There is no function on the lock contract that reduces, cancels, or reschedules a vesting grant once created.

Vesting locks can't be extended, unlike plain locks

A plain token lock's unlock time can be pushed later after creation. Vesting locks are the one lock kind that explicitly cannot - the contract's extend function rejects vesting locks outright. The schedule you confirm at creation is permanent in every respect, not just the total amount.

Fee-on-transfer tokens and vesting

releasable() never reports more than the lock contract actually holds - it returns the smaller of the ideal vested-and-unreleased amount and the real token balance. That protects against a fee-on-transfer or rebasing token causing an over-release; it also means such a token's holder may see the schedule's nominal math slightly outpace what's actually claimable at the tail end.

Risks and limitations

• The schedule and total amount are fixed at creation - there is no way to top up, pause, accelerate, or shorten a vesting grant afterward, and unlike plain locks, not even the unlock time can be extended.
• No admin can revoke a grant even if circumstances change (e.g. a team member leaves) - that guarantee is the point, but it means there's no recourse built into the contract for that scenario.
• Only the current lock owner can call release() - if ownership is transferred, claiming rights transfer with it.
• Double-check start, cliff, and end before confirming; there is no edit function afterward.

Related resources