Token Vesting & Locking
Schedules, cliffs, and claims that operators can actually run.
What it is
Create vesting for one beneficiary or a thousand. Visualize unlocks. Claim, revoke, extend — in a project-grade console.
Vesting schedules, cliffs, and claims that an operator can actually run — for one beneficiary or a thousand.
The public Console runs this module on fabricated data. Nothing there is signed or broadcast.
Who it is for
Team lockups
Employee and founder allocations with a cliff, enforced by contract rather than by policy.
Investor vesting
Round-specific schedules with statements a beneficiary can check without asking finance.
Treasury emissions
Scheduled treasury release so circulating supply changes predictably.
Advisor and contributor grants
Smaller allocations managed in the same register instead of ad-hoc transfers.
How it works
- 01Select the tokenSchedules are created against the project's token, not a free-text field.
- 02Add beneficiariesEnter one, or import a cohort by CSV with validation on addresses and amounts.
- 03Set the scheduleTGE release, cliff, duration, and unlock frequency — the four parameters that define behaviour.
- 04Review the curveThe unlock visualization shows exactly what releases when, before creation.
- 05Create the scheduleParameters are committed and the schedule becomes part of the project register.
- 06Operate itClaim, revoke, extend, or transfer from the detail view, with every action recorded.
What it includes
Single or bulk beneficiaries
One schedule or an imported cohort, created against the same token and parameters.
CSV import
Bulk beneficiary and allocation ingest with validation before anything is created.
Full parameter set
TGE percentage, cliff duration, total duration, and unlock frequency configured independently.
Unlock visualization
The release curve rendered as you configure, so the shape is a decision rather than a surprise.
Portfolio metrics
Total value locked, active schedules, beneficiary count, and upcoming unlocks across the project.
Per-schedule detail
Allocation, released, remaining, next unlock, progress, and transaction history.
Administrative actions
Claim, revoke, extend, and beneficiary transfer, each recorded with an operator.
User and project views
A beneficiary sees their position; the project sees every schedule and claim.
Boundaries
Revocation and beneficiary transfer are first-class operations with a record, not emergency scripts.
- Schedule parameters are immutable after creation except through recorded administrative action
- Revoke and beneficiary transfer require explicit confirmation and leave an audit entry
- Dual control is recommended on revocation in production deployments
- Beneficiary view is read-only against their own position
- Demo actions in the public Console mutate local state and nothing else
Questions
Can we import beneficiaries from a spreadsheet?
Yes. CSV import handles a cohort in one operation, with validation on addresses and amounts before any schedule is created. The sandbox demonstrates the flow; in production it runs against your vesting backend.
Is anything on-chain in this demo?
No. The public Console is a redesigned interface over fabricated data for the demo token. Claims, revocations, and transfers change local state so the workflow can be evaluated end to end.
What happens if a beneficiary leaves?
Revocation stops future release while preserving the record of what was already released, and beneficiary transfer reassigns a position. Both are recorded administrative actions rather than manual transactions.
Can a schedule be changed after creation?
Deliberately not, except through explicit administrative action that is logged. A lockup that can be quietly edited provides no assurance to the person it applies to.
How do beneficiaries claim?
From their own view, which shows released, remaining, and next unlock for their position only. They do not need project access, and they do not need to ask an operator to release on their behalf.