Skip to main content
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.
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 the unlock frequency you set (every given number of minutes, days, weeks, months, or years).
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.
There is no minimum or maximum for lock duration or token amount.

​
Lock Parameters

When creating a lock on lock.jup.ag, you select the token, then fill in the following fields (names as shown in the form). Every parameter is permanent once the lock is created; only the recipient can change afterward, and only if the permissions allow it. 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 can reassign the lock to a different wallet after creation: None, Only Creator, Only Recipient, or Creator or Recipient (either of them). Who can cancel the contract? This determines which party can cancel the lock entirely, with the same four options. These permissions are set once and cannot be changed after the lock is created. Both default to None in the form.
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 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 audited, but the upgrade capability is a factor to be aware of.