Alpha Vaults can be configured to either be permissionless or permissioned.
  • 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

Creating a Merkle Root Config

Depositing into an Alpha Vault

Withdrawing from an Alpha Vault

Cranking an Alpha Vault

Claiming from an Alpha Vault

Close Escrow Account

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.
You can use this config endpoint that has predefined timings created by Meteora. If your preferred configs are not available in the predefined config lists above, and you want more customization, please contact the Meteora team.

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.
{
  maxBuyingCap: new BN(10000000),
  index,
  startVestingDuration: new BN(3600),
  endVestingDuration: new BN(7200),
  escrowFee: new BN(0),
  individualDepositingCap: new BN(50000),
  activationType: ActivationType.TIMESTAMP,
  depositingPoint: new BN(1028979080),
}

Considerations for Slot Parameters

Alpha Vault Slot Progression

djpased \rightarrow j \rightarrow p \rightarrow a \rightarrow s \rightarrow e

Current Slot Condition

current_slot<p\text{current\_slot} < p
Alpha Vault will start to buy from the pool from pre_activation_slot (pp)

Slot Constraints

d+3000jd + 3000 \leq j j>current_slotj > \text{current\_slot} j+750=pj + 750 = p p+9000=ap + 9000 = a a<sa < s ese \geq s

User Submission Requirements

{d,a,s,e}\{d, a, s, e\}

Slot Calculation Guidelines

  1. Get Current Slot current_slot=getCurrentSlot()\text{current\_slot} = \text{getCurrentSlot()}
  2. Calculate Activation Slot a=current_slot+9000+750+buffera = \text{current\_slot} + 9000 + 750 + \text{buffer}
  3. Calculate Depositing Slot d=a90003000750bufferd = a - 9000 - 3000 - 750 - \text{buffer}
  4. Set Vesting Slots es>ae \geq s > a

Slot-to-Timestamp Conversion

3000=20minutes3000 = 20 minutes 750=5minutes750 = 5 minutes 9000=1hour9000 = 1 hour 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:
  • dd = depositing_slot
  • jj = last_join_slot
  • pp = pre_activation_slot
  • aa = activation_slot
  • ss = start_vesting_slot
  • ee = 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
The project will not be able to claim swap fees earned from t1 to t2, since fees from t1 to t2 are assigned to the LP token before the LP token gets permanently locked. When the LP token gets locked, the earlier fees are locked along with it. The project will only be able to claim swap fees from locked liquidity starting from 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’s activationPoint
  • 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
Vault deposit close point (time when vault deposits close):
  • Timestamp-based Vault: Deposit close point = Crank start point - 5 min
  • Slot-based Vault: Deposit close point = Crank start point - 750

G) How to crank the Alpha Vault so that it purchases the token from the pool?

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 repo and input your PublicKey.