- For
Permissionless
Alpha Vaults, anyone can deposit assets into the Alpha Vault after creation. - For permissioned Alpha Vaults, only whitelisted addresses can deposit assets into the Alpha Vault after creation. There are 2 types of permissioned Alpha Vaults:
PermissionedWithAuthority
- In this mode, only the Alpha Vault creator can create escrow account with max_cap. This allows the creator to easily use a permissioned (with whitelist) setup without having to use the merkle tree. Creator needs to pay SOL rent for each escrow account for the whitelisted wallets, so this Alpha Vault whitelist mode is suitable for scenarios where there are very few whitelisted addresses(e.g. <=100)
. If they need to support a lot more whitelisted addresses, they should still use the merkle tree (PermissionWithMerkleProof whitelist mode).PermissionedWithMerkleProof
- In this mode, only wallets that are whitelisted can deposit into the Alpha Vault. CSV file containing the list of whitelisted wallets needs to be provided by the project to Meteora, for the Merkle proof to be hosted by Meteora and shown on the UI. Alpha Vault deposits should not open until the Merkle proof is hosted by Meteora.
Example Timeline of an Alpha Vault

Code Examples
Creating an Alpha Vault
Create DAMM V1 Pool with Permissionless Alpha Vault
Create DAMM V1 Pool with Permissionless Alpha Vault
This example shows how to create a new DAMM v1 Pool that also adds a permissionless Alpha Vault.Note for token vesting period:
You have to find a pool config and vault config that meets your requirements. Please contact us on discord if you need new pool configs or vault configs.
Currently, only SOL or USDC is accepted as the quote token when initializing a DAMM v1 Pool with Alpha Vault in a permissionless setup.
startVestingSlot = poolState.activationSlot + startVestingDuration
endVestingSlot = poolState.activationSlot + endVestingDuration
startVestingPoint
: Absolute value, the slot or timestamp that start vesting depend on the pool activation type. If no vesting is required, you should put this as 1 sec after the pool’s activationPointendVestingPoint
: Absolute value, the slot or timestamp that end vesting depend on the pool activation type. If no vesting is required, this should be the same as startVestingPoint
Creating a Merkle Root Config
Create Merkle Root Config for Permissioned Alpha Vault
Create Merkle Root Config for Permissioned Alpha Vault
This example shows how to create a merkle root config after generating a merkle tree, which is required to verify the whitelisted wallet address data, and enable deposits by whitelisted wallets.
Depositing into an Alpha Vault
Deposit into an Alpha Vault
Deposit into an Alpha Vault
This example shows how to deposit SOL or USDC into an Alpha Vault. Deposit can only happen before the end of the deposit period.
Withdrawing from an Alpha Vault
Withdraw from an Alpha Vault
Withdraw from an Alpha Vault
This example shows how to withdraw SOL or USDC from an Alpha Vault. Withdraw function only available before the end of the deposit period, and the function is applicable only when the Alpha Vault is using Pro rata mode.
Withdraw unused tokens from an Alpha Vault
Withdraw unused tokens from an Alpha Vault
This example shows how to withdraw unused SOL or USDC deposit from an Alpha Vault after the Alpha Vault has completed the purchase of tokens from the liquidity pool. This is applicable only for Alpha Vault using Pro rata mode.
Cranking an Alpha Vault
Cranking the Alpha Vault to buy from DAMM v1 pool
Cranking the Alpha Vault to buy from DAMM v1 pool
This example shows how to crank an Alpha Vault to purchase the base token from the liquidity pool during the crank period. Alpha Vault would purchase tokens using the SOL or USDC deposited into the Alpha Vault earlier.
Cranking the Alpha Vault to buy from DLMM pool
Cranking the Alpha Vault to buy from DLMM pool
This example shows how to crank an Alpha Vault to purchase the base token from the liquidity pool during the crank period. Alpha Vault would purchase tokens using the SOL or USDC deposited into the Alpha Vault earlier.Typically, we have a keeper that cranks the Alpha Vault to automatically purchase tokens from the pool. However, if the auto-crank fails, you can visit this fillVaultDlmm.ts and input your PublicKey.
Claiming from an Alpha Vault
Claiming tokens from an Alpha Vault
Claiming tokens from an Alpha Vault
This example shows how to claim tokens from an Alpha Vault after it has purchased those tokens from the liquidity pool. Claiming can only happen after the start of the vesting period.For a new token launch, the project should ensure that token claiming from the Alpha Vault is NOT possible before the launch pool trading activation or before the token starts trading anywhere, whether on a Dynamic AMM or DLMM Pool. If users are able to claim tokens before the launch pool/token starts trading, they may create a separate market with a price that deviates from the project’s preferred launch price.
Important Reminder: Claim start time should NOT be earlier than Pool activation time
Close Escrow Account
Close Escrow Account
Close Escrow Account
When a user deposits to the vault, it will create an escrow account, which stores the user info, such as deposit, claimed token, etc. Once user fully claims all tokens, they can close the escrow account.Close escrow can only happen after vesting of tokens is complete, and the escrow has claimed all the bought token. This example shows how to close an escrow account and get rental back.
Configure Alpha Vault Timings
If you are integrating the Alpha Vault program and need to view and select the predefined timings for the various phases, such as:- Deposit open time (only for FCFS mode currently)
- Deposit close time
- Vault crank/buy start time
- Vault crank/buy end time
- Withdraw unused USDC or SOL after crank is successful
- Pool Activation time
- Token claim start time
- Vesting start time
- Vesting end time
There must be a ~1 hour 5 minutes period between the deposit close time and the pool activation time.
DAMM v1 Pool Config List
View all available pool configurations for DAMM v1 Pools with Alpha Vault.
DAMM v1 Vault Config List
Browse all vault configurations for DAMM v1 Pools with Alpha Vault.
Config endpoint based on Pool Activation Timing
This config endpoint is tied to the pool activation timing, so all timings for the different Alpha Vault phases is derived from the pool activation timing. In this example below, the claim process will start 3600 seconds (1 hour) after pool activation, and it will end 7200 seconds (2 hours) after pool activation. In other words, after the pool starts trading, tokens are locked first and released for claiming 3600 seconds (1 hour) later.Considerations for Slot Parameters
Alpha Vault Slot Progression
Current Slot Condition
Alpha Vault will start to buy from the pool from pre_activation_slot ()
Slot Constraints
User Submission Requirements
Slot Calculation Guidelines
Recommended Calculation Sequence
- Get Current Slot
- Calculate Activation Slot
- Calculate Depositing Slot
- Set Vesting Slots
Slot-to-Timestamp Conversion
Note for Quote mint: New endpoint only supports wSOL or USDC as Quote mint on mainnet. Devnet has more flexibility regarding the Quote mint; please reach out to the team.Variable Definitions
Where:- = depositing_slot
- = last_join_slot
- = pre_activation_slot
- = activation_slot
- = start_vesting_slot
- = end_vesting_slot
Important Reminders
A) Claim start time should NOT be earlier than Pool activation time
For a new token launch, the project should ensure that token claiming from the Alpha Vault is NOT possible before the launch pool trading activation or before the token starts trading anywhere, whether on a Dynamic AMM or DLMM Pool. If users are able to claim tokens before the launch pool/token starts trading, they may create a separate market with a price that deviates from the project’s preferred launch price.B) For Memecoins that want to permanently lock liquidity, lock it before Pool activation time
If the Alpha Vault is used for a Memecoin launch pool, and the project wants to permanently lock liquidity in the Memecoin pool, they should ideally lock the liquidity BEFORE the pool starts trading, so that swap fees from locked liquidity are captured the second trading starts. In a scenario where:- The pool started trading - t0
- Liquidity gets deposited to the pool by the project, but not locked - t1
- Subsequently, that liquidity is permanently locked by the project - t2
C) Quote token must be SOL or USDC
Only SOL or USDC is accepted as the quote token when initializing a Dynamic AMM or DLMM Pool with Alpha Vault.D) For permissionless Alpha Vault (any wallet can deposit), is there a way to set an individual user cap?
Permissionless FCFS Alpha Vault allows you to set an individual cap, but this will be the same individual cap for everyone.E) If no vesting is required, what should the startVestingPoint and endVestingPoint be?
startVestingPoint
: Absolute value, the slot or timestamp that start vesting depend on the pool activation type. If no vesting is required, you should put this as 1 sec after the pool’sactivationPoint
endVestingPoint
: Absolute value, the slot or timestamp that end vesting depend on the pool activation type. If no vesting is required, this should be the same as startVestingPoint
F) How do you determine the Alpha Vault deposit close time?
Crank start point (time when vault buys tokens from the pool):- Timestamp-based:
Crank start point = activationPoint - 3600
- Slot-based:
Crank start point = activationPoint - 9000
- Timestamp-based Vault:
Deposit close point = Crank start point - 5 min
- Slot-based Vault:
Deposit close point = Crank start point - 750