Alpha Vault

Available on DLMM, DAMM v1, and (soon) DAMM v2.

The Alpha Vault is a complementary anti-bot mechanism used together with a Launch Pool that provides early (first) access for genuine supporters to deposit and purchase tokens before the pool starts trading, thereby getting tokens at the earliest price and helping to safeguard the token launch against sniper bots.

Projects who use the Alpha Vault have the flexibility to tailor vault parameters to suit their specific token launch requirements, such as setting maximum purchase limits and defining the lock-up and vesting periods for users.

Key Features and Benefits

  • First-to-purchase ability to front run snipers: The Alpha Vault is whitelisted to buy tokens from the liquidity pool before the launch activation slot, so Alpha Vault users can buy the token at the earliest (and likely lowest) price before the activation slot and thus before sniper bots.

  • Fairer distribution: All vault users get their tokens at the same average price and the amount of tokens received is proportional to their share of the total amount of SOL or USDC deposited.

  • Configurable parameters for token launches: Projects can configure vault parameters such that tokens bought by the vault are locked for a day or more, and subsequently vested for a few days, encouraging purchase by genuine supporters of the project.

This solution mitigates against the negative effects of mercenary capital from sniper bots while encouraging purchase from genuine supporters, who'd be more willing to receive their tokens a day or so later than others. This helps ensure greater alignment between projects and token holders! Read about our Alpha Vault launch here.

How does it work?

The Alpha Vault doesn’t hold any tokens at the start. During the deposit period, the Alpha Vault will accept either SOL or USDC from depositors.

It subsequently has the ability to buy tokens from the Launch Pool before public trading. SOL or USDC goes from the Alpha Vault into the pool, and token from the pool goes to the Alpha Vault - to be distributed to depositors at a set time.

The Alpha Vault for the Launch Pool is first created together with the Launch Pool, using the project’s preferred configurations for the Alpha Vault and pool, including:

  • Alpha Vault mode: Pro rata or FCFS

  • To accept SOL or USDC deposits

  • Alpha Vault Max Buy Cap

  • Pool activation slot/time

  • Token lock-up period

  • Vesting Period for token claims

  • To whitelist addresses for deposits or not

  • Individual address purchase cap

Alpha Vault Modes

  • Pro Rata

  • FCFS (First come first serve)

1. Pro Rata mode

Summary

In Pro Rata mode, the Alpha Vault is able to accept unlimited deposits of SOL or USDC, even exceeding the Alpha Vault Max Buy Cap.

After depositing SOL or USDC, depositors can choose to withdraw anytime before the end of the deposit period if they change their mind.

Once the deposit period ends, users can no longer deposit more SOL or USDC or withdraw their earlier deposit. The vault becomes active and after a short buffer period, will begin using the funds collected to buy tokens from the pool.

However, the Alpha Vault would only buy tokens up to the max buy cap. As such, if the deposits by users into the Alpha Vault had exceeded the max buy cap, there will be unused funds, and they can be withdrawn by depositors.

For example, you deposited 100 USDC and TVL in the vault (total deposited) is 10M USDC, but the vault max cap is 1M USDC. Only 1/10th of your USDC deposit will be used to purchase tokens. 90 USDC from your 100 USDC deposit will be unused and returned to you.

All vault users get their tokens at the same price and the amount of tokens received is proportional to your share of the total amount of SOL or USDC deposited.

Example flow (Pro Rata mode)

Full Pro Rata Process

A) Deposit Period

The deposit and token purchase period will always take place a period of time before the main token launch, so vault users are the earliest to secure the token at launch.

The Alpha Vault doesn’t hold any tokens at the start. During the deposit period, users are able to deposit their preferred amount of USDC or SOL into the vault. A timer shows a countdown to the end of this period.

Before the end of the deposit period, if users change their mind, they can also withdraw their deposits.

Based on users' USDC or SOL deposit amount and the current deposit TVL in the vault, the estimated token amount received and discount from launch price is calculated.

There needs to be a buffer period of at least roughly ~1 hour 5 min between the end of the Alpha Vault deposit period and the pool activation time.

B) Token Purchase Period

At the end of the deposit period, the token purchase period begins. The Alpha Vault is whitelisted to buy tokens from the pool BEFORE the pool is activated for trading. The vault will start using the USDC or SOL collected to buy tokens from the liquidity pool.

This is essentially a token swap, which means SOL or USDC from the Alpha Vault goes into the pool, while tokens purchased from the pool go into the Alpha Vault. The token pool price would increase from the initial price, based on the token amount purchased by the Alpha Vault.

During the token purchase period, users can no longer deposit more USDC or SOL, or withdraw their earlier deposit.

If the vault max cap is not reached, all the USDC or SOL collected in the vault would be used to buy the token from the pool.

Claim unused funds for Pro rata mode: However, if the Alpha Vault is using the Pro rata mode (which accepts unlimited deposits), and funds in the vault exceed the max cap the vault can buy from the pool, unused USDC or SOL will be returned to users and they can withdraw them anytime once the token purchase period is over.

  • Example: you deposited 100 USDC and TVL in the vault is 10M USDC, but the vault max cap is 1M USDC. Only 1/10th of your USDC deposit will be used to purchase tokens. 90 USDC from your 100 USDC deposit will be unused and returned to you.

