Token Vesting & Locking
Schedules, cliffs, and claims that operators can actually run.
Vesting schedules, cliffs, and claims that an operator can actually run — for one beneficiary or a thousand.
- project
- Lunor Demo
- token
- LUNR
- module
- vesting
- category
- lock
- status
- live · sandbox
Every figure in this module's demo is fabricated. No wallet connection, no signing, and no broadcast path exists from this site.
The problem
A lockup that lives in a spreadsheet is a promise, not a lock.
Team and investor allocations get agreed in a document, tracked in a spreadsheet, and enforced by whoever remembers. That holds until the first person leaves, the first investor asks for a statement, or two allocations turn out to overlap. Then nobody can answer the only questions that matter: who is owed what, on what schedule, and what has already been released.
One-off lock contracts are not much better. Each is deployed with its own parameters, none of them share a record, and revocation or beneficiary transfer means a bespoke transaction that somebody has to reason about under pressure.
The approach
One register, contract-enforced, with an operator surface.
Schedules are created against a project and a token with the parameters that actually determine behaviour: allocation, TGE release, cliff length, total duration, and unlock frequency. An unlock curve renders as you configure it, so a schedule that dumps into a specific quarter is visible before it is created rather than after.
Beneficiaries can be added individually or imported in bulk. Each schedule has a detail view showing allocation, released, remaining, next unlock, and full history — plus the administrative actions an operator genuinely needs: claim, revoke, extend, and transfer beneficiary.
Capabilities
What the module does.
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.
How it works
The workflow, step by step.
- 01Select the token
Schedules are created against the project's token, not a free-text field.
- 02Add beneficiaries
Enter one, or import a cohort by CSV with validation on addresses and amounts.
- 03Set the schedule
TGE release, cliff, duration, and unlock frequency — the four parameters that define behaviour.
- 04Review the curve
The unlock visualization shows exactly what releases when, before creation.
- 05Create the schedule
Parameters are committed and the schedule becomes part of the project register.
- 06Operate it
Claim, revoke, extend, or transfer from the detail view, with every action recorded.
Specification
At a glance.
- Schedule parameters
- TGE %, cliff, duration, unlock frequency
- Beneficiary modes
- Single, multiple, CSV import
- Unlock frequencies
- Daily, weekly, monthly, quarterly
- Operator actions
- Claim, revoke, extend, transfer beneficiary
- Views
- Beneficiary view and project administration
- Public environment
- Sandbox — actions mutate demo state only
Security
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
Full posture, including what we deliberately do not claim, is on the security page.
Use cases
Where it gets used.
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.
Solution paths
Where this module sits in a bigger job.
FAQ
Questions asked before adopting this module.
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.
Other modules
Same Console, same project record.
Next step
Run it before you ask us anything.
The Console needs no signup and no wallet. Open the module, use it against sandbox data, then bring us the specific questions.