Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.meteora.ag/llms.txt

Use this file to discover all available pages before exploring further.

Alpha Vault is configurable, but the best launch designs are simple enough for users to understand before they deposit.

​
Start With the Allocation Goal

GoalBetter fit
Broad participation when demand may exceed capacityPro Rata
Hard accepted-deposit capFCFS
Large allowlist with wallet-specific capsMerkle proof
Small curated allocationAuthority-managed escrows
Open community accessPermissionless, usually Pro Rata
Stronger post-launch alignmentLater start_vesting_point or longer linear vesting

​
Choose the Mode

Use Pro Rata when oversubscription is likely and the team wants users to have time to deposit without racing for capacity. Pro Rata lets total deposits exceed max_buying_cap, then allocates the vault result proportionally. Use FCFS when the team wants a hard cap on accepted deposits. FCFS is easier to explain, but it makes speed and wallet caps much more important.
FCFS without a practical per-wallet cap can concentrate the vault in the earliest depositors.

​
Set Caps Deliberately

CapApplies toDesign question
max_buying_capPro RataHow much quote should the vault be allowed to swap?
max_depositing_capFCFSHow much quote should the vault accept in total?
individual_depositing_capPermissionless FCFSHow much can one wallet contribute?
Escrow max_capMerkle proof and authority-managed accessWhat is each eligible wallet’s quota?
For Pro Rata, the buy cap shapes pool impact. For FCFS, the deposit cap shapes both participation and pool impact because total deposits are the max swappable amount.

​
Plan Timing

Alpha Vault timing follows the pool activation type: slot or timestamp. Important timing points:
  • depositing_point: first point when users can create escrows and deposit.
  • last_join_point: final point when escrow creation and deposits are allowed.
  • pre_activation_start_point: first point when the vault can fill.
  • last_buying_point: final point when the vault can fill.
  • start_vesting_point: first point when users can claim bought tokens.
  • end_vesting_point: point when all bought tokens have unlocked.
On mainnet, the program caps lock duration and vesting duration at roughly one year. FCFS config creation also requires a minimum deposit duration buffer of 3,000 slots for slot-based launches or 1,200 seconds for timestamp-based launches.

​
Prepare the Fill Plan

Vault fills are permissionless and can be performed by crankers during pre-activation. A non-whitelisted cranker pays a fixed 0.0001 SOL crank fee to the Meteora treasury account. Launch teams should plan:
  • Who will crank fills.
  • Whether crankers should be fee-whitelisted.
  • The maximum amount used in each fill instruction.
  • How the pool’s launch liquidity and price curve react to the vault’s buy.
  • What happens if only part of the intended quote is swapped before last_buying_point.
The fill instructions use minimum_amount_out = 0 when calling the underlying pool swap. Pool setup, fill timing, and crank operations are therefore important parts of the launch design.

​
Design Vesting Clearly

Claims unlock linearly from start_vesting_point through end_vesting_point, with inclusive endpoints. Setting both points equal effectively makes the full bought-token allocation claimable at the start point. Use longer vesting only when it matches the community promise. Users should know before depositing when claims start and when the allocation fully unlocks.

​
Account for Token Behavior

Alpha Vault uses checked token transfers through the token program stored by the connected pool. DLMM and DAMM v2 pools can indicate SPL Token or Token 2022 token programs. DAMM v1 pool utility code uses the SPL Token program. If a Token 2022 mint charges transfer fees, the program records deposits net of transfer fees and emits outbound claim or refund amounts net of transfer fees. If a destination account requires transfer memos, claim and refund transfers must include the expected memo program account.

​
Launch Messaging Checklist

A clear launch announcement should include:
  • Connected pool type: DLMM, DAMM v1, or DAMM v2.
  • Accepted quote token.
  • Vault mode: Pro Rata or FCFS.
  • Access model: permissionless, Merkle proof, or authority-managed.
  • Deposit open and close points.
  • Vault cap and wallet caps.
  • Whether Pro Rata users can withdraw before last_join_point.
  • When the vault can buy.
  • Claim start and full unlock point.
  • Refund timing and conditions.
  • Token transfer-fee behavior, if the quote or launch token uses Token 2022 fees.
Good Alpha Vault launches are specific. Users should understand what can happen if the vault is oversubscribed, partially filled, or subject to token transfer fees.