How to calculate Average Vault Price?

All vault users get their tokens at the same average price and the amount of tokens received is proportional to their share of the total amount of USDC deposited.

Average vault price = USDC used by vault to buy tokens / Tokens bought by vault

Example:

  • USDC used by vault to buy tokens = 2.424685m

  • Tokens bought by the vault = 39.49m

  • Average vault price = 2.424685m / 39.49m = ~0.06139 USDC per token

C) Launch Pool Activation Slot / Timestamp

A short period of time after the vault finishes its token purchase, the launch pool activation slot / timestamp will be reached and the pool becomes open and active for everyone to trade and LP.

D) Claiming Tokens: Unlock and Vesting Period

A short period of time after the launch pool activation slot, locked tokens in the vault start getting unlocked and vested over a few days (configurable).

Users can claim unlocked tokens anytime, there is no deadline! Depositors get tokens at the same price, and the amount of tokens received is based on their share of the total deposits.

The exact timing where tokens get unlocked and vested depends on the creator, who can configure the parameters based on their needs. Creators can configure the Alpha Vault to their preference; whether token claiming is unlocked immediately when the pool starts trading or at a later time/date, and whether there is a vesting period for token claims.

The vesting solution has the dual benefit of mitigating against sniper bots as well as encouraging purchase from the strongest and most genuine supporters of the project, since they would be more willing to hold their tokens for a longer period. This helps ensure greater alignment between projects and token holders.

Important Reminder: 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.

Read how to configure Alpha Vault timings here.

How to calculate the token amount to receive?

Amount of tokens to receive = Your USDC used by vault to buy tokens / Average Vault Price

Example:

  • Your USDC used by vault to buy tokens = 100

  • Average Vault Price = 0.061396 USDC per token

  • Amount of tokens you’ll receive = 100 / 0.061396 = 1,628.77 tokens

Note: Meteora cannot guarantee that market price after the launch will remain above the average vault price over time before all tokens are vested/unlocked. This is a risk that users have to consider.

2. FCFS mode

FCFS (First Come First Serve) mode follows a similar process to Pro Rata mode, but with the following differences:

Unlike Pro rata mode, in FCFS mode, during the deposit period, Alpha Vault max buying cap = max amount of deposits the Alpha Vault accepts. Users can deposit as much as they want initially, but as soon as the vault’s reserve reaches the deposit/buy cap, then no one can deposit more (TVL cannot exceed Vault Max Cap). In other words, deposits are first come first served, up to the Alpha Vault max deposit/buy cap.

For example: If Vault Max Cap is 1M USDC, and a single user is the first to deposit 1M USDC right when deposits open, the vault gets fully filled and no longer accepts further deposits.

By default, each user has no individual deposit cap, which means a single user can technically fill up the entire Alpha Vault deposit/buy cap. However, if required, the project can specify an individual user cap and/or submit a whitelist to allow only certain wallets to deposit.

Once a user deposits funds, the user cannot withdraw them, even during the deposit period.

In FCFS mode, there won’t be any unused USDC or SOL. All deposits would be used to buy the token.

After the Alpha Vault buys the tokens, all depositors will also get tokens at the same average price.

Alpha Vault with Whitelist and Individual Deposit Cap

Whitelist and Individual Deposit Cap are optional features for your Alpha Vault.

Whitelist

For both Pro rata and FCFS mode, projects can submit a whitelist (csv file format) to specify which wallets are allowed to deposit into the Alpha Vault.

For some launches, the project may want to restrict which wallet addresses are allowed to deposit funds into the Alpha Vault, so in the config file used in the script to create the Alpha Vault, the whitelistMode needs to be specified.

  • permissionless: No whitelist, anyone can deposit into the Alpha Vault

  • permission_with_authority: In this mode, only the Alpha Vault creator can create escrow account with max_cap. This allows the creator to 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).

  • permission_with_merkle_proof: 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.

Individual Deposit Cap

  • Projects can specify a global individual deposit cap, where all depositors have the same individual deposit cap.

  • Projects can also specify unique individual deposit caps for each wallet e.g. Wallet A = max 500 USDC, Wallet B = max 1,000 USDC, Wallet C = max 1,500 USDC. But this requires the submission of a whitelist.

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

Which Launch Pools can be used with Alpha Vault?

Available for DLMM, DAMM v1, and DAMM v2 Launch Pools (soon).

Other Notes

Past Alpha Vault Launches

Projects that have used Alpha Vault for their token launches include UpRock (UPT), Sanctum (CLOUD), dVin Labs (VIN), deBridge (DBR), Streamflow (STREAM), SonicVM (SONIC), and Sendcoin (SEND).

Read the CLOUD Launch Case Study here.

Alpha Vault Integrations

Alpha Vault Audit

Alpha Vault has been audited by the experienced team from Offside Labs.

Alpha Vault FAQ

Please read our Alpha Vault FAQ.

Comparison of Alpha Vault Features

Compare different Alpha Vault Features here and read the medium announcement here.

PreviousRate LimiterNextDLMM Integration

Last updated