Meteora
  • Meteora: The most dynamic and sustainable liquidity layer on Solana
  • PRODUCT OVERVIEW
    • Meteora Liquidity Pools
      • DLMM Overview
        • What is DLMM?
        • DLMM Program
        • Dynamic Fees
        • Strategies & Use Cases
        • DLMM Farming Rewards
      • DLMM Launch Pool Overview
      • Dynamic AMM Overview
        • What is a Dynamic AMM Pool?
        • Dynamic AMM LP Fee and APY Calculation
        • Creating a Dynamic AMM Pool via the UI
        • Claiming Fees from Permanently Locked Liquidity
        • Dynamic AMM Stable Pools
        • Dynamic LST Pools
        • Additional yield from Dynamic Vaults
        • Dynamic AMM Farm Overview
      • DAMM v2 Overview
      • Memecoin Pool Overview
        • Memecoin Pool v2
          • What is Memecoin Pool v2?
        • Memecoin Pool v1
          • What is Memecoin Pool v1?
          • Permanently Locking Liquidity
      • Stake2Earn Pool Overview
        • What is a Stake2Earn Pool?
        • Stake2Earn for Launchpads
      • Multi-Token Stable Pool Overview
    • Alpha Vault Overview
    • Dynamic Vault Overview
      • What is a Dynamic Vault?
      • Dynamic Vault Program
      • Hermes - Meteora's Keeper
        • Algorithm to find optimal yield allocations
        • Rebalance crank
        • Operation fee calculation
      • Design Goals
      • Security
      • Dynamic Vaults Whitepaper
      • Dynamic Vaults Community Explainers
      • Affiliate Program for Dynamic Vault
        • Become an Affiliate Partner (Dynamic Vaults)
    • Dynamic Bonding Curve (DBC) Overview
      • What is the Dynamic Bonding Curve?
      • Customizable Pool Configuration
      • Bonding Curve Formula
      • DBC Migrator Keeper
    • Meteora’s Anti-Sniper Suite
  • INTEGRATION
    • DLMM Integration
      • DLMM SDK
        • DLMM TypeScript SDK
        • CPI Examples
      • DLMM API
      • Fetching information on locked liquidity in a DLMM
    • Dynamic AMM Pool Integration
      • Dynamic AMM SDK
        • Dynamic AMM TypeScript SDK
        • CPI Examples
      • Dynamic AMM API
        • Pool Info
        • Pool State
      • Setting Pool and Fee Config for Dynamic AMM Pools
      • Create Dynamic Pool with Timestamp/Slot Activation
      • Dynamic AMM - Farm Integration
    • DAMM v2 Integration
      • DAMM v2 SDK
        • DAMM v2 TypeScript SDK
        • DAMM v2 Rust SDK
      • Setting Pool and Fee Config for DAMM v2
      • Technical FAQ
    • Memecoin Pool Integration
      • Memecoin Pool v2 Integration
        • Setting Pool and Fee Config for Memecoin Pool v2
      • Memecoin Pool v1 Integration
        • TypeScript Code Examples
        • CPI Examples
        • Setting Pool and Fee Config for Memecoin Pool v1
        • Track permanently-locked liquidity in Memecoin Pool v1
        • Track Protocol Fee from swaps in Memecoin Pool v1
    • Stake2Earn Pool Integration
    • Dynamic Vault Integration
      • Using TypeScript-Client
      • Using Rust-Client
      • Using CPI
      • Vault API
        • Vault Info
        • Vault State
      • Vault Developer Resources
    • Alpha Vault Integration
      • Alpha Vault TypeScript SDK
      • Alpha Vault without Whitelist Setup
      • Alpha Vault with Whitelist Setup
    • Dynamic Bonding Curve (DBC) Integration
      • DBC SDK
        • DBC TypeScript SDK
        • DBC Rust SDK
      • DBC Fee Scheduler Formula
      • Program Repo
      • Technical FAQ
  • TOKEN LAUNCH POOLS
    • Steps to Create a Pool for a Token Launch
      • Create: DLMM Launch Pool
      • Create: Dynamic AMM Pool
      • Create: Memecoin Pool v1
      • Create: Stake2Earn Pool
      • Create: Pools with Alpha Vault
        • Create: DLMM Launch Pool with Alpha Vault
        • Create: Dynamic AMM Pool with Alpha Vault
        • Create: Memecoin Pool with Alpha Vault
        • Create: Stake2Earn Pool with Alpha Vault
    • Anti-Sniper Fee Suite for a Token Launch
  • Resources
    • Audits
    • Meteora Program IDs
    • Meteora APIs
    • Devnet Testing
    • Community Data Dashboards & Tools
    • Meteora Brand Assets
    • THE MASSIVE METEORA STIMULUS PACKAGE
      • Overview
      • 1. Dynamic Liquidity Market Maker (DLMM)
      • 2. Formation Of An LP Army DAO
      • 3. The 10% Stimulus Proposal
  • USER FAQ
    • Getting Started LPing
      • Supported Wallets
      • Prepare SOL
      • SOL required for Rent
      • What is Wrapped SOL?
      • What is an AMM?
      • What does it mean to provide liquidity?
      • How to swap to the tokens required for adding liquidity to a pool
      • How to quickly check if a token has any risks
      • Viewing your transaction history
      • My wallet has been compromised. What should I do?
    • Differences between DLMM and Dynamic Pools
    • DLMM FAQ
    • Dynamic AMM FAQ
      • How is the pool price of the token calculated in a Dynamic AMM?
      • What is a Meteora LP token?
      • How do I see fees earned on a Dynamic AMM Pool?
      • How to track your earnings for a Dynamic Pool?
      • What is Virtual Price in a Dynamic Pool?
      • How do LP tokens, fees, and virtual price work for Dynamic Pools?
      • Why must I add liquidity in non-stable Dynamic Pools using a 50:50 value ratio?
      • What is AMP in a Dynamic Pool with stable coins?
      • Why is the USDT-USDC pool not 1:1 in ratio of assets?
      • Can I create an LST, FX, or Multi-token pool using the Dynamic Pool creation tool?
    • Alpha Vault FAQ
    • Why is the token sometimes not picked up and tradable on Jupiter?
    • How do I create a new farm?
    • Video Tutorials to Get Started
      • LP Army Boot Camp
      • DLMM Strategy Sessions / Jam Sessions
  • Security and Risks
    • Risk of Impermanent Loss (IL)
    • Risk of depositing into an imbalanced pool / pool with price out of sync
    • Smart contract risk
    • Risk of a stablecoin depeg
    • Operational risk for dynamic vaults and pools
    • Lending risk for dynamic vaults and pools
  • legal
    • Terms of Service
    • Stake2Earn Terms of Service
