> ## Documentation Index
> Fetch the complete documentation index at: https://docs.jup.ag/llms.txt
> Use this file to discover all available pages before exploring further.
# 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.
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.
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](https://lock.jup.ag/).
The recipient connects the wallet specified in the lock.
The interface shows how many tokens have vested and are available to 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.