Vesting schedules

Vesting deposits a complete Fungible Asset allocation into an isolated vault and releases it over an immutable schedule. The beneficiary may claim more than once; every claim transfers only the newly vested amount after the snapshotted protocol fee.

When to use it

Vesting is suitable for:

• team or adviser allocations released over months or years;
• investor allocations with a cliff followed by gradual release;
• grant programs with discrete release milestones; or
• any allocation that needs partial claims rather than one fixed unlock.

Use a token lock when the entire allocation should release at one date. Use a payment stream for continuous payroll-style accrual with an optional creator cancellation policy.

Schedule types

All boundaries use on-chain UTC timestamps, not the user's browser clock.

Before you start

You need the token metadata address, full allocation balance, beneficiary address, final schedule, and enough SUPRA for network gas. There is no fixed protocol fee when creating a vesting schedule, but the current 1% claim fee is snapshotted into the new position.

The creator should explain the gross allocation, fee rate, expected net amount, and schedule to the beneficiary before signing.

Create a schedule

1. Open Create vesting.
2. Enter and verify the token metadata address and creator balance.
3. Enter the gross allocation and immutable beneficiary.
4. Select cliff, linear-with-cliff, or stepped release.
5. Enter the future UTC boundaries and, for stepped vesting, the number of release steps.
6. Review the timeline, exact base units, live fee rate, expected net claims, and authority policy.
7. Sign once and wait for the matching vesting-created event.
8. Save the vesting object address and transaction hash.

The full gross allocation is moved into the vault during creation. No unfunded vesting promise can be created.

Practical example

A contributor receives a gross allocation of 120,000 EXR vesting linearly over 12 months after a 3-month cliff.

• Before the cliff, claimable value is zero.
• If 30,000 EXR is gross vested at the first claim, the current 1% fee is 300 EXR and the contributor receives 29,700 EXR net.
• If the full 120,000 EXR eventually vests, the cumulative fee is 1,200 EXR and cumulative net beneficiary value is 118,800 EXR.
• Claiming monthly or claiming once at the end produces the same cumulative fee, apart from each transaction having its own network gas cost.

The 1% is charged in EXR, the vested asset—not in SUPRA.

Fees and costs

The fee rate is snapshotted when the position is created. A later fee change affects new positions, not an existing schedule. Cumulative integer accounting prevents a beneficiary from reducing the total fee by splitting one claim into many smaller claims.

The creation transaction includes a user-approved maximum fee rate and aborts if the live rate exceeds it. After creation, claims use the position's immutable fee snapshot rather than a changing live rate. A failed claim cannot leave a protocol fee behind, although network gas may still be charged. See Fee governance.

Claim vested tokens

1. Connect the beneficiary wallet and open My positions.
2. Select the exact vesting object and verify its token, gross allocation, schedule, beneficiary, claimed amount, and snapshotted fee rate.
3. Review the current gross claimable amount, 1% fee, and net amount.
4. Sign the claim and wait for the finalized event.
5. Confirm cumulative gross, cumulative fee, beneficiary net, and expected vault balance reconcile.

Anyone may later trigger a sweep of accrued fees, but the destination is fixed to the configured collector. The caller cannot redirect them.

What is guaranteed

• The gross allocation is fully funded at creation.
• Schedule, token, beneficiary, amount, and fee snapshot are immutable.
• Only the beneficiary can claim vested principal.
• gross claimed ≤ vested ≤ total is enforced in base units.
• One position cannot change another position.
• The final eligible claim and final fee sweep should empty the accounted vault exactly.

The historical revision-2 deployment has no creator revocation, pause, beneficiary replacement, or emergency seizure path.

Optional revocation in module version 3

The active immutable revision-5 deployment uses module version 3 and offers Irrevocable (default) or Revocable in the creation form. This choice is permanent and is included in the creation receipt and public proof.

Only the original creator of a revocable schedule can stop future vesting. The transaction refunds the unvested principal to that creator and leaves already vested tokens in the vault for the beneficiary to claim under the original fee snapshot. Revoking before the cliff refunds the full allocation; revoking after full vesting is rejected. Previously claimed tokens cannot be recovered.

For example, if an allocation of 10,000 tokens has vested 4,000 tokens at execution time, revocation refunds 6,000 tokens to the creator. The beneficiary retains the right to the vested 4,000 tokens, minus any earlier gross claims and the original claim fee. The creator refund has no protocol fee; the creator pays network gas.

Connect the creator wallet, open the exact position, choose Review revocation, inspect the refund estimate and beneficiary protection, and then sign Revoke unvested tokens. The exact refund uses chain execution time. If confirmation is interrupted, use the same action to recheck the saved transaction; do not create another transaction manually.

Administrators cannot switch an irrevocable position to revocable, alter its beneficiary or schedule, or seize its funds. Existing revision-2 positions keep their original rules.

Common problems

• Nothing claimable: the cliff or next release step has not been reached on-chain.
• Net amount is lower: the page shows gross, 1% protocol fee, and net separately.
• Claiming frequently: the percentage fee is unchanged, but more claims mean more network gas.
• Wrong schedule: timestamps and schedule type cannot be edited after creation.
• Position missing: use the direct vesting object address while indexer discovery catches up.