Powered by GitBook
On this page
  • 1. Dynamic Fee
  • How does it work?
  • Which Launch Pools support Dynamic Fee?
  • 2. Fee Scheduler
  • How does it work?
  • Which Launch Pools support the Fee Scheduler feature?
  • 3. Alpha Vault
  • How does it work?
  • Alpha Vault Modes
  • Pro Rata
  • FCFS
  • Past Alpha Vault Launches
  • Which Launch Pools can be used with Alpha Vault?
  1. PRODUCT OVERVIEW

Meteora’s Anti-Sniper Suite

For any token launch, sniper bots have an incredibly unfair advantage as they can buy up a substantial portion of the initial token supply right at the activation slot, at the earliest/lowest prices, in order to sell for a quick profit. This prevents tokens from being widely distributed and severely disadvantages genuine users and supporters of the token project.

Meteora has developed an advanced suite of Anti-Sniper technologies to counter the threat of mercenary sniper bots during token launches, helping to provide a fairer experience for the community.

The Anti-Sniper Suite toolkit includes three core components:

  1. Dynamic Fees: Dynamically changing fee structure that capitalizes on launch volatility to maximize yield for LPs while protecting against sniper activity. Available for DLMM and DAMM v2 Launch Pools.

  2. Fee Scheduler: Configurable fee schedule designed to deter sniper bots by imposing higher fees during the initial launch phase. Available for DAMM v1 and DAMM v2 Launch Pools.

  3. Alpha Vault: A complementary anti-bot mechanism used together with a Launch Pool that provides early access for genuine supporters to deposit and purchase tokens before the pool starts trading, thereby safeguarding the token launch against sniper bots. Available for DLMM, DAMM v1, and DAMM v2 Launch Pools.

