How Jupiter Lock Works

Vesting model, lock parameters, permissions, claiming, and onchain mechanics.

Jupiter Lock allows anyone to create an onchain escrow that holds tokens and releases them according to a defined vesting schedule. This page covers the full mechanics: how vesting works, what parameters are set at creation, how permissions and claiming work, and what happens onchain.

Vesting Model

Every lock created on Jupiter Lock follows a cliff + linear vesting model. The vesting schedule is defined at creation and cannot be changed afterward.

Cliff + Linear Vesting

This is the standard configuration. The vesting schedule has two phases:

1. Cliff phase. No tokens are available until the cliff date. On that date, a predefined amount (the cliff unlock amount) becomes claimable immediately.
2. Linear vesting phase. After the cliff, the remaining tokens unlock gradually over the defined vesting duration, at a set frequency (minute, day, week, month, or year).

Example: A lock of 120,000 tokens with a 3-month cliff of 20,000 tokens, then linear monthly vesting over 10 months. At the cliff date, 20,000 tokens unlock. Then 10,000 tokens unlock each month for 10 months.

Simple Lock (Full Release at One Date)

To create a lock with no gradual vesting, set the cliff unlock amount to the full token amount. Since nothing remains after the cliff, the vesting duration and frequency have no effect. All tokens become claimable at the cliff date.

Example: A lock of 100,000 tokens with a cliff unlock amount of 100,000 and a cliff date of January 1, 2026. All tokens become claimable on that date. No linear vesting occurs.

There is no minimum or maximum for lock duration or token amount.

Lock Parameters

When creating a lock, the following parameters are defined. All parameters except permissions are permanent once the lock is created.

Parameter	Description
Token	The SPL token to lock.
Total amount	The total number of tokens to deposit into the escrow.
Recipient wallet	The wallet address that will be able to claim unlocked tokens.
Cliff date	The date at which the cliff amount becomes claimable. No tokens are accessible before this date.
Cliff unlock amount	The number of tokens that unlock at the cliff date. This is an absolute token amount, not a percentage.
Vesting duration	The total duration of the linear vesting phase, starting after the cliff date.
Vesting frequency	How often tokens unlock during the linear vesting phase. Options: minute, day, week, month, or year.
Recipient change permission	Who is allowed to change the lock recipient: creator, recipient, both, or none.
Cancel permission	Who is allowed to cancel the lock: creator, recipient, both, or none.

Each lock has exactly one recipient. To distribute tokens to multiple wallets, create one lock per recipient.

All vesting parameters (cliff date, cliff amount, vesting duration, frequency, token, total amount) are permanent once the lock is created. They cannot be modified, extended, or reduced after creation. Only the recipient wallet and lock cancellation are actionable post-creation, depending on the permissions set.

Permissions

At creation, the lock creator assigns two permissions:

Who can change the recipient. This determines which party (creator, recipient, both, or none) can reassign the lock to a different wallet after creation.

Who can cancel the lock. This determines which party (creator, recipient, both, or none) can cancel the lock entirely.

These permissions are set once and cannot be changed after the lock is created.

If both permissions are set to “none,” the lock becomes fully irreversible: it cannot be cancelled and the recipient cannot be changed.

Claiming Tokens

Unlocked tokens are not sent automatically. The recipient must manually claim them through the Jupiter Lock interface.

1. Connect wallet

   The recipient connects the wallet specified in the lock.

2. View available tokens

   The interface shows how many tokens have vested and are available to claim.

3. Claim

   The recipient triggers a claim transaction. Claimed tokens are transferred from the escrow to the recipient’s wallet.

Unclaimed tokens remain in the escrow indefinitely. There is no expiration on the right to claim.

Token Compatibility

Jupiter Lock supports SPL tokens on Solana.

Onchain Mechanics

When a lock is created, an escrow account is deployed onchain. The locked tokens are transferred from the creator’s wallet to this escrow account. The escrow is controlled by the Jupiter Lock program.

Tokens remain in the escrow until claimed by the recipient according to the vesting schedule.

The Jupiter Lock program is upgradeable. Due to the sensitive nature of the program, updates are only made when critical. The program is open-source and has been audited by OtterSec and Sec3.

Risks and Limitations

Immutable vesting parameters. Vesting schedule, token amount, cliff date, and durations cannot be changed after creation. Only recipient change and cancellation are possible, and only if the corresponding permissions were granted at creation.

No recovery for compromised wallets. If the recipient’s wallet is compromised, there is no built-in recovery mechanism. The only option is if the lock was created with permissions allowing the creator to change the recipient or cancel the lock.

Token-side risks are not handled. Jupiter Lock manages the escrow and vesting schedule only. It does not monitor or react to changes in the token itself (loss of liquidity, mint authority changes, token deprecation). If the locked token becomes worthless or illiquid, the lock still functions as configured, but the claimed tokens may have no practical value.

Upgradeable contract. The Jupiter Lock program is upgradeable. While updates are rare and reserved for critical fixes, the program authority has the technical ability to modify the program’s behavior. The program is open-source and audited, which provides transparency, but the upgrade capability is a factor to be aware of.