1. Dynamic Fee

Creators have the option to use a pool with a dynamically changing fee structure that capitalizes on launch volatility to maximize yield for LPs while protecting against sniper activity.

How does it work?

Dynamic Fee acts as a form of surge pricing based on market fluctuations and volatility.

Since demand for tokens and price volatility are often the highest at launch, Dynamic Fee would also be high. This both mitigates against aggressive sniper bot purchases while capturing more fees for the token creator and LPs in the pool.

DLMM Dynamic Fee Calculation

LPs earn a swap fee from traders when they perform a swap. The total swap fee (fs)(f_s)(fs​) will have two components: a base fee (fb)(f_b)(fb​) and a variable fee (fv)(f_v)(fv​).

Total swap fee fs=fb+fvf_s = f_b + f_vfs​=fb​+fv​

The variable fee (fv)(f_v)(fv​) is a function of real-time price volatility. The fee rate will be applied to the swap amount in each liquidity bin and distributed proportionally to the LPs in that bin.

DAMM v2 Dynamic Fee Calculation

  • dynamic_fee_numerator = ((volatilityAccumulator*binStep)^2 * variableFeeControl + 99_999_999_999) / 100_000_000_000

  • dynamic_fee_percent = (dynamic_fee_numerator / 1_000_000_000) * 100

By default

  • binStep = 1

  • variableFeeControl = 2_000_000

  • volatilityAccumulator is the value inside program and storage in poolState.

Which Launch Pools support Dynamic Fee?

All DLMM Launch Pools have Dynamic Fees enabled by default, while creators have the option to use (or don’t use) Dynamic Fee on DAMM v2 Launch Pools, based on their requirements.

2. Fee Scheduler

Creators have the option to use a pool with a configurable fee schedule where the base fee starts high and drops over time (linearly or exponentially). This is designed to deter sniper bots by imposing higher fees during the start of the launch and initial launch phase.

How does it work?

A fee schedule for a pool can be configured, where the % fee charged per swap changes over time, ending at a % base fee set by the pool creator. The change in fee can be based on a linear or exponential curve.

Token launches or integrators can use their preferred config when setting up their pool.

Current Default Fee Schedule on Meteora Frontend

These parameters for the Fee Scheduler can be configured in advance, but the Meteora uses a few default configurations when a pool is created via the UI.

DAMM v1

For a DAMM v1 pool using the fee scheduler, the default global fee schedule config used on the Meteora frontend is based on a Linear curve, with the following schedule:

  • 15% - when pool trading starts

  • 7% - 10 min after pool trading starts (10 min after 15% starts)

  • 5% - 130 min after pool trading starts (120 min after 7% starts)

  • 2% - 250 min after pool trading starts (120 min after 5% starts)

  • 1% - 370 min after pool trading starts (120 min after 2% starts)

  • 0.5% - 490 min after pool trading starts (120 min after 1% starts)

  • 0.25% - 24 hours after pool trading starts (950 min after 0.5% starts)

DAMM v2

For a DAMM v2 pool using the fee scheduler, the default fee schedule config used on the Meteora frontend is based on an Exponential curve, 50% when pool trading starts, and dropping every second for 120 min, ending at 0.25%. DAMM v2 also offers creators and integrators the option of a Linear curve if required.

Fee Schedule (Exponential) Example

Just as an example, here's a look at the % fee at different time intervals:

  • 50% - when pool trading starts

  • 32.15% - 10 min after pool trading starts (10 min after 50% starts)

  • 20.67% - 20 min after pool trading starts (10 min after 32.15% starts)

  • 13.29% - 30 min after pool trading starts (10 min after 20.67% starts)

  • 8.55% - 40 min after pool trading starts (10 min after 13.29% starts)

  • 5.50% - 50 min after pool trading starts (10 min after 8.55% starts)

  • 3.53% - 60 min after pool trading starts (10 min after 5.50% starts)

  • 2.27% - 70 min after pool trading starts (10 min after 3.53% starts)

  • 1.46% - 80 min after pool trading starts (10 min after 2.27% starts)

  • 0.94% - 90 min after pool trading starts (10 min after 1.46% starts)

  • 0.60% - 100 min after pool trading starts (10 min after 0.94% starts)

  • 0.39% - 110 min after pool trading starts (10 min after 0.60% starts)

  • 0.25% - 120 min after pool trading starts (10 min after 0.39% starts)

Fee Schedule (Linear ) Example

Notes on DAMM v2 Fee Scheduler

By default, LP Fees drop over time per second. But partners using the pool creation setup script have the following options:

  • Time based: Fees change per second

  • Slot based: Fees change per slot (1 slot = 1 block = 0.4 secs)

Fee Scheduler Calculation

  • when in linear feeSchedulerMode: fee = cliff_fee_numerator - (period * reduction_factor)

  • when in exponential feeSchedulerMode: fee = cliff_fee_numerator * (1 - reduction_factor/10_000)^period

baseFee: {
            cliffFeeNumerator: BN // Initial fee numerator (base fee)
            numberOfPeriod: number // The number of reduction periods
            reductionFactor: BN // How much fee reduces in each period
            periodFrequency: BN // How often fees change
            feeSchedulerMode: number // 0: Linear, 1: Exponential

Which Launch Pools support the Fee Scheduler feature?

The Fee Scheduler feature is available as an option for DAMM v1 Launch Pools and DAMM v2 Launch Pools.

In addition, Fee Scheduler can be used together with Dynamic Fee to bolster the defence against sniper bots at launch.

3. Alpha Vault

Alpha Vault is a complementary anti-bot mechanism used together with a Launch Pool that provides early 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.

How does it work?

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

Deposit Period

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.

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.

Buying Period

The Alpha Vault is whitelisted to buy tokens from the pool BEFORE the pool is activated to start trading. After the deposit period ends (and before the pool starts trading), the SOL or USDC collected in the Alpha Vault is used to purchase tokens from the 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.

If the Alpha Vault is using the Pro rata mode (which accepts unlimited deposits), depositors are able to withdraw any unused SOL or USDC that exceeded the Alpha Vault max buy cap.

Token Claiming

When the token unlocks for claiming, the Alpha Vault then distributes the tokens to depositors. Depositors get tokens at the same price, and the amount of tokens received is based on their share of the total deposits.

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.

This 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.

Example Flow (Pro Rata mode example)

Alpha Vault Modes

  • Pro Rata

  • FCFS (First come first serve)

Pro Rata

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.

FCFS

FCFS (First Come First Serve) 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.

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).

Which Launch Pools can be used with Alpha Vault?

Available for DLMM, DAMM v1, and DAMM v2 Launch Pools.

PreviousDBC Migrator KeeperNextDLMM Integration

Last updated 7 days ago

For more information, please visit .

For more information on DAMM v1 pool and fee configuration, visit .

Read about .

For more information on DAMM v2 pool and fee configuration, visit .

Read the CLOUD Launch Case Study .

To learn more about Alpha Vault, visit .

this section
here
how Pump.Science uses DAMM v2's Fee Scheduler for its token launchpad
here
here
here