>,
) -> Result<()> {
let cpi_program = ctx.accounts.zap_program.to_account_info();
let cpi_accounts = ZapOutCtx {
user_token_in_account: ctx.accounts.user_token_in_account.to_account_info(),
amm_program: ctx.accounts.amm_program.to_account_info(),
};
cpi::zap_out(
CpiContext::new(cpi_program, cpi_accounts)
.with_remaining_accounts(remaining_accounts),
params,
)
}
```
The remaining accounts are forwarded by Zap to the whitelisted downstream swap instruction. Their order, signer flags, and writable flags must match the downstream program's expected account list.
## Common CPI Calls
| CPI call | Account context | Parameters | Notes |
| --------------------------------------------- | ------------------------------------- | --------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| `cpi::initialize_ledger_account` | `InitializeLedgerAccountCtx` | None | Creates `UserLedger` at `["user_ledger", owner]`. |
| `cpi::close_ledger_account` | `CloseLedgerAccountCtx` | None | Closes the ledger and sends rent to `rent_receiver`. |
| `cpi::set_ledger_balance` | `SetLedgerBalanceCtx` | `amount`, `is_token_a` | Writes a direct token A/X or token B/Y amount. |
| `cpi::update_ledger_balance_after_swap` | `UpdateLedgerBalanceAfterSwapCtx` | `pre_source_token_balance`, `max_transfer_amount`, `is_token_a` | Stores a capped token-account balance delta. |
| `cpi::zap_out` | `ZapOutCtx` | `ZapOutParameters` | Invokes a whitelisted downstream swap payload. |
| `cpi::zap_in_damm_v2` | `ZapInDammv2Ctx` | `pre_sqrt_price`, `max_sqrt_price_change_bps` | Adds liquidity to an existing DAMM v2 position and may CPI to DAMM v2 `swap2`. |
| `cpi::zap_in_dlmm_for_initialized_position` | `ZapInDlmmForInitializedPositionCtx` | DLMM bin, strategy, and remaining-account info args | Rebalances an existing DLMM position. |
| `cpi::zap_in_dlmm_for_uninitialized_position` | `ZapInDlmmForUnintializedPositionCtx` | DLMM bin, strategy, and remaining-account info args | Initializes a new DLMM position, then rebalances liquidity. |
The uninitialized DLMM account context name is spelled `ZapInDlmmForUnintializedPositionCtx` in the current Rust source. Use the generated binding name exactly.
## Zap-Out CPI Requirements
| Requirement | Details |
| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Whitelisted program | `amm_program` and the first 8 bytes of `payload_data` must match DAMM v2 `swap2`, DLMM `swap2`, Jupiter V6 `route`, or Jupiter V6 `shared_accounts_route`. |
| Amount offset | DAMM v2 and DLMM use offset `8`; Jupiter V6 route payloads use `payload_data.length - 19`. |
| Input token account | `user_token_in_account` is the token account whose balance increase Zap will swap. |
| Signers | Downstream signer accounts in `remaining_accounts` must already be transaction signers or PDA signer accounts provided by the caller. |
| Balance delta | Zap swaps only `post_balance - pre_user_token_balance`, multiplied by `percentage` and capped by `max_swap_amount`. |
## Zap-In CPI Requirements
| Flow | Required setup |
| ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| DAMM v2 zap in | Ledger initialized and populated, existing DAMM v2 position, position NFT account, pool vaults, token mints, token programs, DAMM v2 program, and DAMM v2 event authority. |
| DLMM initialized zap in | Ledger initialized and populated, existing DLMM position, LbPair, reserves, token accounts, token mints, token programs, memo program, system program, DLMM event authority, bin arrays, and transfer-hook accounts when required. |
| DLMM uninitialized zap in | Same as initialized, but `position` is a fresh signer and Zap calls DLMM `initialize_position2`. |
Zap does not emit its own custom events, but DAMM v2 and DLMM downstream CPI calls require their event authority accounts.
## Token And Account Planning
| Area | CPI guidance |
| ------------------ | ------------------------------------------------------------------------------------------------------------------- |
| Token accounts | Create ATAs or token accounts before calling Zap. The CPI helpers do not create them for you. |
| Native SOL | Wrap SOL into a token account before CPI and unwrap after your flow if needed. |
| Token 2022 | Pass the correct token program for each mint and include transfer-hook extra accounts for DLMM flows when required. |
| Ledger cleanup | Close the ledger after the zap-in instruction when it is no longer needed. |
| Remaining accounts | Preserve the exact downstream account order generated by the corresponding SDK or IDL helper. |
## Common CPI Failures
| Error area | CPI-side fix |
| ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| `InvalidOffset` | Recalculate `offset_amount_in` for the exact serialized payload. |
| `AmmIsNotSupported` | Match the payload discriminator to the downstream program ID. |
| Ledger owner mismatch | Derive the ledger from the same `owner` signer used in the CPI context. |
| DLMM invalid position | Use the initialized-position path for existing positions, or pass a fresh signer for the uninitialized-position path. |
| Downstream account error | Include event authorities, bin arrays, token programs, transfer-hook accounts, and any rate-limiter accounts required by the downstream route. |
## Best Practices
| Practice | Why it matters |
| ------------------------------------ | -------------------------------------------------------------------------------------------------------------------- |
| Prefer generated bindings | Anchor CPI helpers keep account structs and argument order aligned with the IDL. |
| Use SDK-built payloads as references | The TypeScript SDK source shows the exact DAMM v2, DLMM, and Jupiter payload formats. |
| Simulate full flows | Zap calls downstream programs and depends on token balance deltas. |
| Keep caps conservative | `max_transfer_amount` and `max_swap_amount` are safety limits, not quote outputs. |
| Test every route variant | DAMM v2, DLMM, Jupiter route, Jupiter shared route, Token 2022, and native SOL paths differ in account requirements. |
# Zap TS SDK Examples
Source: https://docs.meteora.ag/developer-guides/zap/typescript-sdk/examples
Explore Zap TypeScript examples for DAMM v2 zap in, DLMM zap in, zap out through Jupiter, and DLMM position rebalancing.
These examples use the SDK methods exported by `@meteora-ag/zap-sdk`. The SDK returns unsigned `Transaction` objects; sign and submit them with your wallet adapter, backend signer, or test keypair.
## Create A Client
```typescript theme={"system"}
import { Connection } from "@solana/web3.js";
import { Zap } from "@meteora-ag/zap-sdk";
const connection = new Connection(process.env.RPC_URL!, "confirmed");
const zap = new Zap(connection, {
jupiterApiUrl: "https://api.jup.ag",
jupiterApiKey: process.env.JUPITER_API_KEY,
});
```
## Submit Zap-In Transactions In Order
Zap-in builders return multiple transactions because swaps, ledger writes, zap instructions, and cleanup are deliberately separated.
```typescript theme={"system"}
import { Transaction } from "@solana/web3.js";
const transactions: Transaction[] = [];
if (result.setupTransaction) {
transactions.push(result.setupTransaction);
}
transactions.push(...result.swapTransactions);
transactions.push(result.ledgerTransaction);
transactions.push(result.zapInTransaction);
transactions.push(result.cleanUpTransaction);
for (const tx of transactions) {
tx.feePayer = user.publicKey;
tx.recentBlockhash = (await connection.getLatestBlockhash()).blockhash;
}
```
If a DLMM zap-in creates a new position, sign the zap transaction with the generated `position` keypair as well as the user.
## DAMM v2 Direct Zap In
Use this path when the input token is one of the DAMM v2 pool tokens. `dammV2Quote` and `jupiterQuote` are used to choose the swap route for balancing; pass `null` for a route you do not want to consider.
```typescript theme={"system"}
import { BN } from "@coral-xyz/anchor";
import { PublicKey } from "@solana/web3.js";
import { getJupiterQuote } from "@meteora-ag/zap-sdk";
const user = wallet.publicKey;
const pool = new PublicKey("DAMM_V2_POOL_ADDRESS");
const inputTokenMint = new PublicKey("INPUT_TOKEN_MINT");
const positionNftMint = new PublicKey("POSITION_NFT_MINT");
const amountIn = new BN(1_000_000);
const jupiterQuote = await getJupiterQuote(
inputTokenMint,
new PublicKey("OTHER_POOL_TOKEN_MINT"),
amountIn,
40,
300,
false,
true,
true,
{ jupiterApiKey: process.env.JUPITER_API_KEY },
);
const params = await zap.getZapInDammV2DirectPoolParams({
user,
inputTokenMint,
amountIn,
pool,
positionNftMint,
maxSqrtPriceChangeBps: 1_000,
maxTransferAmountExtendPercentage: 20,
maxAccounts: 40,
slippageBps: 300,
dammV2Quote: null,
jupiterQuote,
});
const result = await zap.buildZapInDammV2Transaction(params);
```
The source repository includes richer DAMM v2 examples that prepare both DAMM v2 and Jupiter quotes. The published package root exports the generic Jupiter helpers; use DAMM v2 SDK quote helpers directly when you want to compare both routes.
## DLMM Direct Zap In
Use this path when the input token is token X or token Y of the DLMM pair.
```typescript theme={"system"}
import { StrategyType } from "@meteora-ag/dlmm";
import { BN } from "@coral-xyz/anchor";
import { Keypair, PublicKey } from "@solana/web3.js";
import { estimateDlmmDirectSwap } from "@meteora-ag/zap-sdk";
const user = wallet.publicKey;
const lbPair = new PublicKey("DLMM_PAIR_ADDRESS");
const inputTokenMint = new PublicKey("TOKEN_X_OR_TOKEN_Y_MINT");
const amountIn = new BN(100_000_000);
const position = Keypair.generate();
const estimate = await estimateDlmmDirectSwap({
amountIn,
inputTokenMint,
lbPair,
connection,
swapSlippageBps: 150,
minDeltaId: -34,
maxDeltaId: 34,
strategy: StrategyType.Spot,
config: { jupiterApiKey: process.env.JUPITER_API_KEY },
});
const params = await zap.getZapInDlmmDirectParams({
user,
directSwapEstimate: estimate.result,
maxActiveBinSlippage: 50,
favorXInActiveId: false,
maxAccounts: 50,
maxTransferAmountExtendPercentage: 0,
...estimate.context,
});
const result = await zap.buildZapInDlmmTransaction({
...params,
position: position.publicKey,
});
```
The generated `position` keypair must sign the transaction that includes `zapInTransaction` because the Zap program calls DLMM `initialize_position2`.
## Zap Out Through Jupiter
Use zap out when another instruction first creates a balance increase in the user's input token account, for example after a claim or remove-liquidity action.
```typescript theme={"system"}
import { BN } from "@coral-xyz/anchor";
import { PublicKey, Transaction } from "@solana/web3.js";
import {
getJupiterQuote,
getJupiterSwapInstruction,
getTokenProgramFromMint,
} from "@meteora-ag/zap-sdk";
const user = wallet.publicKey;
const inputMint = new PublicKey("INPUT_MINT");
const outputMint = new PublicKey("OUTPUT_MINT");
const maxSwapAmount = new BN(1_000_000);
const quote = await getJupiterQuote(
inputMint,
outputMint,
maxSwapAmount,
40,
50,
false,
true,
true,
{ jupiterApiKey: process.env.JUPITER_API_KEY },
);
if (!quote) {
throw new Error("Jupiter quote unavailable");
}
const swapInstructionResponse = await getJupiterSwapInstruction(user, quote, {
jupiterApiKey: process.env.JUPITER_API_KEY,
});
const inputTokenProgram = await getTokenProgramFromMint(connection, inputMint);
const outputTokenProgram = await getTokenProgramFromMint(connection, outputMint);
const zapOutTx = await zap.zapOutThroughJupiter({
user,
inputMint,
outputMint,
inputTokenProgram,
outputTokenProgram,
jupiterSwapResponse: swapInstructionResponse,
maxSwapAmount,
percentageToZapOut: 100,
});
const tx = new Transaction()
.add(upstreamClaimOrWithdrawInstruction)
.add(zapOutTx);
```
`zapOutThroughJupiter` reads the user's input token balance before the zap-out instruction is built. Build the zap-out transaction after you know which token account receives the upstream balance increase.
## DLMM Position Rebalance
`rebalanceDlmmPosition` builds a full rebalance sequence for an existing DLMM position: remove liquidity through DLMM helpers, optionally swap the withdrawn tokens, write ledger balances, zap back in, and clean up.
```typescript theme={"system"}
import { StrategyType } from "@meteora-ag/dlmm";
import { PublicKey } from "@solana/web3.js";
import { estimateDlmmRebalanceSwap } from "@meteora-ag/zap-sdk";
const user = wallet.publicKey;
const lbPair = new PublicKey("DLMM_PAIR_ADDRESS");
const position = new PublicKey("DLMM_POSITION_ADDRESS");
const estimate = await estimateDlmmRebalanceSwap({
lbPair,
position,
connection,
swapSlippageBps: 150,
minDeltaId: -34,
maxDeltaId: 34,
strategy: StrategyType.Spot,
config: { jupiterApiKey: process.env.JUPITER_API_KEY },
});
const result = await zap.rebalanceDlmmPosition({
user,
liquiditySlippageBps: 50,
favorXInActiveId: false,
directSwapEstimate: estimate.result,
...estimate.context,
});
```
# Zap TS SDK Getting Started
Source: https://docs.meteora.ag/developer-guides/zap/typescript-sdk/getting-started
Learn how to install @meteora-ag/zap-sdk, create a Zap client, configure Jupiter access, and plan Zap transaction sequences.
This guide shows how to install and initialize the official Zap TypeScript SDK, `@meteora-ag/zap-sdk`.
Before you begin, here are the main resources:
Zap TypeScript SDK repository.
Published package for transaction builders, state reads, PDA helpers, and examples.
## Install
To use the SDK in your project, install it with your preferred package manager:
```bash theme={"system"}
npm install @meteora-ag/zap-sdk @solana/web3.js @solana/spl-token @coral-xyz/anchor bn.js
```
```bash theme={"system"}
pnpm install @meteora-ag/zap-sdk @solana/web3.js @solana/spl-token @coral-xyz/anchor bn.js
```
```bash theme={"system"}
yarn add @meteora-ag/zap-sdk @solana/web3.js @solana/spl-token @coral-xyz/anchor bn.js
```
## Dependencies
| Package | Version |
| ------------------------ | ------------------ |
| `@coral-xyz/anchor` | `^0.31.0` |
| `@solana/web3.js` | `^1.98.0` |
| `@solana/spl-token` | `^0.3.10` or newer |
| `@meteora-ag/cp-amm-sdk` | Compatible |
| `@meteora-ag/dlmm` | Compatible |
| `bn.js` | `^5.2.1` |
| `decimal.js` | `^10.4.3` |
## Create A Client
```typescript theme={"system"}
import { Connection } from "@solana/web3.js";
import { Zap } from "@meteora-ag/zap-sdk";
const connection = new Connection(process.env.RPC_URL!, "confirmed");
const zap = new Zap(connection, {
jupiterApiUrl: "https://api.jup.ag",
jupiterApiKey: process.env.JUPITER_API_KEY,
});
```
`jupiterApiUrl` and `jupiterApiKey` are optional in the SDK constructor. Pass them whenever your Jupiter endpoint requires authenticated quote or swap-instruction requests. You can get the API key from [Jupiter Developer Portal](https://developers.jup.ag/sign-in).
## Program ID
| Network | Program ID |
| ------------ | --------------------------------------------- |
| Mainnet Beta | `zapvX9M3uf5pvy4wRPAbQgdQsM1xmuiFnkfHKPvwMiz` |
| Devnet | `zapvX9M3uf5pvy4wRPAbQgdQsM1xmuiFnkfHKPvwMiz` |
The SDK also exports `ZAP_PROGRAM_ID`, `DAMM_V2_PROGRAM_ID`, `DLMM_PROGRAM_ID`, `JUP_V6_PROGRAM_ID`, and `MEMO_PROGRAM_ID`.
## Transaction Model
Zap builders return unsigned `Transaction` objects. The caller is responsible for fee payer, blockhash, signing, simulation, and submission.
| Flow stage | Purpose |
| -------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| Setup transaction | Create token accounts and wrap native SOL when required. |
| Swap transaction or transactions | Move the input token into pool token A/B or X/Y before zap-in, or perform a standalone swap used in rebalancing. |
| Ledger transaction | Initialize or reset `UserLedger`, then record token amounts from direct balances or post-swap deltas. |
| Zap transaction | Call the Zap program to add liquidity, rebalance DLMM liquidity, or invoke a whitelisted zap-out swap payload. |
| Cleanup transaction | Close the ledger and unwrap native SOL when required. |
For zap-in flows, preserve this order. The ledger stores intermediate token amounts that the following Zap instruction consumes.
## Supported SDK Workflows
| Workflow | Methods |
| ------------------------------------ | ------------------------------------------------------------------------------------------ |
| DAMM v2 zap in, direct input token | `getZapInDammV2DirectPoolParams`, then `buildZapInDammV2Transaction` |
| DAMM v2 zap in, indirect input token | `getZapInDammV2IndirectPoolParams`, then `buildZapInDammV2Transaction` |
| DLMM zap in, direct input token | `estimateDlmmDirectSwap`, `getZapInDlmmDirectParams`, then `buildZapInDlmmTransaction` |
| DLMM zap in, indirect input token | `estimateDlmmIndirectSwap`, `getZapInDlmmIndirectParams`, then `buildZapInDlmmTransaction` |
| DLMM position rebalance | `estimateDlmmRebalanceSwap`, then `rebalanceDlmmPosition` |
| Zap out through DAMM v2 | `zapOutThroughDammV2` |
| Zap out through DLMM | `zapOutThroughDlmm` |
| Zap out through Jupiter | `getJupiterQuote`, `getJupiterSwapInstruction`, then `zapOutThroughJupiter` |
| Low-level zap out | `zapOut` with your own whitelisted payload and account metas |
## Testing the SDK
If you have cloned the SDK repository, start with package-level checks and tests:
```bash theme={"system"}
pnpm install
pnpm run build
pnpm test
```
# Zap TS SDK Reference
Source: https://docs.meteora.ag/developer-guides/zap/typescript-sdk/reference
Understand @meteora-ag/zap-sdk exports, Zap methods, constants, helper functions, route estimators, types, and transaction outputs.
This page is based on `@meteora-ag/zap-sdk`. Use it as the high-level map, then open the package types when you need exact parameter shapes.
```typescript theme={"system"}
import {
Zap,
ZAP_PROGRAM_ID,
estimateDlmmDirectSwap,
estimateDlmmIndirectSwap,
estimateDlmmRebalanceSwap,
getJupiterQuote,
getJupiterSwapInstruction,
deriveLedgerAccount,
} from "@meteora-ag/zap-sdk";
```
## Dependencies
| Package | Use |
| ------------------------ | -------------------------------------------------------------------------------- |
| `@coral-xyz/anchor` | Program client, IDL types, and `BN`. |
| `@solana/web3.js` | Connections, public keys, transactions, and account metas. |
| `@solana/spl-token` | Token accounts, ATAs, Token 2022, and wrapped SOL helpers. |
| `@meteora-ag/cp-amm-sdk` | DAMM v2 state, position derivation, token program flags, and swap quote helpers. |
| `@meteora-ag/dlmm` | DLMM state, strategies, bin arrays, quotes, and rebalance helpers. |
| `bn.js` | Integer token amount inputs and SDK return values. |
| `decimal.js` | UI amount conversion, route comparison, and estimate calculations. |
## Program IDs
| Constant | Value |
| -------------------- | --------------------------------------------- |
| `ZAP_PROGRAM_ID` | `zapvX9M3uf5pvy4wRPAbQgdQsM1xmuiFnkfHKPvwMiz` |
| `DAMM_V2_PROGRAM_ID` | `cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG` |
| `DLMM_PROGRAM_ID` | `LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo` |
| `JUP_V6_PROGRAM_ID` | `JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4` |
| `MEMO_PROGRAM_ID` | `MemoSq4gqABAXKb96qnH8TysNcWxMyWCqXgDLGmfcHr` |
## Creating A Client
```typescript theme={"system"}
import { Connection } from "@solana/web3.js";
import { Zap } from "@meteora-ag/zap-sdk";
const connection = new Connection(process.env.RPC_URL!, "confirmed");
const zap = new Zap(connection, {
jupiterApiUrl: "https://api.jup.ag",
jupiterApiKey: process.env.JUPITER_API_KEY,
});
```
| Constructor option | Type | Default | Use |
| ------------------ | -------- | -------------------- | ----------------------------------------------------- |
| `jupiterApiUrl` | `string` | `https://api.jup.ag` | Jupiter quote and swap-instruction endpoint base URL. |
| `jupiterApiKey` | `string` | Empty string | Optional API key header for Jupiter requests. |
## Zap Methods
| Method | Returns | Use |
| ------------------------------------------ | ------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| `constructor(connection, config?)` | `Zap` | Create a Zap client with an Anchor `Program` from the bundled IDL. |
| `getZapInDammV2DirectPoolParams(params)` | `ZapInDammV2DirectPoolParam` | Prepare DAMM v2 zap-in params when the input mint is token A or token B. |
| `getZapInDammV2IndirectPoolParams(params)` | `ZapInDammV2IndirectPoolParam` | Prepare DAMM v2 zap-in params when the input mint is neither pool token. |
| `buildZapInDammV2Transaction(params)` | `ZapInDammV2Response` | Build setup, swap, ledger, zap-in, and cleanup transactions for DAMM v2. |
| `getZapInDlmmDirectParams(params)` | `ZapInDlmmDirectPoolParam` | Prepare DLMM zap-in params when the input mint is token X or token Y. |
| `getZapInDlmmIndirectParams(params)` | `ZapInDlmmIndirectPoolParam` | Prepare DLMM zap-in params when the input mint is neither pool token. |
| `buildZapInDlmmTransaction(params)` | `ZapInDlmmResponse` | Build setup, swap, ledger, zap-in, and cleanup transactions for a new DLMM position. |
| `rebalanceDlmmPosition(params)` | `RebalanceDlmmPositionResponse` | Build a DLMM remove-liquidity, optional swap, ledger, zap-in, and cleanup sequence for an existing position. |
| `zapOut(params)` | `Transaction` | Low-level generic zap-out builder with caller-supplied payload and account metas. |
| `zapOutThroughJupiter(params)` | `Transaction` | Build a zap-out transaction using a Jupiter V6 swap-instruction response. |
| `zapOutThroughDammV2(params)` | `Transaction` | Build a zap-out transaction through DAMM v2 `swap2`. |
| `zapOutThroughDlmm(params)` | `Transaction` | Build a zap-out transaction through DLMM `swap2`. |
## Zap-In Parameter Builders
| Method | Required route inputs | Important controls |
| ---------------------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| `getZapInDammV2DirectPoolParams` | `user`, `inputTokenMint`, `amountIn`, `pool`, `positionNftMint`, optional DAMM v2 and Jupiter quotes | `maxSqrtPriceChangeBps`, `slippageBps`, `maxAccounts`, `maxTransferAmountExtendPercentage` |
| `getZapInDammV2IndirectPoolParams` | `user`, `inputTokenMint`, `amountIn`, `pool`, `positionNftMint`, optional Jupiter quotes to token A and token B | Same DAMM v2 controls plus per-side route estimates |
| `getZapInDlmmDirectParams` | `user`, `lbPair`, `inputTokenMint`, `amountIn`, `directSwapEstimate` | `minDeltaId`, `maxDeltaId`, `strategy`, `favorXInActiveId`, `maxActiveBinSlippage`, `singleSided` |
| `getZapInDlmmIndirectParams` | `user`, `lbPair`, `inputTokenMint`, `amountIn`, `indirectSwapEstimate` | Same DLMM controls plus Jupiter route caps |
## Zap-In Responses
| Response type | Fields |
| ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `ZapInDammV2Response` | `setupTransaction?`, `swapTransactions`, `ledgerTransaction`, `zapInTransaction`, `cleanUpTransaction` |
| `ZapInDlmmResponse` | `setupTransaction?`, `swapTransactions`, `ledgerTransaction`, `zapInTransaction`, `cleanUpTransaction` |
| `RebalanceDlmmPositionResponse` | `setupTransaction`, `initBinArrayTransaction?`, `rebalancePositionTransaction?`, `swapTransaction?`, `ledgerTransaction`, `zapInTransaction`, `cleanUpTransaction`, `estimation` |
## Zap-Out Methods
| Method | Route source | Notes |
| ---------------------- | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------- |
| `zapOut` | Caller-supplied whitelisted payload | Lowest-level builder. Use only when you already know the downstream account order and amount offset. |
| `zapOutThroughJupiter` | Jupiter V6 swap-instruction response | Builds ATAs, calculates reverse amount offset, forwards Jupiter accounts, and unwraps SOL when needed. |
| `zapOutThroughDammV2` | DAMM v2 pool state and `createDammV2SwapPayload` | Builds DAMM v2 remaining accounts and uses amount offset `8`. |
| `zapOutThroughDlmm` | DLMM pair state and `createDlmmSwapPayload` | Builds DLMM remaining accounts, including transfer-hook slices when required, and uses amount offset `8`. |
## Estimator Functions
| Function | Use |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| `estimateDlmmDirectSwap(params)` | Estimate whether and how much to swap when the input mint is token X or token Y. Compares DLMM and Jupiter routes. |
| `estimateDlmmIndirectSwap(params)` | Estimate split amounts to swap an unrelated input token into token X and/or token Y through Jupiter. |
| `estimateDlmmRebalanceSwap(params)` | Estimate the swap needed after removing liquidity from an existing DLMM position before zapping back in. |
## Jupiter Helpers
| Function | Use |
| -------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| `getJupiterQuote(inputMint, outputMint, amount, maxAccounts, slippageBps, dynamicSlippage, onlyDirectRoutes, restrictIntermediateTokens, config?)` | Fetch a Jupiter quote. Returns `null` when the request fails or the endpoint rejects it. |
| `getJupiterSwapInstruction(userPublicKey, quoteResponse, config?)` | Fetch Jupiter swap instructions for a quote. Throws when the request fails. |
| `buildJupiterSwapTransaction(user, inputMint, outputMint, amount, maxAccounts, slippageBps, quote?, config?)` | Build a transaction containing the Jupiter swap instruction. Reuses a supplied quote when provided. |
## DAMM v2 Helpers
| Function | Use |
| ------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------ |
| `getDammV2Pool(connection, poolAddress)` | Fetch a DAMM v2 pool state through `@meteora-ag/cp-amm-sdk`. |
| `getDammV2RemainingAccounts(poolAddress, user, userInputTokenAccount, userTokenOutAccount, tokenAProgram, tokenBProgram, poolState)` | Build account metas for DAMM v2 `swap2` in zap-out flows. |
| `createDammV2SwapPayload(amountIn, minimumSwapAmountOut)` | Serialize DAMM v2 `swap2` payload data for generic `zapOut`. |
| `isSingleSidedA(poolState)` / `isSingleSidedB(poolState)` | Detect DAMM v2 single-sided pool boundary states. |
## DLMM Helpers
| Function | Use |
| ------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- |
| `getLbPairState(connection, lbPair)` | Fetch a DLMM pair state. |
| `getDlmmRemainingAccounts(connection, lbPair, user, userInputTokenAccount, userTokenOutAccount, tokenXProgram, tokenYProgram, lbPairState)` | Build DLMM swap remaining accounts and `RemainingAccountInfo`. |
| `createDlmmSwapPayload(amountIn, minimumSwapAmountOut, remainingAccountsInfo)` | Serialize DLMM `swap2` payload data for generic `zapOut`. |
| `getBinArrayBitmapExtension(connection, binArray)` | Decode a bin array bitmap extension account when it exists. |
| `getNextBinArrayIndexWithLiquidity(...)` | Scan DLMM bitmap state for the next bin array with liquidity. |
| `toProgramStrategyType(strategy)` | Convert DLMM SDK strategy enum values into Zap IDL enum values. |
| `convertAccountTypeToNumber(accountType)` | Encode DLMM remaining-account slice account types. |
## PDA, Token, And Utility Helpers
| Function | Use |
| -------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| `deriveLedgerAccount(owner)` | Derive the Zap user ledger PDA. |
| `deriveDammV2EventAuthority()` | Derive DAMM v2 event authority. |
| `deriveDammV2PoolAuthority()` | Derive DAMM v2 pool authority. |
| `deriveDlmmEventAuthority()` | Derive DLMM event authority. |
| `getOrCreateATAInstruction(connection, tokenMint, owner, payer, allowOwnerOffCurve, tokenProgram)` | Return an ATA and an idempotent creation instruction. |
| `getTokenProgramFromMint(connection, mint)` | Detect SPL Token versus Token 2022 from mint ownership, defaulting to SPL Token on lookup failure. |
| `getTokenAccountBalance(connection, tokenAccount)` | Return a token-account balance string, or `"0"` when the account lookup fails. |
| `wrapSOLInstruction(from, to, amount, tokenProgram?)` | Build native SOL wrap instructions. |
| `unwrapSOLInstruction(owner, receiver, allowOwnerOffCurve?)` | Build a wrapped SOL close-account instruction. |
| `filterOutCloseSplTokenAccountInstructions(instructions)` | Remove SPL Token `CloseAccount` instructions from a list. |
| `getExtraAccountMetasForTransferHook(connection, mint)` | Return Token 2022 transfer-hook extra accounts for a mint. |
| `convertLamportsToUiAmount(amount, decimals)` / `convertUiAmountToLamports(amount, decimals)` | Convert between integer and UI decimal amounts. |
## Constants And Enums
| Export | Values or meaning |
| --------------------------------- | ------------------------------------------------------------------- |
| `AMOUNT_IN_DAMM_V2_OFFSET` | `8` |
| `AMOUNT_IN_DLMM_OFFSET` | `8` |
| `AMOUNT_IN_JUP_V6_REVERSE_OFFSET` | `19` |
| `DAMM_V2_SWAP_DISCRIMINATOR` | DAMM v2 `swap2` discriminator. |
| `DLMM_SWAP_DISCRIMINATOR` | DLMM `swap2` discriminator. |
| `DEFAULT_JUPITER_API_URL` | `https://api.jup.ag` |
| `ZapInDammV2PoolSwapRoute` | `Jupiter`, `DammV2` |
| `SwapExternalType` | `swapToA`, `swapToB`, `swapToBoth` |
| `DlmmDirectSwapQuoteRoute` | `Jupiter`, `Dlmm` |
| `DlmmSwapType` | `XToY`, `YToX`, `NoSwap` |
| `DlmmSingleSided` | `X`, `Y` |
| `AccountsType` | Transfer-hook slice account types used for DLMM remaining accounts. |
## Core Types
| Type | Use |
| --------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| `ZapConfig` | Optional Jupiter API URL and API key. |
| `ZapOutParameters` | IDL-derived payload fields for `zap_out`. |
| `ZapOutParams` | Low-level generic zap-out builder input. |
| `ZapOutThroughDammV2Params`, `ZapOutThroughDlmmParams`, `ZapOutThroughJupiterParams` | Route-specific zap-out builder inputs. |
| `GetZapInDammV2DirectPoolParams`, `GetZapInDammV2IndirectPoolParams` | DAMM v2 zap-in parameter preparation inputs. |
| `GetZapInDlmmDirectParams`, `GetZapInDlmmIndirectParams` | DLMM zap-in parameter preparation inputs. |
| `EstimateDlmmDirectSwapParams`, `EstimateDlmmIndirectSwapParams`, `EstimateDlmmRebalanceSwapParams` | DLMM estimate inputs. |
| `JupiterQuoteResponse`, `JupiterSwapInstructionResponse` | Jupiter API response shapes used by helpers. |
| `ZapProgram`, `ZapTypes`, `ZapIdl` | Anchor program type, generated IDL type, and bundled IDL JSON. |
# We Build Liquidity Pools
Source: https://docs.meteora.ag/get-started/index
The Most Composable Liquidity Layer for Liquidity Providers, Launchpads and Token Launches on Solana.
## Why Meteora?
Meteora is the dynamic liquidity infrastructure powering Solana's most successful token launches and biggest LP community. Whether you're an LP maximizing returns, a launchpad delivering deep day-one liquidity, a team launching a token, or a builder integrating liquidity primitives, Meteora gives you the tools to ship fast with unmatched capital efficiency.
The same battle-tested infrastructure powering Meteora's DLMM, DAMM, and Dynamic Bonding Curve pools is available to you through robust TypeScript and Rust SDKs, as well as free public REST APIs. We handle the complex math, so you can focus on building your product, with world-class support from the Meteora team that wants you to win.
Earn fees and rewards across Solana's largest, most active LP community.
Power day-one liquidity for every project you launch with battle-tested pools.
Bring your token to market with deep, reliable liquidity from block one.
## Products
### Core Products
Concentrated liquidity in discrete price bins with dynamic, volatility-aware fees, zero-slippage swaps within a bin and native onchain limit orders.
Constant-product AMM with position NFTs, optional concentrated ranges, and built-in anti-sniper suite.
Fully customizable bonding curves for token launches that auto-graduate to a DAMM pool once the quote threshold is hit.
### Helper Products
Run token presales with whitelists, tiers, and contributions in any SPL token.
Early-access launch vault that lets genuine supporters buy in before public trading opens.
Automatically split pool fees across multiple recipients by configurable share allocations.
Convert tokens and manage positions in a single transaction with the ability to zap in or zap out instantly.
### Legacy Products
Constant-product AMM with infinite price range, earning swap fees plus extra yield from lending integrations.
Auto-rebalances idle LP capital across Solana lending markets to boost yield on DAMM v1 pools.
Reward top token stakers with a share of locked LP trading fees from DAMM v1 pools.
## Developer Guides
Build with bin-based concentrated liquidity, native limit order and dynamic fees.
Build constant-product pools with NFT positions, anti-sniping mechanisms, and multiple fee collection modes support.
Build custom token launches with programmable 16-point curve segments that auto-graduate to a DAMM pool.
Build presales with fixed-price, FCFS, or prorata modes including tier systems, whitelists, and deposit fees.
Add anti-bot deposit vaults to DLMM, DAMM v1, or DAMM v2 launches with FCFS or prorata modes.
Create fee vaults that split collected fees across recipients natively onchain.
Combine program actions and Jupiter swaps in one transaction across DAMM v2 and DLMM pools.
Build with the legacy infinite-range AMM that contains integrated lending yield.
Integrate auto-rebalancing yield vaults powered by the Hermes yield aggregation engine.
Distribute trading fees from locked liquidity to top token stakers.
## Agents
Meteora is built for AI agents and LLM-powered development. Drop these tools into your stack to ship integrations faster.
Manage pools and run swaps from the terminal — JSON-native and agent-ready.
Drop-in skill files that teach coding agents how to integrate Meteora correctly.
Search and query Meteora docs from any MCP-compatible AI editor.
LLM-optimized documentation index for RAG pipelines and AI agents.
## Invent on Meteora
We abstract the need for understanding Meteora integration complexities by providing an all-in-one interface that any developer can use to create, enter commands and deploy liquidity pools on Solana.
Spin up a concentrated liquidity pool, with optional Alpha Vault for anti-bot protection.
Spin up a balanced or one-sided pool with optional Alpha Vault and onchain anti-sniping mechanisms.
Spin up a freshly minted DAMM v1 pool with optional Alpha Vault.
Spin up a fully customizable bonding curve that auto-graduates to a DAMM pool.
## Community
Get developer support and chat with the Meteora community.
Join Solana's largest LP community and learn winning strategies from active LPs.
Real-time program updates and product releases on Telegram.
## Socials
Product updates, technical deep dives, and launch information.
Real-time announcements, ecosystem news, and releases.
# Pushing the Boundaries of DeFi
Source: https://docs.meteora.ag/get-started/pushing-the-boundaries-of-defi
Explore the innovative DeFi programs Meteora is building on Solana, including DLMM, DAMM, DBC, and more.
**We write innovative programs that push the boundaries of DeFi on Solana.**
Concentrated Market Making, Dynamic AMMs, Launch Curves, Vault Yield, Fee Sharing, and many more - each product solves a specific market-design problem so **builders**, **protocols**, **liquidity providers**, and **traders** can go live onchain with the best capital efficiency.
## Active Programs
Active
= will have new developments and still actively maintained
| Program |
Program ID |
Open Source |
| DLMM |
LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo |
❌ |
| DAMM v2 |
cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG |
✅ |
| DBC |
dbcij3LWUppWqq96dh6gJWwBifmcGfLSB5D4DuSMaqN |
✅ |
| Presale Vault |
presSVxnf9UU8jMxhgSMqaRwNiT36qeBdNeTRKjTdbj |
✅ |
| Alpha Vault |
vaU6kP7iNEGkbmPkLmZfGwiGxd4Mob24QQCie5R9kd2 |
❌ |
| Dynamic Fee Sharing |
dfsdo2UqvwfN8DuUVrMRNfQe11VaiNoKcMqLHVvDPzh |
✅ |
| Zap |
zapvX9M3uf5pvy4wRPAbQgdQsM1xmuiFnkfHKPvwMiz |
✅ |
## Legacy Programs
Legacy
= will not have new developments but still maintained
| Program |
Program ID |
Open Source |
| DAMM v1 |
Eo7WjKq67rjJQSZxS6z3YkapzY3eMj6Xy8X5EQVn5UaB |
❌ |
| Dynamic Vault |
24Uqj9JCLxUeoC3hGfh5W3s9FM9uCHDS2SG3LYwBpyTi |
❌ |
| Stake2Earn |
FEESngU3neckdwib9X3KWqdL7Mjmqk9XNp3uh5JbP4KP |
❌ |
| Farm |
FarmuwXPWXvefWUeqFAa5w6rifLkq5X6E8bimYvrhCB1 |
❌ |
| Mercurial Stable Swap |
MERLuDFBMmsHnsBPZw2sDQZHvXFMwp8EdjudcU2HKky |
❌ |
# Why are Liquidity Pools and Liquidity Providers on Solana Important?
Source: https://docs.meteora.ag/get-started/why-are-liquidity-pools-important
Liquidity Pools are the foundation of Decentralized Finance, and Liquidity Providers are the driving force behind them.
Liquidity pools are the backbone of decentralized finance. No matter what you're building, whether it's a new token, a DApp, or a DeFi service, it all starts with liquidity. For example, if you're launching a new token, you begin with nothing. You need to create a liquidity pool to enable swaps between your token and others.
Moreover, deep liquidity for key tokens like SOL enables smooth liquidation and minimizes bad debt risks within the ecosystem. And deep liquidity for wrapped tokens (e.g., BTC, ETH) on Solana allows users to bridge assets across chains, attracting more users from other blockchain networks.
Most users tend to focus only on the DeFi app experience, overlooking the liquidity that powers it. It's important to remember that behind every trade is a liquidity pool making it possible.
### Endless Ways to Provide Liquidity
There are countless approaches to being a liquidity provider (LP). You can LP for:
* New token launches
* Memecoins or non-hyped assets
* Market-making strategies
* Major DeFi protocols or smaller experiments
* Real-world assets
Being an LP isn't one-size-fits-all, it’s a spectrum with endless possibilities.
### A Diverse Range of LPs
Being an LP can mean very different things depending on who you are and what your goals are. Liquidity provision comes from a wide array of contributors, such as:
* Professional Market Makers
* Developers who integrate liquidity pools into DApps
* Creators who launch and bootstrap liquidity for new tokens
* Launchpads that help migrate and establish liquidity for new projects
* Everyday DeFi users who provide liquidity directly to earn yield or support projects they believe in
### Liquidity Is the Fuel for Crypto’s Future
As DeFi continues to evolve, liquidity will become even more critical. The future of crypto doesn’t revolve around centralized exchanges, it lies in decentralized systems. We're heading toward a world where millions of people are launching billions of new tokens.
**Liquidity Pools** will be central to that future. We’ll need new mechanisms for **creating, launching, distributing**, and **maintaining** these tokens, and all of them will depend on liquidity pools.
**Liquidity Providers (LPs)** will be the people driving this ecosystem. They’re the ones who create, fund, and maintain the markets that make DeFi possible.
**Launchpads** will play a vital role in this shift, offering platforms for new tokens to be created and launched. The launchpad ecosystem is just getting started—what we have today is only the beginning.
# Alpha Vault Formulas
Source: https://docs.meteora.ag/helper-products/alpha-vault/formulas
Review Alpha Vault allocation, swappable amount, refund, vesting, cap, and Token 2022 transfer-fee formulas.
Alpha Vault accounting is proportional: the vault buys as one account, then users receive token claims and quote refunds based on their escrow deposit share.
All on-chain arithmetic uses integer token amounts. Division rounds down.
## Key Terms
| Term | Meaning |
| ---------------------------- | ------------------------------------------------------- |
| `total_deposit` | Total net quote amount recorded across all escrows. |
| `escrow.total_deposit` | Net quote amount recorded for one escrow. |
| `max_buying_cap` | Pro Rata quote amount cap for vault fills. |
| `max_depositing_cap` | FCFS total accepted deposit cap. |
| `swapped_amount` | Total quote amount already used by vault fills. |
| `bought_token` | Total launch token bought by the vault. |
| `claimed_token` | Launch token already claimed by an escrow. |
| `withdrawn_deposit_overflow` | Pro Rata overflow quote already withdrawn by an escrow. |
## Max Swappable Amount
The max swappable amount is mode-dependent.
```math theme={"system"}
\text{Pro Rata Max Swappable} =
\min(\text{total\_deposit}, \text{max\_buying\_cap})
```
```math theme={"system"}
\text{FCFS Max Swappable} =
\text{total\_deposit}
```
Each fill instruction also takes a `max_amount`, so the actual amount for that fill is:
```math theme={"system"}
\text{Fill Swappable Amount} =
\min(\text{Max Swappable Amount} - \text{swapped\_amount}, \text{max\_amount})
```
## User Deposit Share
Most user-facing amounts use the escrow's share of total vault deposits.
```math theme={"system"}
\text{User Share} =
\frac{\text{escrow.total\_deposit}}{\text{total\_deposit}}
```
Because this is integer math on-chain, the program multiplies before dividing and rounds down.
## Linear Vesting
The program treats both endpoints as inclusive by adding `1` to the numerator and denominator.
```math theme={"system"}
\text{Vesting Duration} =
\text{end\_vesting\_point} - \text{start\_vesting\_point} + 1
```
```math theme={"system"}
\text{Elapsed Duration} =
\min(\text{current\_point}, \text{end\_vesting\_point})
- \text{start\_vesting\_point} + 1
```
```math theme={"system"}
\text{Total Claimable Token} =
\text{bought\_token}
\times
\frac{\text{Elapsed Duration}}{\text{Vesting Duration}}
```
Claims are not allowed before `start_vesting_point`.
## User Claimable Token
```math theme={"system"}
\text{Escrow Dripped Token} =
\text{Total Claimable Token}
\times
\frac{\text{escrow.total\_deposit}}{\text{total\_deposit}}
```
```math theme={"system"}
\text{User Claimable Token} =
\text{Escrow Dripped Token} - \text{escrow.claimed\_token}
```
After a claim, the program increments both the escrow's `claimed_token` and the vault's `total_claimed_token`.
## Pro Rata Overflow Refund
Overflow is the part of total deposits that cannot be included in max swappable amount.
```math theme={"system"}
\text{Deposit Overflow} =
\text{total\_deposit} - \text{Max Swappable Amount}
```
```math theme={"system"}
\text{Escrow Overflow Refund} =
\text{Deposit Overflow}
\times
\frac{\text{escrow.total\_deposit}}{\text{total\_deposit}}
```
An escrow can withdraw this overflow after `last_join_point` and through `last_buying_point`. The program tracks `withdrawn_deposit_overflow` so repeated withdrawals only receive the remaining overflow amount.
## Final Remaining Quote Refund
After the pool's `last_buying_point`, an escrow can withdraw its share of quote left in the vault.
```math theme={"system"}
\text{Remaining Quote} =
\text{total\_deposit} - \text{swapped\_amount}
```
```math theme={"system"}
\text{Escrow Total Refund Quote} =
\text{Remaining Quote}
\times
\frac{\text{escrow.total\_deposit}}{\text{total\_deposit}}
```
```math theme={"system"}
\text{Final Refund Transfer} =
\text{Escrow Total Refund Quote}
- \text{escrow.withdrawn\_deposit\_overflow}
```
The escrow is then marked as refunded so the final remaining quote path cannot be used twice.
## FCFS Accepted Deposit
In FCFS mode, the program limits the accepted deposit amount before transfer.
```math theme={"system"}
\text{Remaining Vault Capacity} =
\text{max\_depositing\_cap} - \text{total\_deposit}
```
```math theme={"system"}
\text{Remaining User Quota} =
\text{User Cap} - \text{escrow.total\_deposit}
```
```math theme={"system"}
\text{Accepted Deposit} =
\min(
\text{requested net amount},
\text{Remaining Vault Capacity},
\text{Remaining User Quota}
)
```
If the accepted amount is `0`, the deposit fails.
## Token 2022 Transfer Fees
When the quote mint has a Token 2022 transfer fee, the vault records the fee-excluded amount as the deposit. It transfers the fee-included amount from the user so that the vault receives the intended net amount.
```math theme={"system"}
\text{Recorded Deposit} =
\text{Transfer Amount} - \text{Transfer Fee}
```
For outbound claims and refunds, emitted event amounts are fee-excluded when a transfer fee applies.
Formula examples describe the accounting path. Actual token balances can also be affected by Token 2022 transfer fees and transfer-memo requirements on destination accounts.
# Alpha Vault Launch Design Guide
Source: https://docs.meteora.ag/helper-products/alpha-vault/launch-design-guide
Choose Alpha Vault mode, caps, access model, timing, crank plan, and vesting settings based on the behavior enforced by the program.
Alpha Vault is configurable, but the best launch designs are simple enough for users to understand before they deposit.
## Start With the Allocation Goal
| Goal | Better fit |
| --------------------------------------------------- | ---------------------------------------------------- |
| Broad participation when demand may exceed capacity | Pro Rata |
| Hard accepted-deposit cap | FCFS |
| Large allowlist with wallet-specific caps | Merkle proof |
| Small curated allocation | Authority-managed escrows |
| Open community access | Permissionless, usually Pro Rata |
| Stronger post-launch alignment | Later `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
| Cap | Applies to | Design question |
| --------------------------- | ----------------------------------------- | --------------------------------------------------- |
| `max_buying_cap` | Pro Rata | How much quote should the vault be allowed to swap? |
| `max_depositing_cap` | FCFS | How much quote should the vault accept in total? |
| `individual_depositing_cap` | Permissionless FCFS | How much can one wallet contribute? |
| Escrow `max_cap` | Merkle proof and authority-managed access | What 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.
# Alpha Vault Modes
Source: https://docs.meteora.ag/helper-products/alpha-vault/vault-modes
Compare Alpha Vault Pro Rata and FCFS modes, including caps, withdrawals, overflow refunds, and how deposits are accepted.
Alpha Vault supports two vault modes: **Pro Rata** and **FCFS**.
Both modes collect quote token before launch and let the vault buy from a connected Launch Pool during pre-activation. The difference is how each mode accepts deposits, applies caps, and handles unused quote.
## Mode Comparison
| Product Area | Pro Rata | FCFS |
| -------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ |
| Main cap | `max_buying_cap` | `max_depositing_cap` |
| Max swappable amount | `min(total_deposit, max_buying_cap)` | `total_deposit` |
| Total deposits can exceed buying power | Yes | No, deposits are limited by remaining vault capacity |
| Normal user withdrawal | Allowed through `last_join_point` | Not available |
| Overflow withdrawal | Available after `last_join_point` and through `last_buying_point` when total deposits exceed max swappable amount | Not expected by design |
| Per-wallet cap | Ignored for permissionless Pro Rata because the vault returns `u64::MAX` as the individual cap | Applied in permissionless FCFS and permissioned vaults |
| Best fit | Broad participation and oversubscription | Hard capacity and scarce early access |
## Pro Rata Mode
Pro Rata mode is designed for launches where demand may exceed the amount the vault should buy.
Users can deposit during the deposit window. The vault can accept more quote than `max_buying_cap`, but it can only swap up to:
```math theme={"system"}
\min(\text{total\_deposit}, \text{max\_buying\_cap})
```
If total deposits exceed the max buying cap, every depositor participates proportionally and the excess quote becomes refundable.
### Withdrawal Rules
Pro Rata has two withdrawal paths:
| Timing | What can be withdrawn |
| ------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| From `depositing_point` through `last_join_point` | A user can withdraw their deposited quote, up to the requested amount. |
| After `last_join_point` and through `last_buying_point` | A user can withdraw their proportional deposit overflow, if the vault is oversubscribed. |
| After `last_buying_point` | A user uses `withdraw_remaining_quote` to withdraw their final remaining quote, minus any overflow already withdrawn. |
Pro Rata allocation is proportional to deposit size. A larger deposit increases a user's share, but the vault still cannot swap more than `max_buying_cap`.
## FCFS Mode
FCFS means **First Come, First Served**. It is designed for launches that want a hard cap on accepted quote.
When a user deposits, the program limits the accepted amount by:
* The user's requested amount after transfer-fee adjustment.
* The remaining vault capacity: `max_depositing_cap - total_deposit`.
* The user's remaining quota from the vault individual cap or permissioned escrow cap.
Once the vault reaches `max_depositing_cap`, additional deposits fail because the accepted deposit amount becomes zero.
FCFS does not expose the normal user withdrawal instruction. Accepted deposits are intended to remain in the vault until the fill and refund lifecycle completes.
Permissionless FCFS should use a meaningful `individual_depositing_cap` if broad distribution matters. Without a low enough cap, early wallets can consume most or all vault capacity.
## Shared Behavior
Both modes use the same claim and final refund accounting:
* Users receive a share of bought tokens based on `escrow.total_deposit / vault.total_deposit`.
* Claims unlock linearly from `start_vesting_point` through `end_vesting_point`.
* After the pool's `last_buying_point`, users can withdraw quote that was not swapped.
Both modes can be paired with permissionless, Merkle proof, or authority-managed escrow creation. Permissioned escrows use the escrow's `max_cap` as the user's quota.
# What is Alpha Vault?
Source: https://docs.meteora.ag/helper-products/alpha-vault/what-is-alpha-vault
Learn how Meteora Alpha Vault collects pre-launch quote deposits, buys from a connected Launch Pool during the protected pre-activation window, and distributes bought tokens to participants.
## Overview
Alpha Vault is Meteora's pre-launch allocation product for teams that want supporters to commit quote tokens before a Launch Pool opens for public trading.
An Alpha Vault is connected to one Meteora Launch Pool. Users deposit the pool's quote token into the vault during the deposit window. During the pool's protected pre-activation buying window, the vault can swap that quote token into the launch token before public trading begins. After the vault buys, users claim the bought token and withdraw any unused quote according to the vault configuration.
Launch Pools.Alpha Vault runs on the mainnet program `vaU6kP7iNEGkbmPkLmZfGwiGxd4Mob24QQCie5R9kd2`. The program Alpha Vault supports **DLMM**, **DAMM v1** (`DynamicPool`), and **DAMM v2**
Alpha Vault is not a separate AMM. It is an account-based allocation layer that uses the connected Launch Pool for the actual buy.
## Why Alpha Vault Exists
Public token launches can concentrate the earliest fills in the hands of bots, priority-fee races, and wallets prepared to trade the first public slot or timestamp. Alpha Vault separates commitment from execution:
* Users commit during a configured deposit window.
* The vault buys during the pool's pre-activation window.
* The vault distributes the bought token according to transparent on-chain accounting.
* Unused quote can be withdrawn through defined refund paths.
This gives teams a more deliberate launch flow while still using Meteora pool liquidity and activation mechanics.
## Core Features
Each vault is tied to one DLMM, DAMM v1, or DAMM v2 pool, and the pool must point back to that vault as its whitelisted pre-activation buyer.
Pro Rata supports oversubscription with proportional allocation. FCFS accepts deposits until the configured cap is reached.
Escrows can be permissionless, Merkle-proof based, or created by the vault authority.
Bought tokens unlock linearly from `start_vesting_point` through `end_vesting_point`, using either slots or timestamps.
Users can withdraw Pro Rata overflow and any final quote left after the vault's buying window.
Vault transfers use checked token transfers and account for Token 2022 transfer fees and required transfer memos where applicable.
## Lifecycle
```text theme={"system"}
Pool stores the Alpha Vault address
|
Vault is initialized with mode, timing, caps, and access rules
|
Users create escrows and deposit quote
|
Crankers fill the vault during the pool's pre-activation window
|
Users claim bought tokens and withdraw unused quote
```
The vault stores aggregate accounting such as `total_deposit`, `swapped_amount`, `bought_token`, `total_refund`, and `total_claimed_token`. Each participant has one escrow account for the vault. The escrow stores the user's `total_deposit`, claimed token amount, refund state, and optional permissioned `max_cap`.
The vault does not know each user's final token amount until the vault has bought tokens from the pool. Once `bought_token` is recorded, each user's share is calculated from their escrow deposit relative to `total_deposit`.
## Important Constraints
| Area | Program behavior |
| ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Quote and base mints | The vault quote mint must match the pool quote side, and the base mint must match the pool launch-token side. |
| Pool linkage | The connected pool must store the vault address as its derived or whitelisted Alpha Vault. |
| Activation type | Timing can be slot-based or timestamp-based, matching the connected pool. |
| Deposit timing | New escrows and deposits are allowed from `depositing_point` through the pool's `last_join_point`. |
| Fill timing | Vault fills are allowed from the pool's `pre_activation_start_point` through `last_buying_point`. |
| Claim timing | Token claims start at `start_vesting_point` and unlock linearly through `end_vesting_point`. |
| Escrow fee | Permissionless vaults may charge an escrow creation fee capped at `0.01 SOL`; permissioned vaults must set the escrow fee to `0`. |
| Mainnet duration limits | Lock duration and vesting duration are each capped at roughly one year. FCFS configured deposit duration must be at least the program timing buffer: `3,000` slots or `1,200` seconds, depending on activation type. |
## What To Read Next
Compare Pro Rata and FCFS behavior, including caps, withdrawals, overflow, and user experience.
Choose mode, caps, access model, deposit timing, and vesting settings for a launch.
Understand permissionless escrows, Merkle roots, authority-created escrows, and wallet caps.
Review the allocation, refund, vesting, and rounding math used by the vault.
Alpha Vault configuration affects who can deposit, how much quote can be used, when users can withdraw, and when tokens unlock. Teams should test the exact vault and pool configuration before opening deposits.
# Alpha Vault Whitelist and Access
Source: https://docs.meteora.ag/helper-products/alpha-vault/whitelist-and-access
Understand Alpha Vault permissionless escrows, Merkle proof escrows, authority-created escrows, wallet caps, vault authority, and escrow fees.
Alpha Vault controls access at the escrow-creation layer. A user must have an escrow for the vault before they can deposit.
## Access Models
| Access model | Who can create the escrow | How user quota is set |
| ----------------- | ------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| Permissionless | Anyone can create an escrow during the deposit window. | Permissionless FCFS uses `individual_depositing_cap`; permissionless Pro Rata effectively has no individual cap. |
| Merkle proof | A user or payer creates an escrow with a valid Merkle proof. | The Merkle leaf includes the wallet and `max_cap`; the escrow stores that `max_cap`. |
| Authority-managed | The vault authority creates the escrow for a selected wallet. | The authority passes a positive `max_cap`; the escrow stores that `max_cap`. |
## Permissionless Escrows
Permissionless mode lets anyone create an escrow while the vault is open. The escrow address is derived from the vault and owner, so each owner has one escrow per vault.
Permissionless vaults may charge an escrow creation fee. The program caps this fee at `10,000,000` lamports (`0.01 SOL`) and sends it to the Meteora treasury account. The fee is recorded in `total_escrow_fee` and is not refunded when the escrow is closed.
## Merkle Proof Escrows
Merkle proof mode is built for larger allowlists.
The vault authority or a program admin creates a `MerkleRootConfig` for the vault. Each user then proves membership with a leaf built from:
```text theme={"system"}
owner pubkey + max_cap
```
The program stores the supplied `max_cap` in the user's escrow after verifying the proof. Deposits are then limited by the escrow's remaining cap.
The program also supports Merkle proof metadata with a `proof_url`, which can point clients to off-chain proof data.
The Merkle root account is versioned, so teams can publish multiple root versions for the same vault when needed.
## Authority-Managed Escrows
Authority-managed mode is for curated lists. The vault authority signs the escrow creation transaction and selects the owner and `max_cap`.
This mode is operationally simple for small lists because the team can create the escrow accounts directly. It is less scalable than Merkle proof mode for large public allowlists.
## Permissioned Vault Fee Rule
Permissioned vaults cannot charge an escrow creation fee.
The initialization path rejects any nonzero `escrow_fee` when `whitelist_mode` is Merkle proof or authority-managed. This avoids charging users or teams for escrow creation in permissioned flows where the project may create many escrows.
## Vault Authority and Admins
The vault authority is normally the vault creator. It can:
* Create Merkle root configs for a Merkle-proof vault.
* Create Merkle proof metadata.
* Create authority-managed escrows when the vault uses authority mode.
* Transfer vault authority to a new pubkey.
Program admins can create global Pro Rata and FCFS config accounts, update vault parameters through admin-only instructions, create crank-fee whitelist accounts, and also create Merkle root configs or metadata.
## Wallet Caps
Caps are enforced during deposit, not just during escrow creation.
| Cap source | Applies when | Behavior |
| --------------------------- | ----------------------------------------- | --------------------------------------------------------------------- |
| `individual_depositing_cap` | Permissionless FCFS | Limits each escrow's accepted deposit. |
| `u64::MAX` | Permissionless Pro Rata | Means the individual cap is effectively ignored. |
| Escrow `max_cap` | Merkle proof and authority-managed vaults | Limits deposits for that permissioned escrow. |
| `max_depositing_cap` | FCFS vaults | Limits total accepted vault deposits. |
| `max_buying_cap` | Pro Rata vaults | Limits how much quote the vault can swap, not how much it can accept. |
# Dynamic Fee Sharing Compatibilities
Source: https://docs.meteora.ag/helper-products/dynamic-fee-sharing/compatibilities
Review Dynamic Fee Sharing limits, supported token mints, vault types, funding paths, and whitelisted source-program actions.
Dynamic Fee Sharing is intentionally narrow. This page is the compatibility reference for what the current program accepts.
## Compatibility Overview
| Area | Supported |
| ------------------------------------ | ------------------------------------------------------------- |
| Recipient count | 2 to 5 recipients per fee vault |
| Share values | Non-zero `u32` shares for each user entry |
| Recipient address | Non-default public key |
| Token standard | SPL Token and Token 2022 mints with supported extensions only |
| Vault types | Non-PDA fee vault and PDA fee vault |
| Funding methods | Manual funding and supported claim-by-integration funding |
| Claim-by-integration source programs | Whitelisted DAMM v2 and Dynamic Bonding Curve actions |
## Recipient Limits
A fee vault supports **2 to 5 recipients**.
Each recipient needs:
* A wallet address.
* A non-zero share value.
* A recipient index used when claiming.
The program rejects the default public key as a recipient address. It does not reject duplicate recipient addresses, so clients and teams should treat uniqueness as an operational requirement unless duplicate entries are intentional.
The program stores the configured recipient list in the fee vault and does not expose a general edit-recipient or edit-share instruction.
## Token Compatibility
Dynamic Fee Sharing can distribute fees in one token mint per vault.
Supported token types include:
* Standard SPL Token mints.
* Token 2022 mints with supported extensions.
For Token 2022, the program accepts mints whose extension list contains only:
* `TransferFeeConfig`
* `MetadataPointer`
* `TokenMetadata`
If a Token 2022 mint uses any other extension, initialization fails with `InvalidMint`.
If a project wants to split fees for multiple token mints, it should create one fee vault per token mint.
## Vault Types
Dynamic Fee Sharing supports two fee vault types.
| Vault Type | Compatible With | Best For |
| ----------------- | ------------------------------------------------------------- | ------------------------------------------------------- |
| Non-PDA fee vault | Manual fee funding | Standalone fee-sharing agreements. |
| PDA fee vault | Manual fee funding and supported claim-by-integration funding | Protocol-integrated fee sharing tied to a base account. |
## Funding Paths
Dynamic Fee Sharing supports two funding paths.
### Manual Funding
Manual funding works for both Non-PDA and PDA fee vaults.
A funder signs for the source token account. The program transfers `min(max_amount, source_balance)` into the token vault, records the net amount for supported transfer-fee mints, and updates fee-per-share accounting.
### Funding by Claiming Fees
Funding by claiming fees works for PDA fee vaults and only for whitelisted source-program actions.
The vault calls a supported fee-claim action, receives claimed tokens into its token vault, and then adds the token-vault balance increase to fee-sharing accounting.
Additional requirements:
* The `source_program` and instruction discriminator must match a whitelisted action.
* The whitelisted token-vault account index must point to the fee vault's token vault.
* The signer must be one of the configured share-holder addresses.
* The fee vault must be a PDA vault.
A fee vault is designed to support a single token mint and a single token vault, and `fund_by_claiming_fee` credits only the balance increase of that one token vault. The source pool's `CollectFeeMode` must therefore be configured to collect fees only in the fee vault's token mint: `OnlyB` or `Compounding` for DAMM v2 and `QuoteToken` for DBC.
## Compatible Source Programs and Actions
Dynamic Fee Sharing currently whitelists supported actions from DAMM v2 and DBC.
### DAMM v2
Supported DAMM v2 claim actions include:
| Whitelisted Action | Token Vault Account Index | Product Meaning |
| ------------------ | ------------------------- | -------------------------------------------------------------- |
| `ClaimPositionFee` | `4` | Claim trading fees from a DAMM v2 position into the fee vault. |
| `ClaimReward` | `5` | Claim DAMM v2 reward emissions into the fee vault. |
### Dynamic Bonding Curve (DBC)
Supported DBC claim and withdrawal actions include:
| Whitelisted Action | Token Vault Account Index | Product Meaning |
| ------------------------ | ------------------------- | --------------------------------------------------- |
| `CreatorWithdrawSurplus` | `3` | Route creator surplus into the fee vault. |
| `ClaimCreatorTradingFee` | `3` | Route creator trading fees into the fee vault. |
| `PartnerWithdrawSurplus` | `3` | Route partner surplus into the fee vault. |
| `ClaimTradingFee` | `4` | Route eligible DBC trading fees into the fee vault. |
| `WithdrawMigrationFee` | `3` | Route eligible migration fees into the fee vault. |
The token-vault index is part of the program's whitelist check. If an integration changes account ordering, Dynamic Fee Sharing must whitelist the matching action and account index before that claim path works.
## What Is Not a Fit
Dynamic Fee Sharing may not be the right product when:
* The recipient set changes frequently.
* There are more than 5 recipients.
* The token mint uses unsupported Token 2022 extensions.
* The fee source requires an unsupported cross-program claim action.
* The payout requires complex conditional logic instead of fixed shares.
* The setup needs owner-managed edits, admin withdrawals, or vault closure through the current program.
For those cases, teams should either use manual operational flows or build a custom distribution layer around their requirements.
# Dynamic Fee Sharing Design Guide
Source: https://docs.meteora.ag/helper-products/dynamic-fee-sharing/design-guide
Choose Dynamic Fee Sharing recipients, shares, token mint, vault type, and funding method before initializing a fee vault.
Dynamic Fee Sharing is simple after initialization, so most design work happens before a vault is created. Use this page to turn a fee-sharing agreement into a vault configuration.
## Start With the Revenue Stream
Before configuring a vault, identify the fee stream you want to split.
Answer these questions first:
* What product or campaign generates the fees?
* Which token mint will the fees be paid in?
* Who should receive the fees?
* Are there 2 to 5 stable recipient entries?
* Will fees be manually funded or claimed from a compatible Meteora product?
A clear revenue stream makes the vault easier to design and easier for recipients to understand.
## Choose the Vault Type
| Vault Type | Choose This When |
| ----------------- | ------------------------------------------------------------------------------------------------------------------- |
| Non-PDA fee vault | The vault is standalone and will be manually funded. |
| PDA fee vault | The vault should be deterministic from `base` and `token_mint`, or it needs supported claim-by-integration funding. |
If you are unsure and only need to transfer tokens into the vault manually, a Non-PDA fee vault is usually simpler.
## Choose the Token Mint
A fee vault distributes one token mint.
If your revenue stream has multiple tokens, create separate vaults. For example:
* One vault for USDC fees.
* One vault for SOL fees.
* One vault for a reward token.
This keeps each vault's accounting clear and avoids mixing assets with different decimals, transfer behavior, or recipient expectations.
## Choose Recipients
Dynamic Fee Sharing supports 2 to 5 recipients.
Good recipient entries include:
* Creator wallet
* Launchpad wallet
* Treasury wallet
* Strategy operator wallet
* Campaign partner wallet
* Contributor multisig
Because the recipient list is fixed at creation, use durable wallets. For teams, a multisig or treasury-controlled wallet is usually better than a personal hot wallet.
The program rejects the default public key, but it does not reject duplicate recipient addresses. Unless duplicate entries are intentional, check for duplicates before initialization.
## Choose Shares
Shares are relative weights. They do not need to add up to 100, but percent-style totals are easier to communicate.
Common share patterns:
| Split | Share Setup |
| ------------------ | -------------------------- |
| 50/50 | 50 and 50 |
| 70/30 | 70 and 30 |
| 80/15/5 | 80, 15, and 5 |
| Basis points style | Total shares add to 10,000 |
Use basis-points style shares when you want more precise allocations, such as 12.5% or 2.75%.
```text theme={"system"}
12.5% = 1,250 shares out of 10,000
2.75% = 275 shares out of 10,000
```
The program stores each share and total shares as `u32` values. Choose a share scale that is precise enough for the agreement but still easy for humans to audit.
## Choose the Funding Method
### Manual Funding
Manual funding is best when fees are collected outside the Dynamic Fee Sharing program or need to be batched before distribution.
Use manual funding for:
* Treasury distributions.
* Partner payouts.
* Revenue that arrives from off-chain operations.
* Unsupported fee sources.
* Campaign budgets.
### Funding by Claiming Fees
Funding by claiming fees is best when a PDA fee vault is integrated with a supported Meteora product action.
Use this path for:
* Supported DAMM v2 fee or reward claims.
* Supported DBC fee, surplus, or migration-fee claims.
* Product-native revenue sharing where the fee vault should receive claimable fees directly.
Because a fee vault supports a single token mint and a single token vault, the source pool's `CollectFeeMode` must collect fees only in the fee vault's token mint: `OnlyB` or `Compounding` for DAMM v2 and `QuoteToken` for DBC.
See [Compatibilities](/helper-products/dynamic-fee-sharing/compatibilities) for the exact whitelisted actions and signer requirements.
## Communicate the Vault Clearly
Before recipients rely on a fee vault, share the key details:
```text theme={"system"}
Fee vault address:
Token mint:
Vault type: Non-PDA / PDA
Base account, if PDA:
Recipient list:
Recipient shares:
Funding method: Manual / supported claim action
Recipient index for each recipient:
Expected funding cadence:
```
For public or partner-facing setups, a simple table of recipients and shares is usually enough.
If funding amounts are very small relative to total shares, tell recipients to claim only when their displayed claimable amount is greater than zero. The program advances a recipient checkpoint even when the rounded claim amount is zero.
## Avoid Common Mistakes
A fee vault is tied to one token mint. Create separate vaults for separate fee tokens.
Recipient addresses are fixed. Prefer durable wallets such as treasuries or multisigs for long-lived revenue streams.
The program does not reject duplicate recipient addresses. Check the recipient list before initialization so dashboards, claims, and expectations are clear.
Dynamic Fee Sharing supports up to 5 recipients. If your payout design needs a large recipient set, use a different distribution approach.
The program supports a limited set of Token 2022 extensions. Check compatibility before creating the vault.
Claim-by-integration funding only works for whitelisted actions. Other revenue can still use manual funding.
A fee vault tracks a single token mint and a single token vault. Keep the source pool on the default quote-token-only `CollectFeeMode` (`OnlyB` for DAMM v2, `QuoteToken` for DBC) so all claimed fees arrive in the fee vault's token mint. Fees collected in a second token are not tracked by the fee vault.
The fee vault stores an `owner` field, but the current instructions do not use it for editing recipients, changing shares, withdrawing funds, or closing the vault.
## Recommended Designs
| Scenario | Recommended Design |
| ----------------------------- | ------------------------------------------------------------------------------ |
| Simple partner split | Non-PDA vault, 2 recipients, manual funding. |
| Creator and launchpad revenue | PDA vault if integrated with DBC, otherwise Non-PDA vault with manual funding. |
| DAMM v2 fee sharing | PDA vault tied to the relevant base account and token mint. |
| Reward token sharing | Separate vault for the reward token mint. |
## Pre-Launch Checklist
Before creating a fee vault, confirm:
* The token mint is correct.
* The token standard is supported.
* There are 2 to 5 recipients.
* Every recipient wallet is correct.
* Recipient addresses are unique unless duplicates are intentional.
* Every share is non-zero.
* The share split matches the agreement.
* The vault type matches the funding method.
* The `base` account can sign initialization if this is a PDA vault.
* A configured share-holder can sign claim-by-integration funding if needed.
* Recipients know how and when to claim.
Once those are true, the vault can become the on-chain source of truth for that fee split.
# Dynamic Fee Sharing Formulas
Source: https://docs.meteora.ag/helper-products/dynamic-fee-sharing/formulas
Understand Dynamic Fee Sharing share math, fixed-point fee-per-share accounting, claimable amounts, rounding, and transfer-fee behavior.
Dynamic Fee Sharing uses cumulative share accounting. Funding increases the value of each share, and each recipient stores a checkpoint for the share value they have already claimed.
The program performs integer arithmetic. This page shows the same formulas in product terms, with the important units and rounding behavior called out.
## Units
| Value | Program Unit |
| ----------------- | ------------------------------------------------------------------- |
| `share` | `u32` relative weight for one user entry. Must be greater than `0`. |
| `total_share` | `u32` sum of all configured shares. |
| `funded_amount` | `u64` amount added to vault accounting. |
| `fee_per_share` | `u128` cumulative Q64.64-style value. |
| `PRECISION_SCALE` | `64`, meaning calculations scale by `2^64`. |
| `fee_claimed` | `u64` gross amount claimed by one user entry. |
## Total Shares
The vault adds all recipient shares together.
```math theme={"system"}
\text{Total Share} = \sum_i \text{Recipient Share}_i
```
Each recipient's expected proportion is:
```math theme={"system"}
\text{Recipient Proportion} = \frac{\text{Recipient Share}}{\text{Total Share}}
```
Example:
| Recipient | Share | Percentage |
| --------- | ----- | ---------- |
| Creator | 50 | 50% |
| Partner | 30 | 30% |
| Treasury | 20 | 20% |
The total share is 100, so the shares map directly to percentages. The same split could also be represented as 5, 3, and 2 shares.
## Manual Funding Amount
Manual funding takes `max_amount`, but the program never transfers more than the source token account currently holds:
```math theme={"system"}
\text{Transfer Amount} =
\min(\text{max\_amount}, \text{source token account balance})
```
If `Transfer Amount = 0`, the instruction fails.
For standard SPL Token mints, the funded amount is the transfer amount:
```math theme={"system"}
\text{Funded Amount} = \text{Transfer Amount}
```
For supported Token 2022 transfer-fee mints, the program calculates the transfer fee for the current epoch and accounts for the amount excluding that fee:
```math theme={"system"}
\text{Funded Amount} =
\text{Transfer Amount} - \text{Transfer Fee}
```
This prevents funding accounting from crediting more tokens than the token vault receives.
## Claim-By-Integration Funding
When a PDA vault funds itself through `fund_by_claiming_fee`, the program measures the token vault balance before and after the whitelisted CPI.
```math theme={"system"}
\text{Claimed Amount} =
\text{Token Vault Balance After} - \text{Token Vault Balance Before}
```
If `Claimed Amount > 0`, the vault adds that amount to fee accounting:
```math theme={"system"}
\text{Funded Amount} = \text{Claimed Amount}
```
If the balance does not increase, the program does not update fee accounting or emit a fund event.
## Fee Per Share
Each time new fees enter the vault, the vault increases the cumulative fee-per-share value.
Conceptually:
```math theme={"system"}
\text{Fee Per Share Increase} = \frac{\text{Funded Amount}}{\text{Total Share}}
```
In the program:
```math theme={"system"}
\text{Fee Per Share Increase} =
\left\lfloor
\frac{\text{Funded Amount} \times 2^{64}}{\text{Total Share}}
\right\rfloor
```
Then it updates the cumulative value:
```math theme={"system"}
\text{New Fee Per Share} =
\text{Previous Fee Per Share} + \text{Fee Per Share Increase}
```
The vault also increases `total_funded_fee`:
```math theme={"system"}
\text{Total Funded Fee}_{new} =
\text{Total Funded Fee}_{old} + \text{Funded Amount}
```
## Claimable Fee
Each recipient stores a checkpoint: the fee-per-share value they had already claimed up to.
When the recipient claims, the vault calculates the difference between the current fee-per-share and that recipient's checkpoint.
```math theme={"system"}
\text{Unclaimed Fee Per Share} =
\text{Current Fee Per Share} - \text{Recipient Checkpoint}
```
Then the vault multiplies that delta by the recipient's share:
```math theme={"system"}
\text{Claimable Fee} =
\left\lfloor
\frac{\text{Recipient Share} \times \text{Unclaimed Fee Per Share}}{2^{64}}
\right\rfloor
```
After the claim, the recipient's checkpoint and total claimed amount are updated:
```math theme={"system"}
\text{Recipient Checkpoint} = \text{Current Fee Per Share}
```
```math theme={"system"}
\text{Fee Claimed}_{new} =
\text{Fee Claimed}_{old} + \text{Claimable Fee}
```
This is how the vault prevents double-claiming while still allowing recipients to claim independently.
The checkpoint updates even when `Claimable Fee` rounds down to `0`. For very small funding amounts or very large total-share values, claiming too early can round the user's current entitlement to zero and advance their checkpoint.
## Worked Example
Assume a vault has three recipients:
| Recipient | Share |
| --------- | ----- |
| Creator | 50 |
| Partner | 30 |
| Treasury | 20 |
Total share:
```math theme={"system"}
50 + 30 + 20 = 100
```
A funder adds 1,000 USDC into the vault.
The expected distribution is:
```math theme={"system"}
\text{Creator} =
1{,}000 \times \frac{50}{100} = 500
```
```math theme={"system"}
\text{Partner} =
1{,}000 \times \frac{30}{100} = 300
```
```math theme={"system"}
\text{Treasury} =
1{,}000 \times \frac{20}{100} = 200
```
If the creator claims first, the creator receives 500 USDC and the creator's checkpoint updates. The partner and treasury can claim later; their balances remain claimable because their checkpoints have not moved.
## Multiple Funding Events
Dynamic Fee Sharing supports repeated funding.
Example:
| Event | Net Funded Amount |
| --------- | ----------------- |
| Funding 1 | 1,000 USDC |
| Funding 2 | 500 USDC |
| Funding 3 | 250 USDC |
Total funded fee:
```math theme={"system"}
\text{Total Funded Fee} = 1,000 + 500 + 250 = 1,750
```
A 30% recipient would be entitled to:
```math theme={"system"}
1{,}750 \times 30\% = 525 \text{ USDC}
```
If that recipient already claimed 300 USDC after the first funding event, the next claim would be around 225 USDC, subject to integer rounding.
## Remaining Vault Balance
For standard SPL Token mints, the token vault balance usually represents funded fees that have not yet been claimed, plus small rounding dust.
Simplified formula:
```math theme={"system"}
\text{Remaining Vault Balance} =
\text{Total Funded Fee} - \sum_i \text{Total Claimed By Recipient}_i
```
Because token amounts are integers and `fee_per_share` increments are floored, small dust can remain when funded amounts do not divide evenly across shares.
## Transfer-Fee Token Claims
For supported Token 2022 transfer-fee mints, manual funding credits the net amount received by the token vault. Claims are different: the program calculates a gross `Claimable Fee` and transfers that amount from the token vault to the recipient token account. If the mint charges a transfer fee on that outgoing transfer, the recipient token account may receive less than the gross claimed amount.
```math theme={"system"}
\text{Net Received By Recipient} =
\text{Claimable Fee} - \text{Outgoing Transfer Fee}
```
The program's `fee_claimed` field tracks the gross claimed amount.
## Rounding and Precision
The program uses high-precision fee-per-share accounting by scaling calculations with `2^64`. This helps preserve precision for small funding amounts and large total-share values. The program includes a property test that checks small funded amounts still produce a non-zero `fee_per_share` even when `total_share` is `u32::MAX`.
Even with high precision, final claim amounts are integer token amounts. If a funded amount cannot be split perfectly between recipients, dust can remain in the vault.
For product planning, choose share weights that are easy to communicate. Percent-style totals such as 100, 1,000, or 10,000 are usually easier for teams and recipients to reason about.
# What is Dynamic Fee Sharing?
Source: https://docs.meteora.ag/helper-products/dynamic-fee-sharing/what-is-dynamic-fee-sharing
Learn how Meteora Dynamic Fee Sharing lets teams fund a token vault and split claimable fees across a small fixed recipient set.
## Overview
Dynamic Fee Sharing is Meteora's on-chain fee distribution program. It lets a team create a fee vault for one token mint, configure a fixed list of recipients and shares, fund the vault, and let each recipient claim their share directly on-chain.
It is a distribution layer for splitting funded token balances across **2 to 5** configured recipient entries.
Dynamic Fee Sharing runs on the mainnet program `dfsdo2UqvwfN8DuUVrMRNfQe11VaiNoKcMqLHVvDPzh`.
## Why Dynamic Fee Sharing Exists
Many on-chain fee streams need to be split between a small group: creators, launchpads, protocol treasuries, strategy operators, partners, or contributors. Without a dedicated vault, teams often collect fees into one wallet and reconcile payouts manually.
Dynamic Fee Sharing moves that split into program state:
* The recipient addresses and share weights are stored in the fee vault.
* Fees are added to a program-controlled token vault.
* Each funding event increases cumulative `fee_per_share` accounting.
* Each recipient claims by index, and the program tracks that recipient's checkpoint.
## Core Features
A vault stores 2 to 5 recipient entries, each with a wallet address, share amount, and claim checkpoint.
Recipients claim independently by signing with the wallet configured at their recipient index.
Vaults can be funded manually. PDA vaults can also fund through whitelisted DAMM v2 and Dynamic Bonding Curve claim actions.
Vaults support standard SPL Token mints and Token 2022 mints that only use supported extensions.
## How Dynamic Fee Sharing Works
The program has three main concepts.
| Component | What It Stores |
| ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| Fee vault | Owner field, token mint, token vault, vault type, base account, total shares, total funded fees, cumulative fee per share, and up to 5 user entries. |
| Token vault | The program-controlled token account that holds funded tokens before claims. |
| User entry | A recipient address, share amount, total fee claimed, and fee-per-share checkpoint. |
A vault lifecycle is short:
```text theme={"system"}
Initialize a fee vault for one token mint
|
Store 2-5 user entries and non-zero shares
|
Fund the token vault manually or through a supported claim action
|
Recipients claim by index with their configured wallet
```
## Fee Vault Types
Dynamic Fee Sharing supports two fee vault types. Both use the same share and claim accounting after initialization.
| Vault Type | How It Is Used |
| ----------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| Non-PDA fee vault | A standalone vault initialized from an externally generated signer account. Best for manual funding. |
| PDA fee vault | A deterministic vault derived from `["fee_vault", base, token_mint]`. Required for whitelisted claim-by-integration funding. |
## Important Constraints
| Constraint | Program Behavior |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| Recipient entries | Minimum `2`, maximum `5`. |
| Shares | Each share must be greater than `0`. |
| Recipient addresses | Each address must be non-default. The program does not reject duplicate addresses. |
| Token mint | One token mint per vault. |
| Updates | The current program exposes no general instruction to edit recipients, edit shares, withdraw admin funds, or close a vault. |
| Owner field | `owner` is stored and emitted, but current instructions do not use it as an admin authority. |
| Claim authorization | A claim succeeds only when the signer matches the user entry at the provided index. |
Treat the initialized recipient list and shares as permanent for that fee vault. If a split changes, create a new vault for the new arrangement.
## What To Read Next
Choose the recipient set, shares, token mint, vault type, and funding path before initialization.
Review token support, vault types, source programs, and whitelisted claim actions.
Understand fee-per-share accounting, fixed-point precision, rounding, and Token 2022 transfer-fee behavior.
## Who Dynamic Fee Sharing Is For
Protocol teams can route revenue into a fee vault and distribute it to contributors, treasuries, integrations, or strategic partners without manual payout operations.
Launchpads and creators can use Dynamic Fee Sharing to split eligible launch revenue between creator, partner, protocol, or campaign wallets.
Partners can receive their share directly from a vault instead of waiting for a centralized operator to reconcile and send payouts.
Integrators can track funded fees, claim events, recipient allocations, and vault balances as a clear on-chain revenue stream.
## What Dynamic Fee Sharing Is Best For
Dynamic Fee Sharing is best when a single supported token needs to be split between a small, known, stable recipient set.
Good use cases include:
* Creator and launchpad fee sharing.
* Treasury-funded partner splits.
* DAMM v2 fee or reward sharing through supported claim actions.
* Dynamic Bonding Curve creator, partner, trading-fee, or migration-fee sharing through supported claim actions.
* Campaign or contributor revenue splits where the recipient set is fixed.
# Presale Vault Access and States
Source: https://docs.meteora.ag/helper-products/presale-vault/access-and-states
Review Presale Vault accounts, access models, escrow creation paths, operator permissions, Merkle roots, lifecycle gates, and close conditions.
Presale Vault uses a small set of program accounts to separate sale configuration, participant state, allowlist data, and token custody. This page is a program-level map for integrators who need to understand which account owns which responsibility.
## Core Accounts
| Account | What It Stores |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `Presale` | Sale owner, base mint, quote mint, token vaults, mode, whitelist mode, caps, timing, vesting, total deposits, fees, claim totals, token program flags, registries, and one-time lifecycle flags. |
| `PresaleRegistry` | Per-registry supply, total deposits, escrow count, claimed and refunded totals, buyer deposit range, and deposit fee bps. Registries are stored inside the `Presale` account. |
| `Escrow` | A buyer's position: owner, registry index, net deposit, deposit fee, personal cap, pending claim amount, claimed amount, remaining-quote withdrawal flag, and timestamps. |
| `FixedPricePresaleExtraArgs` | Fixed Price extra params: `q_price`, owner, presale, and whether buyer withdrawals are disabled. |
| `Operator` | Permissioned authority mapping between a creator and an operator owner. |
| `MerkleRootConfig` | Merkle root, presale, and version for permissioned Merkle-proof escrows. |
| `PermissionedServerMetadata` | Optional server URL for retrieving Merkle proofs or authority-mode transaction data off-chain. |
The base-token and quote-token vaults are token accounts controlled by the program's presale authority PDA. The program checks that vault and mint accounts match the `Presale` state before moving tokens.
## Access Models
Presale Vault supports three whitelist modes.
### Permissionless
Permissionless sales let anyone create an escrow while the sale is ongoing. The escrow uses the default registry index `0`, and the escrow's personal cap defaults to the registry's buyer maximum.
### Permission with Authority
Authority-mode sales require an `Operator` account. The operator owner signs escrow creation, and the operator must belong to the presale creator. The escrow creation instruction assigns:
* buyer wallet
* registry index
* personal deposit cap
Operator accounts are scoped by creator and operator owner, not by a single presale. The creator can revoke an operator account, which closes it back to the creator.
### Permission with Merkle Proof
Merkle-mode sales require a `MerkleRootConfig`. The buyer provides a proof for a leaf containing:
* buyer wallet
* registry index
* personal deposit cap
The Merkle root config is created by the presale owner while the sale is not started or ongoing, and only for presales using the Merkle whitelist mode. Root configs are versioned, so a creator can publish a new version if the allowlist data changes.
The program validates the proof and cap data on-chain, but it does not prevent the same wallet from appearing in multiple registries. Creators and launchpads should prevent unintended duplicate eligibility off-chain.
## Permissioned Server Metadata
For permissioned sales, the creator can publish an optional `PermissionedServerMetadata` account with a server URL. The URL can point users to Merkle proofs or authority-mode transaction data.
This account is only allowed for permissioned whitelist modes and can be created while the sale is not started or ongoing. The creator can close it in any sale state.
## Lifecycle Gates
| Action | Gate |
| -------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| Initialize presale | Params, token support, registries, mode-specific rules, and base-token funding must validate. |
| Create escrow | Sale must be ongoing. Whitelist mode and registry index must match the selected creation path. |
| Deposit | Sale must be ongoing. Deposit is capped by the mode, registry, personal cap, and fixed-price supply where applicable. |
| Withdraw during sale | Sale must be ongoing. Pro Rata allows withdrawals, FCFS disallows them, and Fixed Price depends on `disable_withdraw`. |
| Claim | Sale must be completed. The claim amount is cumulative and subtracts already claimed and pending amounts. |
| Withdraw remaining quote | Allowed after failed sales, or after completed Pro Rata sales for overflow quote. Each escrow can do this once. |
| Creator withdraw | Allowed after completed or failed sales. The creator can withdraw once. |
| Collect deposit fee | Allowed only after completed sales, and only once. |
| Perform unsold base-token action | Allowed only after completed sales, only if unsold base tokens exist, and only once. |
## Creator Settlement
After a completed sale, the creator can withdraw raised quote token once. The withdrawal is capped by the sale's maximum cap, which is especially important for oversubscribed Pro Rata sales.
After a failed sale, the creator can withdraw the base-token supply instead.
Deposit fees are collected separately. In Fixed Price and FCFS, the creator can collect total deposit fees after completion. In Pro Rata, the collectible fee excludes the fee attributed to overflow quote that buyers can refund. See [Presale Vault Formulas](/helper-products/presale-vault/formulas) for the exact withdrawal and fee formulas.
## Close Conditions
Escrow accounts can only be closed once they have no remaining economic claim:
* during an ongoing sale, the escrow must have zero deposit and zero deposit fee
* after a failed sale, the escrow must have withdrawn remaining quote, unless it has zero deposit and zero fee
* after a completed sale, refundable quote must be withdrawn when applicable, and all tokens claimable through the vesting end must be claimed
Merkle root configs can be closed by the creator when the presale is not ongoing. Fixed-price extra params can be closed by their owner. Permissioned server metadata can be closed by the presale owner in any sale state.
# Presale Vault Configuration Guide
Source: https://docs.meteora.ag/helper-products/presale-vault/configuration-guide
The main decisions and constraints to check before creating a Presale Vault.
Use this guide before creating a vault. It focuses on configuration choices that are enforced by the program, plus the product decisions that should be communicated to buyers.
# 1. Choose the sale mode
## Fixed Price
Use Fixed Price when buyers need a known price before depositing.
You must also create fixed-price extra params with:
* `q_price` in Q64.64 format
* `disable_withdraw` as true or false
Fixed Price is sensitive to integer rounding. Make sure the chosen price, cap, and supply can produce the intended sale outcome in smallest token units.
## FCFS
Use FCFS when deposits should stop at the maximum cap and buyers should be committed once they deposit.
If early completion is enabled, reaching the maximum cap moves the sale end time to the current timestamp. This also recalculates vesting times from the new end time.
## Pro Rata
Use Pro Rata when the sale may be oversubscribed and buyers should receive proportional allocation with proportional overflow refunds.
Pro Rata deposits can exceed the maximum cap, so buyer caps and allowlist design matter more.
# 2. Pick supported tokens
The base and quote mints can be standard SPL Token mints or supported Token-2022 mints. If either mint uses Token-2022 extensions, review [Token 2022 Support](/helper-products/presale-vault/token-2022-support) before launch so the UI and transaction builder handle transfer fees, transfer hooks, and memo requirements correctly.
# 3. Set sale timing
| Timing setting | Requirement |
| -------------- | ------------------------------------------------ |
| Start time | cannot be more than 30 days after initialization |
| End time | must be after the effective start time |
| Sale duration | 60 seconds to 30 days |
The effective start time is the later of the requested start time and the current timestamp.
# 4. Set raise caps
The minimum cap must be greater than zero, and the maximum cap must be at least the minimum cap.
For Fixed Price, the program also checks that:
* the maximum cap can be fulfilled by the configured base supply
* the minimum and maximum caps correspond to different bought base-token amounts
# 5. Design registries
A vault must have 1 to 5 registries. Each registry has:
* base-token supply
* buyer minimum deposit cap
* buyer maximum deposit cap
* deposit fee bps
Registry supply must be greater than zero, and the sum of registry supplies must fit in `u64`.
Registry deposit fee cannot exceed 5,000 bps.
## Permissionless registries
Permissionless mode uses registry index `0`. Buyers create their own escrow in that registry.
## Permissioned registries
Multiple registries require a permissioned mode.
For permissioned sales, the program uses the escrow's personal deposit cap to control each buyer. The registry-level cap range has mode-specific constraints:
| Mode | Permissioned registry cap constraint |
| ----------- | ------------------------------------------------------------------------------------------------------------------ |
| Fixed Price | minimum must equal the quote amount needed to buy at least one base unit; maximum must equal `presale_maximum_cap` |
| FCFS | minimum must be `1`; maximum must equal `presale_maximum_cap` |
| Pro Rata | minimum must be `1`; maximum must equal `presale_maximum_cap` |
The personal cap supplied during escrow creation must be within the registry range.
# 6. Choose the whitelist mode
Choose the whitelist mode based on who should be able to create buyer escrows:
| Whitelist mode | Use when |
| ---------------------------- | ------------------------------------------------------------------------------------------------- |
| Permissionless | Anyone should be able to participate through the default registry. |
| Permission with authority | A creator-approved operator should assign buyer escrows, registries, and personal caps. |
| Permission with Merkle proof | Buyers should prove allowlist eligibility on-chain using wallet, registry, and personal cap data. |
See [Access and States](/helper-products/presale-vault/access-and-states) for the escrow creation paths, operator rules, Merkle root accounts, and close conditions.
# 7. Configure deposit fees
Deposit fees are set per registry in bps and charged on top of the net deposit used for allocation.
The program rounds the gross amount up so the requested net deposit is preserved:
```math theme={"system"}
\text{gross} =
\left\lceil
\frac{\text{net\_deposit} \times 10{,}000}
{10{,}000 - \text{fee\_bps}}
\right\rceil
```
In Pro Rata, fee on overflow quote is refundable and is excluded from the creator's collectible fee.
# 8. Configure unlocks
If no lock and vesting params are provided, sold tokens are claimable after the sale completes with no additional lock or drip schedule.
If lock and vesting params are provided:
* immediate release bps must be at most 10,000
* lock duration plus vest duration must be less than 10 years
* if immediate release is 10,000 bps, lock and vest duration must both be zero
* if immediate release is below 10,000 bps, at least one of lock duration or vest duration must be greater than zero
* if immediate release timestamp is set and immediate release bps is greater than zero, it must be between the sale end and vesting end
* if immediate release bps is zero and immediate release timestamp is set, it must equal the sale end
When early completion changes the sale end time, vesting start and end are recalculated from the new end time. The immediate release timestamp preserves its offset from the previous end time.
# 9. Choose unsold base-token action
The unsold action is either:
* **Refund**: return unsold base tokens to the creator
* **Burn**: burn unsold base tokens from the vault
The action is only available after a completed sale, only if there are unsold tokens, and only once.
# 10. Pre-launch checklist
* Base and quote mints use supported token programs and extensions.
* Sale start, end, and duration satisfy the program limits.
* Minimum and maximum caps are intentional and valid.
* Fixed-price `q_price` has been tested in smallest units, if using Fixed Price.
* Registry count, supplies, fee bps, and cap ranges are valid for the selected whitelist mode.
* Permissioned allowlist data includes wallet, registry index, and personal cap.
* Token-2022 transfer hook accounts can be provided where needed.
* Buyer-facing docs explain whether deposits can be withdrawn during the sale.
* Buyer-facing docs explain claim timing and vesting.
* The team has a post-sale plan for creator withdrawal, fee collection, unsold tokens, and liquidity.
# Presale Vault Formulas
Source: https://docs.meteora.ag/helper-products/presale-vault/formulas
The main Presale Vault formulas for fixed-price sales, dynamic allocation, fees, refunds, and vesting.
Presale Vault performs calculations in smallest token units. Display decimals are a UI concern; on-chain math uses integer arithmetic, checked overflow handling, and deterministic rounding.
# Constants
```math theme={"system"}
\text{BPS\_DENOMINATOR} = 10{,}000
```
```math theme={"system"}
\text{Q64\_SCALE} = 2^{64}
```
Deposit fee bps are capped at `5,000`. Immediate release bps are capped at `10,000`.
# Sale success
A sale is completed when the current timestamp is at or after `presale_end_time` and total net deposits meet the minimum cap:
```math theme={"system"}
\text{completed} = \text{total\_deposit} \ge \text{presale\_minimum\_cap}
```
If total deposits are below the minimum cap after the sale ends, the sale is failed.
# Deposit fee
The deposit amount tracked for allocation excludes the deposit fee. If a buyer deposits a net amount `D` into a registry with fee rate `f` bps, the gross amount required before Token-2022 transfer fees is rounded up:
```math theme={"system"}
\text{gross} =
\left\lceil
\frac{D \times 10{,}000}{10{,}000 - f}
\right\rceil
```
```math theme={"system"}
\text{deposit\_fee} = \text{gross} - D
```
The fee is tracked separately on the escrow, registry, and presale. In Pro Rata, the fee attributable to refunded overflow quote is refundable.
# Fixed Price
Fixed Price mode stores `q_price` as a Q64.64 value:
```math theme={"system"}
\text{q\_price} = \text{quote smallest units per base smallest unit} \times 2^{64}
```
For a net quote deposit `D`, bought base units are rounded down:
```math theme={"system"}
\text{base\_bought} =
\left\lfloor
\frac{D \times 2^{64}}{\text{q\_price}}
\right\rfloor
```
When the program needs the quote amount for a base amount, quote is rounded up:
```math theme={"system"}
\text{quote\_needed} =
\left\lceil
\frac{\text{base\_amount} \times \text{q\_price}}{2^{64}}
\right\rceil
```
For each registry, total sold base token is capped by registry supply:
```math theme={"system"}
\text{registry\_sold} =
\min(\text{base\_bought\_from\_registry\_deposits},\ \text{registry\_supply})
```
The buyer's cumulative claimable amount is then based on their share of `registry_sold`, after applying the unlock schedule.
# FCFS allocation
For FCFS, each registry with at least one deposit sells its full registry supply. A buyer's cumulative allocation before vesting is:
```math theme={"system"}
\text{user\_allocation} =
\left\lfloor
\frac{\text{registry\_supply} \times \text{user\_deposit}}
{\text{registry\_total\_deposit}}
\right\rfloor
```
Registries with zero deposits sell zero base token, so their supply is unsold.
# Pro Rata allocation and overflow
Pro Rata uses the same registry-level allocation formula as FCFS:
```math theme={"system"}
\text{user\_allocation} =
\left\lfloor
\frac{\text{registry\_supply} \times \text{user\_deposit}}
{\text{registry\_total\_deposit}}
\right\rfloor
```
Overflow quote is calculated at the presale level:
```math theme={"system"}
\text{remaining\_quote} =
\max(\text{total\_deposit} - \text{presale\_maximum\_cap},\ 0)
```
Each registry receives a share of that remaining quote:
```math theme={"system"}
\text{registry\_remaining\_quote} =
\left\lfloor
\frac{\text{remaining\_quote} \times \text{registry\_total\_deposit}}
{\text{presale\_total\_deposit}}
\right\rfloor
```
Each buyer receives a share of the registry refund:
```math theme={"system"}
\text{user\_refund} =
\left\lfloor
\frac{\text{registry\_remaining\_quote} \times \text{user\_deposit}}
{\text{registry\_total\_deposit}}
\right\rfloor
```
Refundable deposit fee for Pro Rata overflow is calculated proportionally from the registry's collected fee:
```math theme={"system"}
\text{registry\_refund\_fee} =
\left\lfloor
\frac{\text{registry\_total\_fee} \times \text{registry\_remaining\_quote}}
{\text{registry\_total\_deposit}}
\right\rfloor
```
```math theme={"system"}
\text{user\_refund\_fee} =
\left\lfloor
\frac{\text{user\_total\_fee} \times \text{registry\_refund\_fee}}
{\text{registry\_total\_fee}}
\right\rfloor
```
# Failed sale refund
If the sale fails, each buyer can withdraw their full remaining net deposit and deposit fee:
```math theme={"system"}
\text{failed\_sale\_refund} = \text{user\_deposit} + \text{user\_deposit\_fee}
```
The creator can withdraw the base-token supply from a failed sale.
# Creator withdrawal
After a successful sale, the creator can withdraw quote token once:
```math theme={"system"}
\text{creator\_quote\_withdrawal} =
\min(\text{total\_deposit},\ \text{presale\_maximum\_cap})
```
Deposit fees are collected through a separate instruction after completion. For Fixed Price and FCFS, the collectible fee is total deposit fee. For Pro Rata, the collectible fee excludes refundable overflow fee.
# Unlock and vesting
First, split the sold allocation into immediate and vested portions:
```math theme={"system"}
\text{immediate\_amount} =
\left\lfloor
\frac{\text{total\_sold\_token} \times \text{immediate\_release\_bps}}
{10{,}000}
\right\rfloor
```
```math theme={"system"}
\text{vested\_amount} = \text{total\_sold\_token} - \text{immediate\_amount}
```
The immediate portion is included only once the current timestamp is at or after `immediate_release_timestamp`.
The vested portion starts at:
```math theme={"system"}
\text{vesting\_start\_time} = \text{presale\_end\_time} + \text{lock\_duration}
```
and ends at:
```math theme={"system"}
\text{vesting\_end\_time} = \text{vesting\_start\_time} + \text{vest\_duration}
```
If `vest_duration` is zero, the vested portion becomes claimable at `vesting_start_time`. Otherwise it unlocks linearly:
```math theme={"system"}
\text{dripped\_vested\_amount} =
\left\lfloor
\frac{\text{vested\_amount} \times \min(\text{elapsed\_seconds},\ \text{vest\_duration})}
{\text{vest\_duration}}
\right\rfloor
```
The user's cumulative claimable token is their deposit share of the released amounts:
```math theme={"system"}
\text{user\_claimable} =
\left\lfloor
\frac{(\text{released\_immediate} + \text{dripped\_vested\_amount}) \times \text{user\_deposit}}
{\text{registry\_total\_deposit}}
\right\rfloor
```
The next claim is cumulative claimable minus already claimed and pending claim amounts.
# Transfer fees
If the base or quote mint is a supported Token-2022 mint with Transfer Fee enabled, transfers may require additional amount on deposit and may deliver less than the transferred amount on withdrawal or claim. Presale Vault accounts for transfer-fee-inclusive and transfer-fee-exclusive amounts when moving tokens, but allocation math is based on the net deposit tracked by the program.
# Presale Vault Token 2022 Support
Source: https://docs.meteora.ag/helper-products/presale-vault/token-2022-support
See how Presale Vault supports SPL Token and supported Token-2022 mints, transfer fees, transfer hooks, memo transfer, and token integration constraints.
Presale Vault can use standard SPL Token mints or supported Token-2022 mints for both the base token being sold and the quote token buyers deposit.
Unlike DLMM, Presale Vault does not use a token-badge review path in this program. A Token-2022 mint must use only the extensions accepted by the presale program.
## Supported Mints
Presale Vault accepts:
* standard SPL Token mints
* Token-2022 mints with only supported mint extensions
The Token-2022 native mint is rejected.
## Supported Token-2022 Extensions
If a base or quote mint is Token-2022, the program currently accepts only these mint extensions:
* `TransferFeeConfig`
* `MetadataPointer`
* `TokenMetadata`
* `TransferHook`
Any other Token-2022 mint extension fails validation with `UnsupportedToken2022MintOrExtension`.
Transfer hooks are supported by passing the hook accounts required by the hook program. Presale Vault does not require the transfer hook program or authority to be revoked.
## Transfer Fees
Presale Vault accounts for Token-2022 transfer fees when moving tokens.
### Deposits
When a buyer deposits a quote token with transfer fees, the program calculates the transfer-fee-included amount needed for the intended net deposit and registry deposit fee. The escrow and presale state track the net deposit used for allocation, while the buyer may transfer more than the net amount because of Token-2022 transfer fees.
### Claims and withdrawals
When tokens move from the presale vault to a user, the transfer amount may be reduced by the token's transfer fee. Events report transfer-fee-excluded amounts where applicable.
This affects:
* buyer withdrawals during the sale
* failed-sale quote refunds
* Pro Rata overflow quote refunds
* base-token claims
* creator withdrawals
* deposit-fee collection
* unsold base-token refunds
### 100% transfer-fee edge case
If a Token-2022 mint has a 100% transfer fee, the program uses the mint's maximum fee when calculating the inverse transfer fee needed for deposits. If that addition overflows, the instruction fails.
## Transfer Hooks
If the base or quote mint has a Transfer Hook extension, instructions that transfer that token must pass the required remaining accounts for the hook program.
The program separates hook account slices by token side:
| Accounts type | Used for |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| `TransferHookBase` | Base-token transfers, such as initialization funding, claims, failed creator withdrawal, and unsold base-token refunds. |
| `TransferHookQuote` | Quote-token transfers, such as deposits, buyer quote withdrawals, Pro Rata refunds, creator quote withdrawal, and fee collection. |
If a transfer hook exists and the required accounts are missing, the instruction fails. If hook accounts are supplied for a mint without a transfer hook, the instruction also fails.
## Memo Transfer
`MemoTransfer` is an account-level Token-2022 extension, not a mint extension. Presale Vault checks destination token accounts when the program transfers tokens out of the vault.
If the destination account requires incoming transfer memos, the program builds a memo with:
```text theme={"system"}
Presale
```
This applies to transfers from the presale vault to users or creator-controlled accounts. User-to-vault transfers do not include a memo context.
## Initialization Funding
At initialization, the creator funds the base-token vault with the sum of all registry supplies. If the base mint has a transfer fee, the creator may need to transfer a transfer-fee-included amount so the vault receives the intended base supply.
The same transfer-hook rules apply if the base mint uses Transfer Hook.
## Integration Checklist
* Confirm both base and quote mints are either SPL Token mints or supported Token-2022 mints.
* Reject unsupported Token-2022 extensions before showing a launch flow.
* Include transfer hook remaining accounts for every instruction that transfers a hook-enabled mint.
* Display net deposit separately from registry deposit fee and Token-2022 transfer fee.
* Explain to buyers that transfer-fee tokens may deliver less on claims or refunds.
* Ensure destination token accounts can receive memo-bearing transfers when `MemoTransfer` is enabled.
# Presale Vault Modes
Source: https://docs.meteora.ag/helper-products/presale-vault/vault-modes
Compare the Fixed Price, FCFS, and Pro Rata modes supported by Presale Vault.
Presale Vault supports three sale modes. The mode controls deposit capacity, withdrawal support, token-allocation math, and when the sale can end.
# Comparison
| Mode | Price behavior | Deposit capacity | During-sale withdrawal | Token allocation |
| ----------- | -------------------------------------------------- | ----------------------------------------------------------------- | ---------------------- | ----------------------------------------------------------------------- |
| Fixed Price | Creator sets a Q64.64 quote-per-base price | Cannot exceed the global maximum cap or available registry supply | Configurable | Based on fixed price, then vested |
| FCFS | Final implied price depends on deposits and supply | Cannot exceed the global maximum cap | Disabled | Registry supply is split by deposit share |
| Pro Rata | Final implied price depends on deposits and supply | Can exceed the global maximum cap, subject to buyer caps | Enabled | Registry supply is split by deposit share; overflow quote is refundable |
# Fixed Price
Fixed Price mode is for sales where buyers should know the quote-per-base price before participating.
The creator creates a fixed-price extra-params account before initializing the vault. That account stores:
* `q_price`, a Q64.64 price in quote-token smallest units per base-token smallest unit
* `disable_withdraw`, which controls whether buyers can withdraw during the ongoing sale
The program verifies that the configured price can buy at least one base-token unit for the relevant buyer caps, that the maximum cap can be fulfilled by the deposited base supply, and that the minimum and maximum caps buy different base-token amounts.
## Deposit behavior
Fixed Price deposits are capped by:
* remaining global quote capacity
* remaining personal and registry deposit capacity
* remaining base-token supply in the buyer's registry
The program may reduce a requested deposit to the largest amount that maps cleanly to purchasable base-token units. Fixed-price token amounts are rounded down in base-token units, and quote needed for those units is rounded up.
## Claim behavior
The sold amount for a registry is:
```math theme={"system"}
\min\left(\left\lfloor \frac{\text{registry\_total\_deposit} \times 2^{64}}{\text{q\_price}} \right\rfloor,\ \text{registry\_supply}\right)
```
Each buyer's claimable amount is their share of that sold amount, subject to the unlock schedule.
# FCFS
FCFS mode is for capped sales where deposits should stop once the sale reaches the maximum cap.
Deposits are capped by:
* remaining global quote capacity
* remaining personal and registry deposit capacity
FCFS does not support during-sale withdrawals. If early completion is not disabled, the program updates the presale end time to the current timestamp once total deposits reach the maximum cap.
## Claim behavior
For each registry that received deposits, the full registry supply is sold and split by deposit share:
```math theme={"system"}
\text{user\_allocation} =
\left\lfloor
\frac{\text{registry\_supply} \times \text{user\_deposit}}
{\text{registry\_total\_deposit}}
\right\rfloor
```
A registry with no deposits is not treated as sold, so its supply is unsold base token.
# Pro Rata
Pro Rata mode is for sales where buyers should be able to participate throughout the sale window even if demand exceeds the maximum cap.
Deposits are not capped by the global maximum cap. They are still capped by the buyer's remaining deposit quota. Pro Rata supports during-sale withdrawals.
## Claim and refund behavior
Token allocation uses the same registry-level share formula as FCFS:
```math theme={"system"}
\text{user\_allocation} =
\left\lfloor
\frac{\text{registry\_supply} \times \text{user\_deposit}}
{\text{registry\_total\_deposit}}
\right\rfloor
```
If total deposits exceed the maximum cap, the excess quote token is refundable after the sale completes. The creator can withdraw only up to `presale_maximum_cap`; buyers withdraw the remaining quote token proportionally.
Deposit fees on the refunded portion are also refundable. The creator's collectible fee in Pro Rata is the total fee minus the fee attributed to overflow quote.
All three modes can be used with any whitelist mode. Registry and personal-cap constraints are covered in the [Configuration Guide](/helper-products/presale-vault/configuration-guide).
# Choosing a mode
Use when the sale needs an explicit price and predictable buyer communication.
Use when the sale should be hard-capped and deposits are meant to be committed.
Use when the sale may be oversubscribed and unused quote should be refunded fairly.
# What is Presale Vault?
Source: https://docs.meteora.ag/helper-products/presale-vault/what-is-presale-vault
Learn how Meteora's Presale Vault helps teams run standalone token presales with fixed-price, FCFS, and pro rata modes, permissioned access, registry buckets, refunds, fees, and vesting.
Presale Vault is still in beta and is subject to breaking changes.
Presale Vault is Meteora's on-chain infrastructure for teams that want to run a standalone token sale before market trading begins.
A creator deposits the token being sold into a program-owned base vault. Buyers deposit a quote token during the sale window. If the sale succeeds, buyers claim the sold token according to the selected sale mode and unlock schedule. If the sale fails, buyers can withdraw their deposited quote token and refundable fees.
Presale Vault runs on the mainnet program `presSVxnf9UU8jMxhgSMqaRwNiT36qeBdNeTRKjTdbj`.
## Why Presale Vault Exists
Pre-market token sales need more than a deposit address. Teams often need caps, allowlists, multiple participant tiers, predictable refund rules, vesting, and clean post-sale accounting before a token is listed on a live market.
Presale Vault brings those sale mechanics into one on-chain flow. A creator or launchpad can configure the sale terms up front, buyers participate through escrow accounts, and the program handles allocation, refunds, claims, fees, and unsold-token handling according to the configured mode.
Run a token sale before market trading begins, without requiring an AMM pool or automatic liquidity deployment.
Choose Fixed Price, FCFS, or Pro Rata depending on whether the sale needs a known price, capped urgency, or proportional allocation under oversubscription.
Use 1 to 5 registries to separate allocations, deposit fee bps, and buyer deposit ranges.
Support public participation, operator-created escrows, or Merkle-proof allowlists with per-buyer registry and cap data.
Track net deposits and deposit fees separately, including failed-sale refunds and Pro Rata overflow refunds.
Configure immediate release, lock duration, and linear vesting for tokens bought in a successful sale.
## How Presale Vault Works
A Presale Vault launch has two main phases.
During the **sale phase**, the creator initializes the vault, funds the base-token vault, and buyers create escrow accounts. Deposits are accepted only while the sale is ongoing. The selected mode controls whether deposits are capped at the maximum cap, whether buyers can withdraw during the sale, and how allocations are calculated.
During the **settlement phase**, the sale is either completed or failed. Completed sales allow buyer claims, creator quote withdrawal, deposit-fee collection, Pro Rata overflow refunds when applicable, and one-time unsold base-token handling. Failed sales allow buyers to withdraw their quote deposit and fee, while the creator can withdraw the unsold base supply.
| Stage | What Happens |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Initialize vault | The creator sets the mode, whitelist mode, caps, timing, registries, unlock schedule, and unsold-token action. The base vault is funded with the total registry supply. |
| Create escrows | Buyers need an escrow before depositing. Permissionless escrows use registry `0`; permissioned escrows include registry and personal cap data. |
| Deposit quote | Buyers deposit net quote token plus any registry deposit fee and Token-2022 transfer fee. The program records the net amount used for allocation. |
| Sale ends | The sale completes if total net deposits meet the minimum cap. Fixed Price and FCFS can end early at the maximum cap unless disabled. |
| Settle buyers | Completed sales allow claims. Failed sales allow full remaining quote and fee refunds. Completed Pro Rata sales allow proportional overflow quote and fee refunds. |
| Settle creator | The creator can withdraw raised quote after completion, withdraw base supply after failure, and collect non-refundable deposit fees after completion. |
| Handle unsold supply | After completion, unsold base token can be returned to the creator or burned once, depending on the configured action. |
## Product Building Blocks
Compare Fixed Price, FCFS, and Pro Rata behavior around deposit capacity, withdrawals, allocation, and refunds.
Review the main setup constraints around tokens, timing, caps, registries, access, fees, vesting, and unsold-token handling.
See supported Token-2022 extensions, transfer-fee behavior, transfer hooks, and memo-transfer handling.
Review state accounts, escrow creation paths, operator permissions, Merkle roots, lifecycle gates, and close conditions.
Understand the core formulas for Q64.64 fixed price, dynamic allocation, deposit fees, refunds, creator withdrawal, and vesting.
## Who Presale Vault Is For
Presale Vault is useful for launchpads that want repeatable presale infrastructure with configurable sale modes, permissioned access, registries, deposit fees, refunds, and vesting.
Creators can run a standalone fundraising round before listing, decide who can participate, define per-buyer limits, configure unlocks, and settle raised quote tokens after the sale.
Buyers get an escrow account that tracks their registry, net deposit, deposit fee, personal cap, pending claim amount, claimed tokens, and remaining-quote withdrawal status.
Wallets, launch interfaces, dashboards, and indexers can follow a clear lifecycle: vault initialization, escrow creation, deposits, completion or failure, claims, refunds, and creator settlement.
## Presale Vault vs Alpha Vault
Presale Vault and Alpha Vault both support early token access, but they solve different launch problems.
* **Presale Vault** runs a standalone token sale. Buyers deposit quote tokens into a presale vault and later claim the sold token. The creator withdraws raised quote tokens after a successful sale.
* **Alpha Vault** is paired with a launch pool. Users deposit into the vault so the vault can buy from that pool before public trading starts.
Use Presale Vault when the goal is a configurable fundraising round. Use Alpha Vault when the goal is first access to buy from a launch pool.
Presale Vault does not automatically create liquidity or list the token after the sale. Launch teams should plan creator withdrawal, fee collection, refunds, unsold-token handling, and any post-sale liquidity deployment before deposits open.
# Zap Compatibilities
Source: https://docs.meteora.ag/helper-products/zap/compatibilities
Review the instructions, routes, tokens, accounts, permissions, and constraints supported by Zap.
Zap has a fixed compatibility surface in the on-chain program. Use this page to check whether a user flow maps to one of Zap's supported instructions.
## Instruction Surface
| Instruction | Purpose | Main constraint |
| ---------------------------------------- | ------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| `initialize_ledger_account` | Create the user ledger PDA. | `owner` and `payer` sign. |
| `set_ledger_balance` | Write token A/B or token X/Y amount into the ledger. | Ledger owner signs. |
| `update_ledger_balance_after_swap` | Record a post-swap balance delta, capped by `max_transfer_amount`. | Ledger owner signs. |
| `close_ledger_account` | Close the ledger and send rent to `rent_receiver`. | Ledger owner and rent receiver sign. |
| `zap_in_damm_v2` | Add DAMM v2 liquidity, optionally swap surplus through DAMM v2, then add again. | Existing DAMM v2 position; owner signs. |
| `zap_in_dlmm_for_uninitialized_position` | Initialize a new DLMM position and add liquidity through `rebalance_liquidity`. | Position account must be empty and sign. |
| `zap_in_dlmm_for_initialized_position` | Add liquidity to an existing DLMM position through `rebalance_liquidity`. | Ledger owner signs. |
| `zap_out` | Swap a percentage of a detected token balance increase. | Route must be whitelisted by program and discriminator; swap authority comes from the supplied route accounts. |
## Compatibility Matrix
| Area | Supported | Important constraint |
| ------------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| Program ID | `zapvX9M3uf5pvy4wRPAbQgdQsM1xmuiFnkfHKPvwMiz` | Same declared ID in the program. |
| DAMM v2 Zap In | Yes | Swaps only through DAMM v2 `swap2` inside the Zap In flow. |
| DLMM Zap In | Yes | Adds through DLMM `rebalance_liquidity`; Zap does not withdraw or claim in this instruction. |
| DLMM strategies | `Spot`, `Curve`, `BidAsk` | `min_delta_id <= max_delta_id`. |
| Zap Out routes | DAMM v2 swap, DLMM `swap2`, Jupiter v6 route, Jupiter v6 shared-account route | Route is checked by program ID plus 8-byte instruction discriminator. |
| Zap Out percentage | `1` to `100` | Values outside this range fail. |
| Ledger | User-owned PDA | Seeds are `["user_ledger", owner]`; ledger instructions require owner signature. |
| Token transfer fees | Partially supported | Zap In math uses transfer-fee-excluded amounts where it calculates liquidity or strategy amounts. |
## Whitelisted Zap Out Routes
Zap Out only invokes a swap if the supplied `amm_program` and the first 8 bytes of `payload_data` match one of the whitelisted pairs:
| Route | Program-level check |
| ------------------------------- | ----------------------------------------------------------- |
| DAMM v2 swap | DAMM v2 program plus DAMM v2 swap discriminator. |
| DLMM swap | DLMM program plus `swap2` discriminator. |
| Jupiter v6 route | Jupiter v6 program plus route discriminator. |
| Jupiter v6 shared-account route | Jupiter v6 program plus shared-account route discriminator. |
Unsupported Jupiter instruction variants, custom routers, or arbitrary AMM instructions are rejected with `AmmIsNotSupported`.
## Access Controls and Accounts
| Action | Required authority |
| -------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| Initialize ledger | `owner` signer and `payer` signer. |
| Set ledger balance | Ledger `owner` signer. |
| Update ledger balance after swap | Ledger `owner` signer. |
| Close ledger | Ledger `owner` signer and `rent_receiver` signer. |
| DAMM v2 Zap In | Ledger `owner` signer, also used as DAMM v2 position owner. |
| DLMM Zap In | Ledger `owner` signer, plus `rent_payer` signer. |
| Zap Out | No owner signer is enforced by Zap itself; the invoked swap route must receive whatever signers/accounts it requires. |
The ledger account has `has_one = owner` checks on mutable instructions. For uninitialized DLMM positions, the `position` account must be a signer, must be empty, and must not equal the owner or rent payer. Zap Out does not verify the token account owner; integrators should build the surrounding transaction so the route authority and token accounts are the intended user accounts.
## Flow Constraints
| Flow | Constraint |
| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| DAMM v2 Zap In | Zap calls DAMM v2 `add_liquidity` with `token_a_amount_threshold` and `token_b_amount_threshold` set to `u64::MAX`; price protection comes from `max_sqrt_price_change_bps` around the optional balancing swap. |
| DAMM v2 Zap In | If the surplus-side swap calculation fails or returns zero input/output, Zap returns successfully after the first add-liquidity attempt and leaves remaining amounts in the ledger. |
| DLMM Zap In | Strategy parameters are generated from the pair's on-chain active bin at execution. The caller-supplied `active_id` is forwarded to DLMM with `max_active_bin_slippage`. |
| DLMM Zap In | Zap sets `should_claim_fee = false`, `should_claim_reward = false`, `min_withdraw_x_amount = 0`, `min_withdraw_y_amount = 0`, and `removes = []`. |
| Zap Out | `payload_data` must start with an 8-byte supported instruction discriminator, and `offset_amount_in` must point to the amount-in field to rewrite. |
## Token Compatibility
Zap In calculates transfer-fee-excluded amounts for token mints when it needs to reason about net deposit amounts. For Token 2022 mints without a transfer fee extension, the calculation is treated like a normal token amount.
Do not assume every Token 2022 extension is compatible with every underlying DAMM v2, DLMM, or Jupiter route. Zap can coordinate supported instructions, but the downstream program still defines whether a token behavior is valid.
## Not a Fit
Use a direct integration instead of Zap when:
* The target AMM is not DAMM v2 or DLMM.
* The Zap Out route is not one of the four whitelisted instruction types.
* The flow needs Zap In swaps through Jupiter or another external router inside the Zap instruction.
* The DLMM flow needs Zap itself to withdraw liquidity, claim fees, or claim rewards.
* The token behavior is unsupported by the underlying product or route.
* The product copy needs to promise best execution, guaranteed output, or automatic route selection.
# Zap Formulas and Limits
Source: https://docs.meteora.ag/helper-products/zap/formula-and-limits
Review the formulas, units, rounding behavior, and limits used by the Zap program.
Zap uses integer arithmetic and delegates most AMM math to DAMM v2 or DLMM. This page covers the calculations Zap performs directly.
## Zap Out Amount
Zap Out starts from the increase in the user's input token account:
```math theme={"system"}
\text{balance increase} = \text{post balance} - \text{pre balance}
```
If `pre_user_token_balance >= post balance`, Zap returns successfully and does not invoke a swap.
The swap amount is:
```math theme={"system"}
\text{swap amount} =
\min\left(
\left\lfloor\frac{\text{balance increase} \times \text{percentage}}{100}\right\rfloor,
\text{max swap amount}
\right)
```
For `percentage = 100`, Zap uses the full balance increase before applying the max-swap cap.
| Parameter | Limit |
| ------------------ | -------------------------------------------------------------------------- |
| `percentage` | Must be `1` through `100`. |
| `max_swap_amount` | Caps the calculated swap amount. |
| `payload_data` | Must contain at least the first 8 discriminator bytes for the route check. |
| `offset_amount_in` | Must allow 8 bytes to fit inside `payload_data`. |
Zap writes the final swap amount into `payload_data` as a little-endian `u64`.
## Ledger Delta Updates
When Zap updates a ledger after a balance-changing CPI, it applies the token account delta to the current ledger amount:
```math theme={"system"}
\text{new ledger amount}
=
\text{old ledger amount}
+ \text{post token balance}
- \text{pre token balance}
```
For `update_ledger_balance_after_swap`, the recorded amount is capped:
```math theme={"system"}
\text{recorded amount}
=
\min(\text{post token balance} - \text{pre token balance}, \text{max transfer amount})
```
The balance delta uses saturating subtraction, so if the current token balance is below the supplied pre-balance, the delta is `0`.
## Transfer-Fee-Excluded Amounts
Zap In uses transfer-fee-excluded token amounts when calculating DAMM v2 liquidity and DLMM strategy parameters:
```math theme={"system"}
\text{net amount} = \text{gross amount} - \text{transfer fee}
```
For SPL Token mints and Token 2022 mints without a transfer fee extension, the transfer fee is treated as `0`. For Token 2022 transfer-fee mints, Zap uses the current epoch's configured fee.
## DAMM v2 Price Slippage
DAMM v2 Zap In checks the pool sqrt price after the optional balancing swap:
```math theme={"system"}
\text{sqrt price change bps}
=
\left\lceil
\frac{|\text{post sqrt price} - \text{pre sqrt price}| \times 10{,}000}
{\text{pre sqrt price}}
\right\rceil
```
The instruction fails if:
```math theme={"system"}
\text{sqrt price change bps} > \text{max sqrt price change bps}
```
`max_sqrt_price_change_bps` is supplied by the caller as a `u32`.
## DAMM v2 Surplus-Side Swap
DAMM v2 Zap In compares how much liquidity the ledger's token A and token B amounts can provide. The side that can provide more liquidity is considered surplus:
| Comparison | Swap direction |
| -------------------------------------- | -------------- |
| `liquidity_from_a > liquidity_from_b` | Swap A to B. |
| `liquidity_from_a <= liquidity_from_b` | Swap B to A. |
Zap then uses a binary search of up to `20` iterations to estimate an exact-in swap amount that makes the remaining user amounts closer to the pool ratio. The search accounts for DAMM v2 fee mode, dynamic fee, reserves, compounding fee behavior, and transfer-fee-excluded token amounts.
The internal DAMM v2 fee simulation supports these base fee modes:
* `FeeTimeSchedulerLinear`
* `FeeTimeSchedulerExponential`
* `FeeMarketCapSchedulerLinear`
* `FeeMarketCapSchedulerExponential`
* `RateLimiter`
If the calculation fails or produces a zero input or output amount, Zap skips the swap and returns successfully.
## DLMM Range
DLMM Zap In receives `min_delta_id` and `max_delta_id` relative to the current active bin. The program requires:
```math theme={"system"}
\text{min delta id} \le \text{max delta id}
```
For a new position, Zap initializes the DLMM position with:
```math theme={"system"}
\text{lower bin id} = \text{current active id} + \text{min delta id}
```
```math theme={"system"}
\text{width} = \text{max delta id} - \text{min delta id} + 1
```
The strategy math uses the pair's current `active_id` and `bin_step`.
## Active Bin Side Selection
`favor_x_in_active_id` controls which side receives the active bin when a range crosses the active bin.
| `favor_x_in_active_id` | Y-side end | X-side start |
| ---------------------- | ---------- | ------------ |
| `true` | `-1` | `0` |
| `false` | `0` | `1` |
This matters because bins below the active area use token Y, bins above it use token X, and the active bin can be assigned to either side.
## DLMM Strategy Shapes
Zap computes DLMM `AddLiquidityParams` for three strategy types:
| Strategy | Program behavior |
| -------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| `Spot` | Token Y is divided evenly across Y-side bins. Token X is weighted by inverse bin price across X-side bins. |
| `Curve` | Liquidity is concentrated toward the active area. The slope terms are negative on each side and integer division rounds amounts down. |
| `BidAsk` | Liquidity is weighted toward the range edges. The slope terms are positive on each side, except single-bin ranges use the single-bin formula. |
The computed signed parameters are stored as absolute `u64` values plus a bit flag that marks which of `x0`, `y0`, `delta_x`, or `delta_y` was negative.
Zap's DLMM strategy math is parameter generation for DLMM `rebalance_liquidity`. DLMM still performs its own validation and liquidity accounting during the CPI.
## Error Conditions
| Error | Common cause |
| ---------------------------- | ------------------------------------------------------------------------------------ |
| `InvalidZapOutParameters` | Zap Out percentage is `0` or greater than `100`. |
| `AmmIsNotSupported` | Zap Out program/discriminator pair is not whitelisted. |
| `InvalidOffset` | `offset_amount_in + 8` exceeds payload length. |
| `InvalidPosition` | New DLMM position account is already initialized or is the owner/rent payer account. |
| `ExceededSlippage` | DAMM v2 sqrt price moved beyond `max_sqrt_price_change_bps`. |
| `InvalidDlmmZapInParameters` | `min_delta_id > max_delta_id`. |
| `UnsupportedFeeMode` | DAMM v2 fee mode cannot be handled by Zap's swap amount calculation. |
# What is Zap?
Source: https://docs.meteora.ag/helper-products/zap/what-is-zap
Learn how Meteora Zap coordinates supported zap-in and zap-out flows for DAMM v2 and DLMM positions.
## Overview
Zap is Meteora's helper program for position workflows that need token accounting, a supported swap, or a follow-up liquidity action.
In practice, Zap has two jobs:
* **Zap In**: use tracked token amounts to add liquidity to a supported DAMM v2 or DLMM position flow.
* **Zap Out**: detect tokens received during the current flow and swap a selected percentage through a whitelisted route.
Zap runs on the program `zapvX9M3uf5pvy4wRPAbQgdQsM1xmuiFnkfHKPvwMiz`.
Zap is deliberately narrow. It only supports the instructions and routes described in this section; it is not a general-purpose Solana router.
## Core Features
Zap In flows use a user-owned ledger PDA to track token A/B or token X/Y amounts before and after swaps or deposits.
Zap can add DAMM v2 liquidity, optionally swap the surplus side through DAMM v2, then add remaining liquidity again.
Zap can initialize a new DLMM position or deposit into an existing position with Spot, Curve, or Bid-Ask distribution parameters.
Zap can rewrite the amount field in a prepared DAMM v2, DLMM, or Jupiter v6 swap instruction and invoke it for the detected balance increase.
## What Zap Supports
| Area | Supported by the Zap program |
| ------------------------ | ------------------------------------------------------------------------------------------------------ |
| DAMM v2 Zap In | Add liquidity, calculate the surplus side, swap through DAMM v2 `swap2`, then add remaining liquidity. |
| DLMM Zap In | New and existing positions through DLMM `rebalance_liquidity`. |
| DLMM strategies | `Spot`, `Curve`, and `BidAsk`. |
| Zap Out routes | DAMM v2 swap, DLMM `swap2`, Jupiter v6 route, and Jupiter v6 shared-account route. |
| Ledger accounting | One PDA per owner using the `user_ledger` seed. |
| Token 2022 transfer fees | Transfer-fee-aware net amount calculations in Zap In liquidity math. |
## What Zap Does Not Do
Zap does not choose the user's pool, route, quote, position range, or slippage settings. Frontends and integrators still prepare those decisions before calling the program.
Zap also does not guarantee the best route or exact final output. Swap execution still depends on pool liquidity, price movement, route accounts, token behavior, and the slippage checks used by the underlying program.
## How It Works
```text theme={"system"}
Frontend prepares accounts, quote, range, and payload
|
Zap validates ownership, route type, and supplied limits
|
Zap updates ledger balances or detects received tokens
|
Zap CPIs into DAMM v2, DLMM, or a whitelisted Zap Out route
```
For Zap In, the frontend records the token amounts in a user ledger before calling the DAMM v2 or DLMM Zap In instruction. For Zap Out, the frontend supplies a prepared swap instruction payload, and Zap replaces the amount field with the percentage of tokens received during the current flow.
## Product Fit
Zap is useful when a user intent maps cleanly to one of the supported flows:
* Add liquidity to a DAMM v2 position using amounts already tracked in the ledger.
* Create a DLMM position and deposit into a selected bin range.
* Add to or reposition an existing DLMM position with a supported strategy.
* Claim, withdraw, or otherwise receive tokens, then convert a selected percentage through a supported Zap Out route.
For unsupported AMMs, unsupported Jupiter instructions, custom token behavior, or complex conditional execution, use the underlying program or route directly.
## Read Next
Review supported instructions, routes, accounts, access controls, and not-fit cases.
See the percentage, slippage, price, and DLMM strategy math used by the program.
Zap simplifies supported workflows, but users still take AMM, route, price movement, and token behavior risk.
# Actions
Source: https://docs.meteora.ag/invent/actions
Run Meteora Invent CLI workflows for onchain actions across Meteora programs.
Launch anything and do any onchain action on Meteora in just a few configurations and commands. Meteora Invent helps you test fast and launch fast with reusable configs and CLI actions.
Using an AI agent? Install the [Meteora Agent Skill](/agents/skill) — it ships in the same repository (`skills/meteora`) and teaches agents every action on this page with dry-run and confirmation safety gates built in.
# Prerequisites
* Node.js >= 22.12.0
* pnpm >= 10.0.0
*If you don't have pnpm installed, you can install it by running the following command.*
```bash Terminal theme={"system"}
npm install -g pnpm
```
# Steps
Meteora Invent is a toolkit consisting of everything you need to invent innovative token launches on Meteora. Run the following command in your terminal to get started.
```bash Terminal theme={"system"}
git clone https://github.com/MeteoraAg/meteora-invent.git
```
Once you've cloned the repository, you'll have a new project directory with a meteora-invent folder. Run the following to install pnpm and the project dependencies.
```bash Terminal theme={"system"}
cd meteora-invent
pnpm install
```
![]()
Copy the `.env.example` file to `.env` and configure the environment variables.
```bash Terminal theme={"system"}
cp studio/.env.example studio/.env
```
Configure the following variables:
* `PRIVATE_KEY` - Your private key for the wallet you will be using to deploy the pool.
You can also run the studio scripts on localnet - [http://localhost:8899](http://localhost:8899) with the following command
```bash Terminal theme={"system"}
pnpm studio start-test-validator
```
This will start a local validator on your machine which will be hosted on `http://localhost:8899`.
Generate a keypair from your private key:
```bash Terminal theme={"system"}
# For devnet (airdrops 5 SOL)
pnpm studio generate-keypair --network devnet --airdrop
# For localnet (airdrops 5 SOL)
# Ensure that you have already started the local validator with pnpm start-test-validator
pnpm studio generate-keypair --network localnet --airdrop
```
This will generate a `keypair.json` file in the `studio` directory which will be used for all actions.
Configure the config files in the `studio/config` directory.
* Configure [DLMM](https://github.com/MeteoraAg/meteora-invent/blob/main/studio/config/dlmm_config.jsonc)
* Configure [DAMM v2](https://github.com/MeteoraAg/meteora-invent/blob/main/studio/config/damm_v2_config.jsonc)
* Configure [DAMM v1](https://github.com/MeteoraAg/meteora-invent/blob/main/studio/config/damm_v1_config.jsonc)
* Configure [DBC](https://github.com/MeteoraAg/meteora-invent/blob/main/studio/config/dbc_config.jsonc)
* Configure [Alpha Vault](https://github.com/MeteoraAg/meteora-invent/blob/main/studio/config/alpha_vault_config.jsonc)
* Configure [Presale Vault](https://github.com/MeteoraAg/meteora-invent/blob/main/studio/config/presale_vault_config.jsonc)
* Configure [Met Lock](https://github.com/MeteoraAg/meteora-invent/blob/main/studio/config/lock_config.jsonc)
* Configure [Dynamic Vault](https://github.com/MeteoraAg/meteora-invent/blob/main/studio/config/dynamic_vault_config.jsonc)
* Configure [Dynamic Fee Sharing](https://github.com/MeteoraAg/meteora-invent/blob/main/studio/config/fee_sharing_config.jsonc)
* Configure [Pool Farms](https://github.com/MeteoraAg/meteora-invent/blob/main/studio/config/farming_config.jsonc)
* Configure [Zap](https://github.com/MeteoraAg/meteora-invent/blob/main/studio/config/zap_config.jsonc)
After configuring the settings in the JSON files, you can choose the action you want to perform.
Timestamp fields in these templates ship as placeholder dates that have already passed. Replace them with future values before you run an action that uses them, such as a presale end time, an Alpha Vault deposit window, or a vesting cliff.
# Actions
## DLMM
Launch a DLMM customizable launch pool
Seed Liquidity with your preferred curve
Seed Liquidity in a single bin
Set your DLMM Pool Status
Place a bid or ask limit order on your DLMM pool
List your open limit orders with fill status
Cancel limit orders and withdraw proceeds
Swap tokens on a DLMM pool with a quote and slippage protection
Claim swap fees and LM rewards across your DLMM positions
List your DLMM positions with bin ranges, amounts, and unclaimed fees
## DAMM v2
Launch a DAMM v2 balanced pool
Launch a DAMM v2 one-sided pool
Split an existing LP Position on DAMM v2 pool
Claim an existing DAMM v2 pool position fee
Add liquidity to an existing DAMM v2 pool position
Remove liquidity from an existing DAMM v2 pool position (includes refresh vesting and closing position)
Close an existing DAMM v2 pool position
Swap tokens on a DAMM v2 pool (Token-2022 aware)
List your DAMM v2 positions with liquidity and unclaimed fees
## DAMM v1
Launch a DAMM v1 constant product launch pool
Lock liquidity for a DAMM v1 pool
Create a Stake2Earn Farm for a DAMM v1 pool
Lock liquidity for a Stake2Earn Farm pool
Swap tokens on a DAMM v1 pool
## DBC
Launch a Dynamic Bonding Curve token pool
Create a Dynamic Bonding Curve config containing the settings for pre-graduation and post-graduation pools
Claim partner and/or creator trading fees for a DBC pool
Migrate your DBC pool to a DAMM v1 pool
Migrate your DBC pool to a DAMM v2 pool
Swap (Buy/Sell) tokens on a DBC pool
Read graduation progress, migration state, reserves, and unclaimed fees
## Alpha Vault
Create an Alpha Vault with an already existing DAMM v1 or DAMM v2 or DLMM pool
Deposit quote tokens into a vault, with the merkle proof fetched for you on permissioned vaults
Withdraw a deposit during the deposit phase of a prorata vault
Claim your vested tokens once the vault has bought from the pool
Recover the unused portion of a prorata deposit after the vault has filled
Run the permissionless crank that buys from the pool until the vault is filled
Read the vault mode, phase, caps, and totals, plus your own escrow when a keypair is present
## Presale Vault
Create a Fixed Price or FCFS or Prorata Presale Vault
Deposit quote tokens into a presale tier, creating your escrow in the same transaction
Withdraw a deposit while the presale still allows it
Claim your purchased tokens, including the vesting schedule when one is set
Sweep the unused quote left over across every tier you deposited into
Reclaim escrow rent once your escrow is fully settled
Withdraw the raise as the creator, optionally collecting the deposit fee
Refund or burn the base tokens the presale did not sell
Read progress, totals, average price, and per-tier state, or find a presale by its base mint
## Met Lock
Lock any SPL or Token-2022 mint for a recipient on a cliff and vesting schedule
Attach a name and contact details to an escrow so recipients can identify it
Claim whatever has vested so far as the escrow recipient
Read one escrow's schedule, total locked, claimed, and claimable amounts
List every escrow where a wallet is the recipient or the creator
## Stake2Earn
Stake tokens into a DAMM v1 pool's fee farm to earn a share of trading fees
Claim the fees your stake has earned in both pool tokens
Begin the unstake cooldown, saving the unstake address you will need to finish it
Cancel a pending unstake to restake, or withdraw once the cooldown has passed
Read the farm's top-list threshold and your staked amount, pending fees, and open unstakes
## Pool Farms
Stake DAMM v1 LP tokens into a reward farm
Withdraw some or all of your staked LP tokens
Claim accumulated rewards from a single farm
Batch reward claims across a list of farms
Read the farm's staking mint, total staked, reward schedule, and your own position
## Dynamic Vault
Deposit a token into its dynamic vault to earn lending yield on idle balances
Redeem vault LP shares back into the underlying token
Read total supply, withdrawable amount, virtual price, and your redemption value
## Dynamic Fee Sharing
Split a fee stream between up to five recipients on fixed shares
Transfer tokens straight into a fee vault for distribution
Hand a position's NFT to the fee vault so the vault can claim its fees
Claim a vault-owned position's trading fees directly into the fee vault
Claim a vault-owned position's reward emissions into the fee vault
Route DBC creator or partner trading fees, surplus, or migration fees into the fee vault
Claim whatever your share of the vault has accrued
Read the recipient split, funded totals, and each share's claimed and claimable amounts
## Zap
Enter a DAMM v2 position with a single token, sourcing the other side from the pool itself
Enter a DLMM position with a single token, pricing the rebalancing swap against Jupiter
Remove liquidity from a DAMM v2 or DLMM position and exit into a single token
# DAMM v1 Launch Pool
Source: https://docs.meteora.ag/invent/launch-pools/damm-v1-launch-pool
Learn how to create a Meteora DAMM v1 launch pool with constant-product liquidity, activation controls, optional Alpha Vault, liquidity locks, and Stake2Earn settings.
This guide walks you through the steps to create a DAMM v1 launch pool on Meteora. Whether you’re a seasoned developer or just starting out, this guide has got you covered to deploy liquidity and launch your project on Meteora.
# What You'll Achieve
By the end of this quicklaunch, you’ll have built a liquidity pool on Meteora by:
* Configuring your liquidity pool settings
* Interacting with our DAMM v1 program
* Seeing your liquidity pool in action on Meteora
**Why Meteora?**
Meteora is a hyper optimized liquidity layer that ensures that your project's provided liquidity is secure, sustainable and composable for anyone to trade on. By following this guide, you'll be able to launch a balanced constant product liquidity pool with auto yield accrual on Meteora in just a few quick and easy steps.
# Prerequisites
* Node.js >= 22.12.0
* pnpm >= 10.0.0
*If you don't have pnpm installed, you can install it by running the following command.*
```bash Terminal theme={"system"}
npm install -g pnpm
```
# Steps
Meteora Invent is a toolkit consisting of everything you need to invent innovative token launches on Meteora. Run the following command in your terminal to get started.
```bash Terminal theme={"system"}
git clone https://github.com/MeteoraAg/meteora-invent.git
```
Once you've cloned the repository, you'll have a new project directory with a meteora-invent folder. Run the following to install pnpm and the project dependencies.
```bash Terminal theme={"system"}
cd meteora-invent
pnpm install
```
![]()
In Meteora Invent we provide an optional command for you to run a local validator to test your pool before deploying it to devnet or mainnet. Run the following command in your code editor terminal to get started.
```bash Terminal theme={"system"}
pnpm studio start-test-validator
```
This will start a local validator on your machine which will be hosted on `http://localhost:8899`.
![]()
We provide an easy way to setup environment variables when getting started. Run the following command in your code editor terminal to get started.
```bash Terminal theme={"system"}
cp studio/.env.example studio/.env
```
This will copy the example environment variables file to your `.env` file. Configure the following variables:
* `PRIVATE_KEY` - Your private key for the wallet you will be using to deploy the pool.
Thereafter, you will need to run this command to generate a keypair from your wallet private key.
```bash Terminal theme={"system"}
pnpm studio generate-keypair
# For devnet (airdrops 5 SOL)
pnpm studio generate-keypair --network devnet --airdrop
# For localnet (airdrops 5 SOL)
# Ensure that you have already started the local validator with pnpm start-test-validator
pnpm studio generate-keypair --network localnet --airdrop
```
This will generate a `keypair.json` file in the `studio` directory which will be used for all actions in this guide.
![]()
Navigate to the `studio/config/damm_v1_config.jsonc` file and configure your DAMM v1 pool settings.
You can configure everything DAMM v1 pool related in this file.
The comments in the file are to help you understand the different settings you can configure. Please ensure that you read through the comments while configuring your pool.
```jsonc damm_v1_config.jsonc theme={"system"}
{
/* rpcUrl is required. You can switch between mainnet, devnet and localnet or use your own RPC URL. */
"rpcUrl": "https://api.devnet.solana.com", // mainnet: https://api.mainnet-beta.solana.com | devnet: https://api.devnet.solana.com | localnet: http://localhost:8899
/* dryRun is required. If true, transactions will be simulated and not executed. If false, transactions will be executed. */
"dryRun": true, // Set to false only after you understand what will happen
/* keypairFilePath is required and will be the payer + signer for all transactions */
"keypairFilePath": "./keypair.json",
/* computeUnitPriceMicroLamports is required and can be adjusted to fit your needs */
"computeUnitPriceMicroLamports": 100000,
/* quoteMint is required for the following actions:
* 1. damm-v1-create-pool
* 2. damm-v1-create-stake2earn-farm
* 3. damm-v1-lock-liquidity
* 4. damm-v1-lock-liquidity-stake2earn
* SOL: So11111111111111111111111111111111111111112 | USDC: EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v | any other token address
*/
"quoteMint": "So11111111111111111111111111111111111111112",
/* If you have a baseMint already created, you can specify it in the cli command via --baseMint flag. If you don't have a baseMint, you can create a new one using createBaseToken.
* Either use --baseMint flag or createBaseToken, but not both.
*/
"createBaseToken": {
"supply": 1000000000, // total amount of base token to be minted
"decimals": 6, // decimals of the base token
// "tokenMintKeypairFilePath": "./mint-keypair.json", // path to token mint keypair if you have a specific keypair for the token mint. If not provided, a new keypair will be generated.
"name": "YOUR_TOKEN_NAME", // token name
"symbol": "YOUR_TOKEN_SYMBOL", // token symbol
"authorities": {
"mint": "YOUR_MINT_AUTHORITY_ADDRESS", // token mint authority address.
"freeze": "YOUR_FREEZE_AUTHORITY_ADDRESS", // token freeze authority address.
"update": "YOUR_UPDATE_AUTHORITY_ADDRESS" // token update authority address.
},
/* Optional Metaplex Token Metadata Properties
* Read more about the properties here: https://developers.metaplex.com/token-metadata
*/
"sellerFeeBasisPoints": 0, // Royalty fee in basis points (0-10000)
"creators": null, // Array of creator objects of the token (optional)
"collection": null, // Collection info (optional)
"uses": null, // Usage restrictions (optional)
"metadata": {
// "uri": "https://gateway.irys.xyz/123456789", // if you already have a metadata URI created, you can specify it here
/* Only use the following parameters for createBaseToken if you don't have an existing metadata uri
* This will create an image uri and a new metadata uri and upload everything to Irys
*/
"image": "./data/image/test-token.jpg", // this can be a URL of the image address (e.g. https://example.com/token-image.png) or the image file path (e.g. ./data/image/test-token.jpg)
"description": "YOUR_TOKEN_DESCRIPTION", // token description
"website": "https://example.com", // project website
"twitter": "https://x.com/yourproject", // twitter URL
"telegram": "https://t.me/yourproject" // telegram URL
}
},
/* dammV1Config is only used in the following actions:
* 1. damm-v1-create-pool
*/
"dammV1Config": {
"baseAmount": 100, // base token amount
"quoteAmount": 0.001, // quote token amount
"tradeFeeNumerator": 2500, // pool fee in bps
"activationType": 1, // 0 - Slot | 1 - Timestamp
"activationPoint": null, // Activation time of the pool depending on activationType (Calculate in slots if activationType is 0 (slots) | Calculate in seconds if activationType is 1 (timestamp))
"hasAlphaVault": false // If true, the alpha vault will be created after the pool is created
},
/* dammV1LockLiquidity is only used in the following actions:
* 1. damm-v1-lock-liquidity
* 2. damm-v1-lock-liquidity-stake2earn
*/
"dammV1LockLiquidity": {
"allocations": [
{
"percentage": 80, // percentage of the LP tokens that will be allocated to address 1
"address": "YOUR_ADDRESS_1" // address 1
},
{
"percentage": 20, // percentage of the LP tokens that will be allocated to address 2
"address": "YOUR_ADDRESS_2" // address 2
}
]
},
/* stake2EarnFarm is only used in the following actions:
* 1. damm-v1-create-stake2earn-farm
*/
"stake2EarnFarm": {
"topListLength": 100, // Maximum number of top stakers eligible for fee rewards (minimum 50, maximum 1000)
"unstakeLockDurationSecs": 25200, // 7-hour cooldown period before unstaked tokens can be withdrawn
"secondsToFullUnlock": 86400, // 24-hour period for locked fees to fully drip/release to stakers
"startFeeDistributeTimestamp": 1753441790 // Start date for fee distribution (Jan 24, 2025 17:49:50 UTC)
},
/* alphaVault is only used in the following actions:
* 1. damm-v1-create-pool
* There are 2 types of alpha vault: First Come First Serve (FCFS) and Prorata.
*/
"alphaVault": {
"poolType": "dynamic", // DLMM = dlmm | DAMM v1 = dynamic | DAMM v2 = damm2
"alphaVaultType": "fcfs", // FCFS = fcfs | Prorata = prorata
/* Only use the following parameters for alphaVaultType: fcfs
* 1. maxDepositCap
* 2. individualDepositingCap
*/
"maxDepositCap": 10000, // Maximum total amount (in quote token) that can be deposited across all users in the vault
"individualDepositingCap": 1, // Maximum amount (in quote token) that each individual user can deposit
/* Only use the following parameters for alphaVaultType: prorata
* 1. maxBuyingCap
*/
// "maxBuyingCap": 10000, // Maximum total amount (in quote token) that can be bought across all users in the vault
"depositingPoint": 1733626299, // When users can start depositing depending on pool's activationType (Calculate in slots if activationType is 0 (slots) | Calculate in seconds if activationType is 1 (timestamp))
"startVestingPoint": 1746808201, // When token vesting begins and users can start claiming their vested tokens depending on pool's activationType (Calculate in slots if activationType is 0 (slots) | Calculate in seconds if activationType is 1 (timestamp))
"endVestingPoint": 1746808201, // When token vesting ends and all tokens become fully claimable depending on pool's activationType (Calculate in slots if activationType is 0 (slots) | Calculate in seconds if activationType is 1 (timestamp))
"escrowFee": 0, // Fee amount (in quote token) charged when creating a stake escrow account
"whitelistMode": "permissionless" // Whitelist mode: permissionless | permissioned_with_merkle_proof | permissioned_with_authority
/* Optional Configuration: whitelistFilePath
* Only use when whitelistMode is permissioned_with_merkle_proof or permissioned_with_authority
*/
// "whitelistFilepath": "./data/whitelist_wallet.csv", // Optional path to CSV file containing whitelisted wallet addresses and their deposit caps (format: wallet,deposit_cap)
/* Optional Configuration: merkleProofBaseUrl, chunkSize, kvProofFilepath, cloudflareKvProofUpload
* Only use when whitelistMode is permissioned_with_merkle_proof
*/
// "merkleProofBaseUrl": "https://example.workers.dev/", // Base URL endpoint where merkle proofs are stored and can be retrieved for whitelisted wallet verification
// "chunkSize": 1000, // Optional batch size for processing large whitelist files or merkle tree operations to avoid memory/performance issues
// "kvProofFilepath": "./data/kv_proofs", // Optional path to key-value file storing pre-computed merkle proofs for whitelisted addresses
// "cloudflareKvProofUpload": {
// "kvNamespaceId": "YOUR_KV_NAMESPACE_ID",
// "accountId": "YOUR_ACCOUNT_ID",
// "apiKey": "YOUR_API_KEY"
// }
}
}
```
The toolkit contains logic to make it easier for you to create the DAMM v1 pool such as:
* Minting a new `baseMint` token or parsing in an existing `baseMint` token.
* Launching the DAMM v1 pool immediately or at a certain `activationPoint` (in slots or timestamp depending on the `activationType`).
* Optional creation of an Alpha Vault with your DAMM v1 launch pool.
After configuring your DAMM v1 pool settings in `damm_v1_config.jsonc`, you can now create your pool by running the following command. These commands will create your pool and
*If you don't have a base mint, you can configure `createBaseToken` in the config file and run the
following command.*
```bash theme={"system"}
pnpm studio damm-v1-create-pool
```
*If you already have a base mint created, you can provide it via the CLI with a `--baseMint` flag
and run the following command.*
```bash theme={"system"}
pnpm studio damm-v1-create-pool --baseMint
```
This will create your pool with liquidity deposited from your `keypair.json` and print the pool address and other relevant information to the console.
![]()
Voilà! You've successfully created your DAMM v1 pool on Meteora. You can now see your pool in action on Meteora either on Meteora's [mainnet](https://app.meteora.ag) or [devnet](https://devnet.meteora.ag) app.
# DAMM v2 Launch Pool
Source: https://docs.meteora.ag/invent/launch-pools/damm-v2-launch-pool
Learn how to create a Meteora DAMM v2 launch pool with balanced or one-sided liquidity, configurable fees, activation controls, optional Alpha Vault, and position management settings.
This guide walks you through the steps to create a DAMM v2 launch pool on Meteora. Whether you’re a seasoned developer or just starting out, this guide has got you covered to deploy liquidity and launch your project on Meteora.
# What You'll Achieve
By the end of this quicklaunch, you’ll have built a liquidity pool on Meteora by:
* Configuring your liquidity pool settings
* Interacting with our DAMM v2 program
* Seeing your liquidity pool in action on Meteora
**Why Meteora?**
Meteora is a hyper optimized liquidity layer that ensures that your project's provided liquidity is secure, sustainable and composable for anyone to trade on. By following this guide, you'll be able to launch a balanced / concentrated / one-sided liquidity pool with dynamic fees on Meteora in just a few quick and easy steps.
# Prerequisites
* Node.js >= 22.12.0
* pnpm >= 10.0.0
*If you don't have pnpm installed, you can install it by running the following command.*
```bash Terminal theme={"system"}
npm install -g pnpm
```
# Steps
Meteora Invent is a toolkit consisting of everything you need to invent innovative token launches on Meteora. Run the following command in your terminal to get started.
```bash Terminal theme={"system"}
git clone https://github.com/MeteoraAg/meteora-invent.git
```
Once you've cloned the repository, you'll have a new project directory with a meteora-invent folder. Run the following to install pnpm and the project dependencies.
```bash Terminal theme={"system"}
cd meteora-invent
pnpm install
```
![]()
In Meteora Invent we provide an optional command for you to run a local validator to test your pool before deploying it to devnet or mainnet. Run the following command in your code editor terminal to get started.
```bash Terminal theme={"system"}
pnpm studio start-test-validator
```
This will start a local validator on your machine which will be hosted on `http://localhost:8899`.
![]()
We provide an easy way to setup environment variables when getting started. Run the following command in your code editor terminal to get started.
```bash Terminal theme={"system"}
cp studio/.env.example studio/.env
```
This will copy the example environment variables file to your `.env` file. Configure the following variables:
* `PRIVATE_KEY` - Your private key for the wallet you will be using to deploy the pool.
Thereafter, you will need to run this command to generate a keypair from your wallet private key.
```bash Terminal theme={"system"}
pnpm studio generate-keypair
# For devnet (airdrops 5 SOL)
pnpm studio generate-keypair --network devnet --airdrop
# For localnet (airdrops 5 SOL)
# Ensure that you have already started the local validator with pnpm start-test-validator
pnpm studio generate-keypair --network localnet --airdrop
```
This will generate a `keypair.json` file in the `studio` directory which will be used for all actions in this guide.
![]()
Navigate to the `studio/config/damm_v2_config.jsonc` file and configure your DAMM v2 pool settings.
You can configure everything DAMM v2 pool related in this file.
The comments in the file are to help you understand the different settings you can configure. Please ensure that you read through the comments while configuring your pool.
```jsonc damm_v2_config.jsonc theme={"system"}
{
/* rpcUrl is required. You can switch between mainnet, devnet and localnet or use your own RPC URL. */
"rpcUrl": "https://api.devnet.solana.com", // mainnet: https://api.mainnet-beta.solana.com | devnet: https://api.devnet.solana.com | localnet: http://localhost:8899
/* dryRun is required. If true, transactions will be simulated and not executed. If false, transactions will be executed. */
"dryRun": true, // Set to false only after you understand what will happen
/* keypairFilePath is required and will be the payer + signer for all transactions */
"keypairFilePath": "./keypair.json",
/* computeUnitPriceMicroLamports is required and can be adjusted to fit your needs */
"computeUnitPriceMicroLamports": 100000,
/* quoteMint is required for the following actions:
* 1. damm-v2-create-balanced-pool
* 2. damm-v2-create-one-sided-pool
* SOL: So11111111111111111111111111111111111111112 | USDC: EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v | any other token address
*/
"quoteMint": "So11111111111111111111111111111111111111112",
/* If you have a baseMint already created, you can specify it in the cli command via --baseMint flag. If you don't have a baseMint, you can create a new one using createBaseToken.
* Either use --baseMint flag or createBaseToken, but not both.
*/
"createBaseToken": {
"supply": 1000000000, // total amount of base token to be minted
"decimals": 6, // decimals of the base token
// "tokenMintKeypairFilePath": "./mint-keypair.json", // path to token mint keypair if you have a specific keypair for the token mint. If not provided, a new keypair will be generated.
"name": "YOUR_TOKEN_NAME", // token name
"symbol": "YOUR_TOKEN_SYMBOL", // token symbol
"authorities": {
"mint": "YOUR_MINT_AUTHORITY_ADDRESS", // token mint authority address.
"freeze": "YOUR_FREEZE_AUTHORITY_ADDRESS", // token freeze authority address.
"update": "YOUR_UPDATE_AUTHORITY_ADDRESS" // token update authority address.
},
/* Optional Metaplex Token Metadata Properties
* Read more about the properties here: https://developers.metaplex.com/token-metadata
*/
"sellerFeeBasisPoints": 0, // Royalty fee in basis points (0-10000)
"creators": null, // Array of creator objects of the token (optional)
"collection": null, // Collection info (optional)
"uses": null, // Usage restrictions (optional)
"metadata": {
// "uri": "https://gateway.irys.xyz/123456789", // if you already have a metadata URI created, you can specify it here
/* Only use the following parameters for createBaseToken if you don't have an existing metadata uri
* This will create an image uri and a new metadata uri and upload everything to Irys
*/
"image": "./data/image/test-token.jpg", // this can be a URL of the image address (e.g. https://example.com/token-image.png) or the image file path (e.g. ./data/image/test-token.jpg)
"description": "YOUR_TOKEN_DESCRIPTION", // token description
"website": "https://example.com", // project website
"twitter": "https://x.com/yourproject", // twitter URL
"telegram": "https://t.me/yourproject" // telegram URL
}
},
/* dammV2Config is only used in the following actions:
* 1. damm-v2-create-balanced-pool
* 2. damm-v2-create-one-sided-pool
*/
"dammV2Config": {
"creator": "YOUR_CREATOR_ADDRESS", // creator address
"baseAmount": 100000000, // base token amount
"quoteAmount": null, // quote token amount
"initPrice": 0.0001, // initial price (in terms of quote/base price) 1 SOL / 1000000000 = initialPrice
"minPrice": null, // min price (in terms of quote/base price) - NOTE: null would use the MIN_SQRT_PRICE for the DAMM v2 balanced pool
"maxPrice": null, // max price (in terms of quote/base price) - NOTE: null would use the MAX_SQRT_PRICE for the DAMM v2 balanced pool
"poolFees": {
"baseFee": {
"baseFeeMode": 2, // 0 - Fee Scheduler: Linear | 1 - Fee Scheduler: Exponential | 2 - Rate Limiter | 3 - Fee Market Cap Scheduler: Linear | 4 - Fee Market Cap Scheduler: Exponential
// "feeTimeSchedulerParam": {
// "startingFeeBps": 120, // starting base fee (in basis points) (if you want a flat fee, set startingFeeBps and endingFeeBps to the same value)
// "endingFeeBps": 120, // ending base fee (in basis points) (if you want a flat fee, set startingFeeBps and endingFeeBps to the same value)
// "numberOfPeriod": 0, // number of periods
// "totalDuration": 0 // total duration (If activationType is 0 (slots), totalDuration = duration / 0.4 | If activationType is 1 (timestamp), totalDuration = duration)
// }
"rateLimiterParam": {
"baseFeeBps": 120, // base fee (max 50% base fee === 5000 bps)
"feeIncrementBps": 100, // fee increment (max fee increment = 5000 bps - baseFeeBps)
"referenceAmount": 1, // reference amount (not in lamports)
"maxLimiterDuration": 3600, // if activationType is 0 (slots), maxLimiterDuration = duration / 0.4, if activationType is 1 (timestamp), maxLimiterDuration = duration)
"maxFeeBps": 5000 // max 50% base fee can go to === 5000 bps
}
// "feeMarketCapSchedulerParam": {
// "startingFeeBps": 500, // starting base fee (in basis points)
// "endingFeeBps": 50, // ending base fee (in basis points)
// "numberOfPeriod": 100, // number of fee reduction periods
// "priceMultiple": 1000, // ratio of ending market cap over starting market cap, must be greater than 1
// "schedulerExpirationDuration": 86400 // maximum duration (seconds) after which scheduler expires and defaults to ending fee
// }
},
"dynamicFeeEnabled": true // if dynamicFeeEnabled is true and dynamicFeeConfig is null, the default dynamic fee configuration will be 20% of the base fee
// "compoundingFeeBps": 5000 // Only used when collectFeeMode is 2 (Compounding). Percentage of trading fees compounded back into pool liquidity (0 to 10000 bps, e.g. 5000 = 50%). Required for compounding mode.
/* Optional Configuration.
* Only used if you want to configure dynamic fee and not use the default dynamic fee configuration
* Formula: dynamicFee = (variableFeeControl * (volatilityAccumulator * binStep)^2 + 99_999_999_999) / 100_000_000_000
*/
// "dynamicFeeConfig": {
// "filterPeriod": 10, // Time period (in slots/seconds) over which volatility is measured and smoothed
// "decayPeriod": 120, // Time period (in slots/seconds) over which volatility accumulator decays back to zero
// "reductionFactor": 5000, // Volatility decay rate in basis points (5000 = 50% reduction per decay period)
// "variableFeeControl": 14460000, // Scaling factor that controls how much volatility affects dynamic fees
// "maxVolatilityAccumulator": 239 // Maximum allowed volatility accumulator value (caps dynamic fee calculation)
// }
},
"collectFeeMode": 1, // 0 - Both Token | 1 - Token B Only | 2 - Compounding (balanced pool only - fees auto-compound back into liquidity)
"activationType": 1, // 0 - Slot | 1 - Timestamp
"activationPoint": null, // Activation time of the pool depending on activationType (Calculate in slots if activationType is 0 (slots) | Calculate in seconds if activationType is 1 (timestamp))
"hasAlphaVault": false // If true, the alpha vault will be created after the pool is created
},
/* addLiquidity is only used in the following actions:
* 1. damm-v2-add-liquidity
*/
"addLiquidity": {
"amountIn": 5, // this is the amount of token A or token B that will be added to the pool (in terms of the token amount)
"isTokenA": false // if your amountIn is in terms of token A, set isTokenA to true, if your amountIn is in terms of token B, set isTokenA to false
},
/* splitPosition is only used in the following actions:
* 1. damm-v2-split-position
*/
"splitPosition": {
"newPositionOwner": "YOUR_NEW_POSITION_OWNER_ADDRESS", // this is the address that will receive the new DAMM v2 NFT position
"unlockedLiquidityPercentage": 50, // this is the percentage of unlocked liquidity that will be split and transferred to the newPositionOwner's position
"permanentLockedLiquidityPercentage": 50, // this is the percentage of permanent locked liquidity that will be split and transferred to the newPositionOwner's position
"innerVestingLiquidityPercentage": 50, // this is the percentage of inner vesting liquidity that will be split and transferred to the newPositionOwner's position
"feeAPercentage": 50, // this is the percentage of unclaimed fee that will be transferred to the newPositionOwner's position
"feeBPercentage": 50, // this is the percentage of unclaimed fee that will be transferred to the newPositionOwner's position
"reward0Percentage": 50, // this is the percentage of unclaimed reward that will be transferred to the newPositionOwner's position
"reward1Percentage": 50 // this is the percentage of unclaimed reward that will be transferred to the newPositionOwner's position
},
/* alphaVault is only used in the following actions:
* 1. damm-v2-create-balanced-pool
* 2. damm-v2-create-one-sided-pool
* There are 2 types of alpha vault: First Come First Serve (FCFS) and Prorata.
*/
"alphaVault": {
"poolType": "damm2", // DLMM = dlmm | DAMM v1 = dynamic | DAMM v2 = damm2
"alphaVaultType": "fcfs", // FCFS = fcfs | Prorata = prorata
/* Only use the following parameters for alphaVaultType: fcfs
* 1. maxDepositCap
* 2. individualDepositingCap
*/
"maxDepositCap": 10000, // Maximum total amount (in quote token) that can be deposited across all users in the vault
"individualDepositingCap": 1, // Maximum amount (in quote token) that each individual user can deposit
/* Only use the following parameters for alphaVaultType: prorata
* 1. maxBuyingCap
*/
// "maxBuyingCap": 10000, // Maximum total amount (in quote token) that can be bought across all users in the vault
"depositingPoint": 1733626299, // When users can start depositing depending on pool's activationType (Calculate in slots if activationType is 0 (slots) | Calculate in seconds if activationType is 1 (timestamp))
"startVestingPoint": 1746808201, // When token vesting begins and users can start claiming their vested tokens depending on pool's activationType (Calculate in slots if activationType is 0 (slots) | Calculate in seconds if activationType is 1 (timestamp))
"endVestingPoint": 1746808201, // When token vesting ends and all tokens become fully claimable depending on pool's activationType (Calculate in slots if activationType is 0 (slots) | Calculate in seconds if activationType is 1 (timestamp))
"escrowFee": 0, // Fee amount (in quote token) charged when creating a stake escrow account
"whitelistMode": "permissionless" // Whitelist mode: permissionless | permissioned_with_merkle_proof | permissioned_with_authority
/* Optional Configuration: whitelistFilePath
* Only use when whitelistMode is permissioned_with_merkle_proof or permissioned_with_authority
*/
// "whitelistFilepath": "./data/whitelist_wallet.csv", // Optional path to CSV file containing whitelisted wallet addresses and their deposit caps (format: wallet,deposit_cap)
/* Optional Configuration: merkleProofBaseUrl, chunkSize, kvProofFilepath, cloudflareKvProofUpload
* Only use when whitelistMode is permissioned_with_merkle_proof
*/
// "merkleProofBaseUrl": "https://example.workers.dev/", // Base URL endpoint where merkle proofs are stored and can be retrieved for whitelisted wallet verification
// "chunkSize": 1000, // Optional batch size for processing large whitelist files or merkle tree operations to avoid memory/performance issues
// "kvProofFilepath": "./data/kv_proofs", // Optional path to key-value file storing pre-computed merkle proofs for whitelisted addresses
// "cloudflareKvProofUpload": {
// "kvNamespaceId": "YOUR_KV_NAMESPACE_ID",
// "accountId": "YOUR_ACCOUNT_ID",
// "apiKey": "YOUR_API_KEY"
// }
}
}
```
The toolkit contains logic to make it easier for you to create the DAMM v2 pool such as:
* Minting a new `baseMint` token or parsing in an existing `baseMint` token.
* Launching the DAMM v2 pool immediately or at a certain `activationPoint` (in slots or timestamp depending on the `activationType`).
* Fully customizable pool fees (including fee scheduler and dynamic fee settings).
* Optional creation of an Alpha Vault with your DAMM v2 launch pool.
After configuring your DAMM v2 pool settings in `damm_v2_config.jsonc`, you can now create your pool by running the following command.
*If you don't have a base mint, you can configure `createBaseToken` in the config file and run the
following command.*
```bash theme={"system"}
pnpm studio damm-v2-create-balanced-pool
```
*If you already have a base mint, you can provide it via the CLI with a `--baseMint` flag and run
the following command.*
```bash theme={"system"}
pnpm studio damm-v2-create-balanced-pool --baseMint
```
Creating a balanced pool will require the `quoteAmount` to be set in the `damm_v2_config.jsonc` file.
![]()
*If you don't have a base mint, you can configure `createBaseToken` in the config file and run the
following command.*
```bash theme={"system"}
pnpm studio damm-v2-create-one-sided-pool
```
*If you already have a base mint, you can provide it via the CLI with a `--baseMint` flag and run
the following command.*
```bash theme={"system"}
pnpm studio damm-v2-create-one-sided-pool --baseMint
```
This will create your pool with liquidity deposited from your `keypair.json` and print the pool address and other relevant information to the console.
![]()
Voilà! You've successfully created your DAMM v2 pool on Meteora. You can now see your pool in action on Meteora either on Meteora's [mainnet](https://app.meteora.ag) or [devnet](https://devnet.meteora.ag) app.
# DBC Token Launch Pool
Source: https://docs.meteora.ag/invent/launch-pools/dbc-token-launch-pool
Learn how to create a Meteora DBC token launch pool with configurable bonding curves, launch fees, token metadata, transfer hooks, DAMM migration, and liquidity distribution.
This guide walks you through the steps to create a DBC token launch pool on Meteora. Whether you’re a seasoned developer or just starting out, this guide has got you covered to deploy liquidity and launch your project on Meteora.
# What You'll Achieve
By the end of this quicklaunch, you’ll have built a liquidity pool on Meteora by:
* Configuring your bonding curve pool and graduated DAMM v1/v2 pool settings
* Interacting with our Dynamic Bonding Curve program
* Seeing your token tradable across trading terminals such as Jupiter Pro, Axiom, and Photon.
**Why Meteora?**
Meteora is a hyper optimized liquidity layer that ensures that your project's provided liquidity is secure, sustainable and composable for anyone to trade on. By following this guide, you'll be able to launch a bonding curve config and a token pool using the bonding curve config on Meteora in just a few quick and easy steps.
# Prerequisites
* Node.js >= 22.12.0
* pnpm >= 10.0.0
*If you don't have pnpm installed, you can install it by running the following command.*
```bash Terminal theme={"system"}
npm install -g pnpm
```
# Steps
Meteora Invent is a toolkit consisting of everything you need to invent innovative token launches on Meteora. Run the following command in your terminal to get started.
```bash Terminal theme={"system"}
git clone https://github.com/MeteoraAg/meteora-invent.git
```
Once you've cloned the repository, you'll have a new project directory with a meteora-invent folder. Run the following to install pnpm and the project dependencies.
```bash Terminal theme={"system"}
cd meteora-invent
pnpm install
```
![]()
In Meteora Invent we provide an optional command for you to run a local validator to test your pool before deploying it to devnet or mainnet. Run the following command in your code editor terminal to get started.
```bash Terminal theme={"system"}
pnpm studio start-test-validator
```
This will start a local validator on your machine which will be hosted on `http://localhost:8899`.
![]()
We provide an easy way to setup environment variables when getting started. Run the following command in your code editor terminal to get started.
```bash Terminal theme={"system"}
cp studio/.env.example studio/.env
```
This will copy the example environment variables file to your `.env` file. Configure the following variables:
* `PRIVATE_KEY` - Your private key for the wallet you will be using to deploy the pool.
Thereafter, you will need to run this command to generate a keypair from your wallet private key.
```bash Terminal theme={"system"}
pnpm studio generate-keypair
# For devnet (airdrops 5 SOL)
pnpm studio generate-keypair --network devnet --airdrop
# For localnet (airdrops 5 SOL)
# Ensure that you have already started the local validator with pnpm start-test-validator
pnpm studio generate-keypair --network localnet --airdrop
```
This will generate a `keypair.json` file in the `studio` directory which will be used for all actions in this guide.
![]()
Navigate to the `studio/config/dbc_config.jsonc` file and configure your DBC token pool settings.
You can configure everything DBC token pool related in this file.
The comments in the file are to help you understand the different settings you can configure. Please ensure that you read through the comments while configuring your pool.
```jsonc dbc_config.jsonc theme={"system"}
{
/* rpcUrl is required. You can switch between mainnet, devnet and localnet or use your own RPC URL. */
"rpcUrl": "https://api.devnet.solana.com", // mainnet: https://api.mainnet-beta.solana.com | devnet: https://api.devnet.solana.com | localnet: http://localhost:8899
/* dryRun is required. If true, transactions will be simulated and not executed. If false, transactions will be executed. */
"dryRun": true, // Set to false only after you understand what will happen
/* keypairFilePath is required and will be the payer + signer for all transactions */
"keypairFilePath": "./keypair.json",
/* computeUnitPriceMicroLamports is required and can be adjusted to fit your needs */
"computeUnitPriceMicroLamports": 100000,
/* quoteMint is required for the following actions:
* 1. dbc-create-config
* 2. dbc-create-pool (if there is no configKeyAddress)
* SOL: So11111111111111111111111111111111111111112 | USDC: EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v | any other token address
*/
"quoteMint": "So11111111111111111111111111111111111111112",
/* dbcConfig is only used in the following actions:
* 1. dbc-create-config
* 2. dbc-create-pool (if there is no --config flag indicated in the command)
*/
"dbcConfig": {
"buildCurveMode": 0, // 0 - buildCurve | 1 - buildCurveWithMarketCap | 2 - buildCurveWithTwoSegments | 3 - buildCurveWithLiquidityWeights | 4 - buildCurveWithMidPrice | 5 - buildCurveWithCustomSqrtPrices
/* Only use the following parameters for buildCurveMode: 0 (buildCurve)
* 1. percentageSupplyOnMigration
* 2. migrationQuoteThreshold
*/
"percentageSupplyOnMigration": 20, // percentage of total token supply to be migrated
"migrationQuoteThreshold": 10, // migration quote threshold needed to migrate the DBC token pool
/* Only use the following parameters for buildCurveMode: 1 (buildCurveWithMarketCap)
* 1. initialMarketCap
* 2. migrationMarketCap
*/
// "initialMarketCap": 20, // the market cap of the DBC token pool when the pool is created specified in terms of quoteMint (not in lamports)
// "migrationMarketCap": 600, // the market cap of the DBC token pool when the pool graduates specified in terms of quoteMint (not in lamports)
/* Only use the following parameters for buildCurveMode: 2 (buildCurveWithTwoSegments)
* 1. initialMarketCap
* 2. migrationMarketCap
* 3. percentageSupplyOnMigration
*/
// "initialMarketCap": 20, // the market cap of the DBC token pool when the pool is created specified in terms of quoteMint (not in lamports)
// "migrationMarketCap": 600, // the market cap of the DBC token pool when the pool graduates specified in terms of quoteMint (not in lamports)
// "percentageSupplyOnMigration": 20, // percentage of total token supply to be migrated
/* Only use the following parameters for buildCurveMode: 3 (buildCurveWithLiquidityWeights)
* 1. initialMarketCap
* 2. migrationMarketCap
* 3. liquidityWeights
*/
// "initialMarketCap": 20, // the market cap of the DBC token pool when the pool is created specified in terms of quoteMint (not in lamports)
// "migrationMarketCap": 600, // the market cap of the DBC token pool when the pool graduates specified in terms of quoteMint (not in lamports)
// "liquidityWeights": [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16], // a array of 16 liquidity weights for each liquidity segment in the curve
/* Only use the following parameters for buildCurveMode: 4 (buildCurveWithMidPrice)
* 1. initialMarketCap
* 2. migrationMarketCap
* 3. midPrice
* 4. percentageSupplyOnMigration
*/
// "initialMarketCap": 20, // the market cap of the DBC token pool when the pool is created specified in terms of quoteMint (not in lamports)
// "migrationMarketCap": 600, // the market cap of the DBC token pool when the pool graduates specified in terms of quoteMint (not in lamports)
// "midPrice": 0.001, // the mid-point price of the curve in terms of quoteMint
// "percentageSupplyOnMigration": 20, // percentage of total token supply to be migrated
/* Only use the following parameters for buildCurveMode: 5 (buildCurveWithCustomSqrtPrices)
* 1. prices - array of decimal prices in ascending order (at least 2 elements).
* 2. liquidityWeights - optional weights for each segment (length must be prices.length - 1)
*/
// "prices": [0.00001, 0.0005, 0.001, 0.01], // array of decimal prices (ascending order). First = starting price, Last = migration price
// "liquidityWeights": [1, 2, 3], // optional: weights for each segment. If omitted, liquidity is distributed evenly
/* Token Configuration */
"token": {
"totalTokenSupply": 1000000000, // total token supply (not in lamports)
"tokenBaseDecimal": 6, // token base decimal
"tokenQuoteDecimal": 9, // token quote decimal
"tokenType": 0, // 0 - SPL Token | 1 - Token 2022
"tokenAuthorityOption": 1, // 0 - CreatorUpdateAuthority | 1 - Immutable | 2 - PartnerUpdateAuthority | 3 - CreatorUpdateAndMintAuthority | 4 - PartnerUpdateAndMintAuthority (3 and 4 are only allowed for transfer hook configs)
"leftover": 0 // leftover tokens in the bonding curve (claimable once pool migrates)
},
/* Fee Configuration */
"fee": {
"baseFeeParams": {
"baseFeeMode": 0, // 0 - Fee Scheduler: Linear | 1 - Fee Scheduler: Exponential | 2 - Rate Limiter
"feeSchedulerParam": {
"startingFeeBps": 100, // starting fee (max 99% fee === 9900 bps)
"endingFeeBps": 100, // ending fee (minimum 0.01% fee === 1 bps)
"numberOfPeriod": 0, // number of period
"totalDuration": 0 // total duration (If activationType is 0 (slots), totalDuration = duration / 0.4 | If activationType is 1 (timestamp), totalDuration = duration)
}
/*
"baseFeeMode": 2, // 2 - Rate Limiter
"rateLimiterParam": {
"baseFeeBps": 200, // base fee (max 99% base fee === 9900 bps)
"feeIncrementBps": 200, // fee increment (max fee increment = 9900 bps - baseFeeBps)
"referenceAmount": 1, // reference amount (not in lamports)
"maxLimiterDuration": 0 // if activationType is 0 (slots), maxLimiterDuration = duration / 0.4, if activationType is 1 (timestamp), maxLimiterDuration = duration)
}
*/
},
"dynamicFeeEnabled": true, // If true, dynamic fee will add 20% of minimum base fee to the total fee.
"collectFeeMode": 0, // 0 - Quote Token | 1 - Output Token
"creatorTradingFeePercentage": 50, // Bonding curve trading fee sharing (0% to 100%) - 0% means all trading fees go to the partner
/* Pool Creation Fee
* Fee charged to token creators when they create a pool using this config.
* Partner claims 90% via claimPartnerPoolCreationFee(), Meteora claims 10%.
* Set to 0 for no fee, or between 0.001 SOL and 100 SOL.
*/
"poolCreationFee": 0, // Pool creation fee in SOL (e.g., 0.1 for 0.1 SOL)
"enableFirstSwapWithMinFee": false // If true, the first swap on the pool will use the minimum fee instead of the starting fee (useful for creator bundled buys)
},
/* Migration Configuration */
"migration": {
"migrationOption": 1, // 0 - Migrate to DAMM v1 | 1 - Migrate to DAMM v2
"migrationFeeOption": 3, // 0 - LP Fee 0.25% | 1 - LP Fee 0.3% | 2 - LP Fee 1% | 3 - LP Fee 2% | 4 - LP Fee 4% | 5 - LP Fee 6% | 6 - Customizable
"migrationFee": {
"feePercentage": 0, // Percentage of fee taken from migration quote threshold once pool migrates (0% to 50%)
"creatorFeePercentage": 0 // Percentage of the migrationFee.feePercentage claimable by creator (0% to 100%)
}
/* Migrated Pool Fee (DAMM v2 only)
* Configure migratedPoolFee when using migrationFeeOption: 6 (Customizable) or when configuring marketCapFeeSchedulerParams.
* Note: When marketCapFeeSchedulerParams is configured, the SDK will automatically set migrationFeeOption to Customizable (6).
*/
// "migratedPoolFee": {
// "collectFeeMode": 0, // 0 - Quote Token | 1 - Output Token | 2 - Compounding
// "dynamicFee": 0, // 0: Disabled, 1: Enabled
// "poolFeeBps": 100, // The pool fee in basis points. Minimum 10, Maximum 1000 bps. Required when marketCapFeeSchedulerParams is configured.
// "compoundingFeeBps": 5000, // Portion of trading fees compounded back into pool liquidity (0 to 10000 bps). Only for collectFeeMode: 2 (Compounding)
// "baseFeeMode": 3, // 3 - FeeMarketCapSchedulerLinear | 4 - FeeMarketCapSchedulerExponential (only for DAMM v2)
// "marketCapFeeSchedulerParams": {
// "endingBaseFeeBps": 50, // The ending (minimum) base fee in basis points
// "numberOfPeriod": 100, // The total number of fee reduction periods
// "priceMultiple": 1000, // The ratio of ending market cap over starting market cap, must be greater than 1
// "schedulerExpirationDuration": 86400 // The maximum duration (seconds) after which the scheduler expires and defaults to minimum fee
// }
// }
},
/* LP Distribution Configuration (must total 100%)
* IMPORTANT: At least 10% of LP must remain locked/vesting for at least 1 day post-migration.
*
* For DAMM v1: partnerPermanentLockedLiquidityPercentage + creatorPermanentLockedLiquidityPercentage >= 10%
*
* For DAMM v2: 3 options to achieve 10% locked/vesting:
* Option 1 (Permanent Only): Set creator + partner permanent locked percentages >= 10% (LP locked forever)
* Option 2 (Vesting Only): Use creator + partner vestingInfoParams with cliffDurationFromMigrationTime >= 86400 (1 day)
* Option 3 (Combination): Mix permanent + vesting to reach 10% (5% permanent + 5% vesting >= 1 day)
*/
"liquidityDistribution": {
"partnerLiquidityPercentage": 50, // Partner claimable LP (withdrawable LP once pool migrates)
"creatorLiquidityPercentage": 40, // Creator claimable LP (withdrawable LP once pool migrates)
"partnerPermanentLockedLiquidityPercentage": 5, // Partner locked LP (permanently locked LP once pool migrates) - counts toward 10% requirement
"creatorPermanentLockedLiquidityPercentage": 5 // Creator locked LP (permanently locked LP once pool migrates) - counts toward 10% requirement
/* LP Vesting (DAMM v2 only)
* Optional vesting schedule for partner/creator LP tokens after migration.
* Only applicable when migrationOption = 1 (DAMM v2).
* Note: At least 10% of LP must remain locked/vesting for at least 1 day post-migration.
*/
// "partnerLiquidityVestingInfoParams": {
// "vestingPercentage": 50, // % of non-permanent LP to vest (0-100)
// "bpsPerPeriod": 100, // BPS released per period (100 = 1%)
// "numberOfPeriods": 100, // Total vesting periods
// "cliffDurationFromMigrationTime": 86400, // Cliff delay in seconds (86400 = 1 day)
// "totalDuration": 2592000 // Total vesting duration in seconds (30 days)
// },
// "creatorLiquidityVestingInfoParams": {
// "vestingPercentage": 50,
// "bpsPerPeriod": 100,
// "numberOfPeriods": 100,
// "cliffDurationFromMigrationTime": 86400,
// "totalDuration": 2592000
// }
},
/* Locked Vesting Configuration */
"lockedVesting": {
"totalLockedVestingAmount": 0, // total locked vesting amount (not in lamports)
"numberOfVestingPeriod": 0, // number of vesting period
"cliffUnlockAmount": 0, // cliff unlock amount (not in lamports)
"totalVestingDuration": 0, // total vesting duration (in seconds)
"cliffDurationFromMigrationTime": 0 // cliff duration from migration time (in seconds)
},
"activationType": 1, // 0 - Slot | 1 - Timestamp
"leftoverReceiver": "YOUR_LEFTOVER_RECEIVER_ADDRESS", // leftover receiver address
"feeClaimer": "YOUR_FEE_CLAIMER_ADDRESS" // fee claimer address
/* Transfer Hook Launch (Token 2022 only)
* Set transferHookProgram to launch tokens whose base mint executes a transfer hook program on every transfer.
* Requires token.tokenType: 1 (Token 2022). The config is created with createConfigWithTransferHook and
* pools on it must be created with the same transferHookProgram (see dbcPool.transferHookProgram).
*/
// "transferHookProgram": "YOUR_TRANSFER_HOOK_PROGRAM_ADDRESS"
},
/* dbcPool is only used in the following actions:
* 1. dbc-create-pool
*/
"dbcPool": {
// "baseMintKeypairFilepath": "./mint-keypair.json", // optional base mint keypair file path
"creator": "YOUR_CREATOR_ADDRESS", // creator address
"name": "TOKEN_NAME", // token name
"symbol": "TOKEN_SYMBOL", // token symbol
// "transferHookProgram": "YOUR_TRANSFER_HOOK_PROGRAM_ADDRESS", // required when the target config was created with a transfer hook; must match the config's hook program
"metadata": {
// "uri": "https://gateway.irys.xyz/123456789", // if you already have a metadata URI created, you can specify it here
/* Only use the following parameters for createBaseToken if you don't have an existing metadata uri
* This will create an image uri and a new metadata uri and upload everything to Irys
*/
"image": "./data/image/test-token.jpg", // this can be a URL of the image address (e.g. https://example.com/token-image.png) or the image file path (e.g. ./data/image/test-token.jpg)
"description": "TOKEN_DESCRIPTION", // token description
"website": "https://example.com", // project website
"twitter": "https://x.com/yourproject", // twitter URL
"telegram": "https://t.me/yourproject" // telegram URL
}
},
/* dbcSwap is only used in the following actions:
* 1. dbc-swap (Buy or Sell)
*/
"dbcSwap": {
"amountIn": 1.03, // the amount of quoteMint or baseMint to be swapped
"slippageBps": 100, // slippage in bps
"swapBaseForQuote": false, // if true, swap base for quote | if false, swap quote for base
"referralTokenAccount": null // optional referral token account address
},
/* dbcTransferPoolCreator is only used in the following actions:
* 1. dbc-transfer-pool-creator
*/
"dbcTransferPoolCreator": {
"newCreator": "YOUR_NEW_CREATOR_ADDRESS" // new creator address
}
}
```
Creating a DBC token pool will automatically mint the token within the same `initialize_virtual_pool` instruction, so if you want to provide a vanity mint address, you will need to specify the `baseMintKeypairFilepath` in the `dbc_config.jsonc` file.
To launch a Token 2022 token with a transfer hook, set `token.tokenType` to `1` and `transferHookProgram` in `dbcConfig` (plus `dbcPool.transferHookProgram` when creating a pool on an existing transfer-hook config). The `dbc-swap` and `dbc-claim-trading-fee` actions detect transfer-hook pools automatically and use the transfer-hook-aware instructions. To learn how transfer-hook launches behave onchain, head to [DBC Transfer Hook Pools](/core-products/dbc/transfer-hook-pools).
The toolkit contains logic to make it easier for you to create the DBC token pool such as:
* Configuring your bonding curve shape based on your `buildCurveMode`.
* Launching the DBC config and token pool using the config immediately.
* Launching Token 2022 tokens with or without a transfer hook.
* Configuring your Anti-Sniping settings (such as Fee Scheduler or Rate Limiter) easily.
* Setting up liquidity vesting schedules for DAMM v2 migrations.
* Configuring market cap-based fee schedules for graduated pools.
* Enabling first swap with minimum fee for pool creators.
* Abstracting the math behind crafting the bonding curve.
After configuring your DBC token pool settings in `dbc_config.jsonc`, you can now create your token pool by running the following command.
*If you don't have a DBC config key, you can run the following command and the config key + pool
will be created together.*
```bash theme={"system"}
pnpm studio dbc-create-pool
```
*If you already have an existing DBC config key, you can provide it via the CLI with a `--config`
flag and run the following command.*
```bash theme={"system"}
pnpm studio dbc-create-pool --config
```
This will create your DBC curve config (if there is no config key) and token pool. You will also be able to see the token address and other relevant information in the console.
![]()
Voilà! You've successfully created your DBC token pool on Meteora. You can now see your token in action on [Jupiter Pro](https://jup.ag/pro), [Axiom](https://axiom.trade/discover) or [Photon](https://photon-sol.tinyastro.io/en/discover).
# DLMM Launch Pool
Source: https://docs.meteora.ag/invent/launch-pools/dlmm-launch-pool
Learn how to create a Meteora DLMM launch pool with configurable price bins, dynamic fees, activation controls, optional Alpha Vault, liquidity seeding, and limit orders.
This guide walks you through the steps to create a DLMM launch pool on Meteora. Whether you’re a seasoned developer or just starting out, this guide has got you covered to deploy liquidity and launch your project on Meteora.
# What You'll Achieve
By the end of this quicklaunch, you’ll have built a liquidity pool on Meteora by:
* Configuring your liquidity pool settings
* Interacting with our DLMM program
* Seeing your liquidity pool in action on Meteora
**Why Meteora?**
Meteora is a hyper optimized liquidity layer that ensures that your project's provided liquidity is secure, sustainable and composable for anyone to trade on. By following this guide, you'll be able to launch a concentrated liquidity pool with dynamic fees on Meteora in just a few quick and easy steps.
# Prerequisites
* Node.js >= 22.12.0
* pnpm >= 10.0.0
*If you don't have pnpm installed, you can install it by running the following command.*
```bash Terminal theme={"system"}
npm install -g pnpm
```
# Steps
Meteora Invent is a toolkit consisting of everything you need to invent innovative token launches on Meteora. Run the following command in your terminal to get started.
```bash Terminal theme={"system"}
git clone https://github.com/MeteoraAg/meteora-invent.git
```
Once you've cloned the repository, you'll have a new project directory with a meteora-invent folder. Run the following to install pnpm and the project dependencies.
```bash Terminal theme={"system"}
cd meteora-invent
pnpm install
```
![]()
In Meteora Invent we provide an optional command for you to run a local validator to test your pool before deploying it to devnet or mainnet. Run the following command in your code editor terminal to get started.
```bash Terminal theme={"system"}
pnpm studio start-test-validator
```
This will start a local validator on your machine which will be hosted on `http://localhost:8899`.
![]()
We provide an easy way to setup environment variables when getting started. Run the following command in your code editor terminal to get started.
```bash Terminal theme={"system"}
cp studio/.env.example studio/.env
```
This will copy the example environment variables file to your `.env` file. Configure the following variables:
* `PRIVATE_KEY` - Your private key for the wallet you will be using to deploy the pool.
Thereafter, you will need to run this command to generate a keypair from your wallet private key.
```bash Terminal theme={"system"}
pnpm studio generate-keypair
# For devnet (airdrops 5 SOL)
pnpm studio generate-keypair --network devnet --airdrop
# For localnet (airdrops 5 SOL)
# Ensure that you have already started the local validator with pnpm start-test-validator
pnpm studio generate-keypair --network localnet --airdrop
```
This will generate a `keypair.json` file in the `studio` directory which will be used for all actions in this guide.
![]()
Navigate to the `studio/config/dlmm_config.jsonc` file and configure your DLMM pool settings.
You can configure everything DLMM pool related in this file.
The comments in the file are to help you understand the different settings you can configure. Please ensure that you read through the comments while configuring your pool.
```jsonc dlmm_config.jsonc theme={"system"}
{
/* rpcUrl is required. You can switch between mainnet, devnet and localnet or use your own RPC URL. */
"rpcUrl": "https://api.devnet.solana.com", // mainnet: https://api.mainnet-beta.solana.com | devnet: https://api.devnet.solana.com | localnet: http://localhost:8899
/* dryRun is required. If true, transactions will be simulated and not executed. If false, transactions will be executed. */
"dryRun": true, // Set to false only after you understand what will happen
/* keypairFilePath is required and will be the payer + signer for all transactions */
"keypairFilePath": "./keypair.json",
/* computeUnitPriceMicroLamports is required and can be adjusted to fit your needs */
"computeUnitPriceMicroLamports": 100000,
/* quoteMint is required for the following actions:
* 1. dlmm-create-pool
* 2. dlmm-seed-liquidity-lfg
* 3. dlmm-seed-liquidity-single-bin
* 4. dlmm-set-pool-status
* SOL: So11111111111111111111111111111111111111112 | USDC: EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v | any other token address
*/
"quoteMint": "So11111111111111111111111111111111111111112",
/* If you have a baseMint already created, you can specify it in the cli command via --baseMint flag. If you don't have a baseMint, you can create a new one using createBaseToken.
* Either use --baseMint flag or createBaseToken, but not both.
*/
"createBaseToken": {
"supply": 1000000000, // total amount of base token to be minted
"decimals": 6, // decimals of the base token
// "tokenMintKeypairFilePath": "./mint-keypair.json", // path to token mint keypair if you have a specific keypair for the token mint. If not provided, a new keypair will be generated.
"name": "YOUR_TOKEN_NAME", // token name
"symbol": "YOUR_TOKEN_SYMBOL", // token symbol
"authorities": {
"mint": "YOUR_MINT_AUTHORITY_ADDRESS", // token mint authority address.
"freeze": "YOUR_FREEZE_AUTHORITY_ADDRESS", // token freeze authority address.
"update": "YOUR_UPDATE_AUTHORITY_ADDRESS" // token update authority address.
},
/* Optional Metaplex Token Metadata Properties
* Read more about the properties here: https://developers.metaplex.com/token-metadata
*/
"sellerFeeBasisPoints": 0, // Royalty fee in basis points (0-10000)
"creators": null, // Array of creator objects of the token (optional)
"collection": null, // Collection info (optional)
"uses": null, // Usage restrictions (optional)
"metadata": {
// "uri": "https://gateway.irys.xyz/123456789", // if you already have a metadata URI created, you can specify it here
/* Only use the following parameters for createBaseToken if you don't have an existing metadata uri
* This will create an image uri and a new metadata uri and upload everything to Irys
*/
"image": "./data/image/test-token.jpg", // this can be a URL of the image address (e.g. https://example.com/token-image.png) or the image file path (e.g. ./data/image/test-token.jpg)
"description": "YOUR_TOKEN_DESCRIPTION", // token description
"website": "https://example.com", // project website
"twitter": "https://x.com/yourproject", // twitter URL
"telegram": "https://t.me/yourproject" // telegram URL
}
},
/* dlmmConfig is only used in the following actions:
* 1. dlmm-create-pool
*/
"dlmmConfig": {
"binStep": 25, // Price increment/decrement percentage in basis points (400 = 4% price step between bins)
"feeBps": 1, // Trading fee in basis points (200 = 2% fee per swap)
"initialPrice": 1.333, // Initial price(in terms of quote/base price)
"activationType": 1, // 0 - Slot | 1 - Timestamp
"activationPoint": null, // Activation time of the pool depending on activationType (Calculate in slots if activationType is 0 (slots) | Calculate in seconds if activationType is 1 (timestamp))
"priceRounding": "up", // Price calculation rounding direction for bin ID conversion
"creatorPoolOnOffControl": true, // Pool creator permission to enable/disable trading for permissionless pools
"hasAlphaVault": false // If true, the alpha vault will be created after the pool is created
// "concreteFunctionType": 0, // 0 - LimitOrder | 1 - LiquidityMining (defaults to 0, only pools created with 0 accept limit orders)
// "collectFeeMode": 0 // 0 - InputOnly | 1 - OnlyY (defaults to 0)
},
/* lfgSeedLiquidity is only used in the following actions:
* 1. dlmm-seed-liquidity-lfg
* https://ilm.jup.ag/
*/
"lfgSeedLiquidity": {
"minPrice": 0.003393, // Minimum price boundary for liquidity distribution range
"maxPrice": 0.004393, // Maximum price boundary for liquidity distribution range
"curvature": 0.6, // Distribution curvature factor (1/k) controlling liquidity concentration (0-1, lower = more concentrated)
"seedAmount": "200000", // Total amount of liquidity to seed into the pool (in token units)
"operatorKeypairFilepath": "./keypair.json", // File path to operator's private key for signing seeding transactions
"positionOwner": "YOUR_POSITION_OWNER_ADDRESS", // Public key of the position owner who controls the liquidity
"feeOwner": "YOUR_FEE_OWNER_ADDRESS", // Public key entitled to claim trading fees from this position
"lockReleasePoint": 0, // Timestamp/slot when position becomes withdrawable (0 = immediately unlocked)
"seedTokenXToPositionOwner": true // Whether to send 1 lamport of token X to position owner as ownership proof
},
/* singleBinSeedLiquidity is only used in the following actions:
* 1. dlmm-seed-liquidity-single-bin
*/
"singleBinSeedLiquidity": {
"price": 1.333, // Exact price where liquidity will be concentrated in a single bin
"priceRounding": "up", // Price calculation rounding direction for bin ID conversion. "up" = round up, "down" = round down
"seedAmount": "750000000", // Amount of token X (base token) to seed into the single bin (in token units)
"operatorKeypairFilepath": "./keypair.json", // File path to operator's private key for signing seeding transactions
"positionOwner": "YOUR_POSITION_OWNER_ADDRESS", // Public key of the position owner who controls the liquidity
"feeOwner": "YOUR_FEE_OWNER_ADDRESS", // Public key entitled to claim trading fees from this position
"lockReleasePoint": 0, // Timestamp/slot when position becomes withdrawable (0 = immediately unlocked)
"seedTokenXToPositionOwner": true // Whether to send 1 lamport of token X to position owner as ownership proof
},
/* setDlmmPoolStatus is only used in the following actions:
* 1. dlmm-set-pool-status
*/
"setDlmmPoolStatus": {
"enabled": true // true = enable trading | false = disable trading
},
/* placeLimitOrder is only used in the following actions:
* 1. dlmm-place-limit-order (requires --poolAddress flag)
* The pool must have been created with the limit order function type (concreteFunctionType: 0).
* A limit order deposits into one or more bins (max 50) and fills as the market price crosses them.
*/
"placeLimitOrder": {
"side": "bid", // "ask" = sell the base token above the active bin | "bid" = buy with the quote token below the active bin
"bins": [
{
"price": 1.2, // price (in terms of quote/base price) for this portion of the order
"amount": 100 // amount in token units: base token amount for "ask" orders, quote token amount for "bid" orders
}
]
},
/* cancelLimitOrder is only used in the following actions:
* 1. dlmm-cancel-limit-order (requires --poolAddress flag, optional --limitOrder flag)
* Cancelling withdraws unfilled deposits, filled proceeds and earned fees, then closes the order account.
*/
"cancelLimitOrder": {
"cancelAll": false // when true and no --limitOrder flag is passed, cancels every open order on the pool
},
/* alphaVault is only used in the following actions:
* 1. dlmm-create-pool
* There are 2 types of alpha vault: First Come First Serve (FCFS) and Prorata.
*/
"alphaVault": {
"poolType": "dlmm", // DLMM = dlmm | DAMM v1 = dynamic | DAMM v2 = damm2
"alphaVaultType": "fcfs", // FCFS = fcfs | Prorata = prorata
/* Only use the following parameters for alphaVaultType: fcfs
* 1. maxDepositCap
* 2. individualDepositingCap
*/
"maxDepositCap": 10000, // Maximum total amount (in quote token) that can be deposited across all users in the vault
"individualDepositingCap": 1, // Maximum amount (in quote token) that each individual user can deposit
/* Only use the following parameters for alphaVaultType: prorata
* 1. maxBuyingCap
*/
// "maxBuyingCap": 10000, // Maximum total amount (in quote token) that can be bought across all users in the vault
"depositingPoint": 1755421200, // When users can start depositing depending on pool's activationType (Calculate in slots if activationType is 0 (slots) | Calculate in seconds if activationType is 1 (timestamp))
"startVestingPoint": 1755507600, // When token vesting begins and users can start claiming their vested tokens depending on pool's activationType (Calculate in slots if activationType is 0 (slots) | Calculate in seconds if activationType is 1 (timestamp))
"endVestingPoint": 1755507600, // When token vesting ends and all tokens become fully claimable depending on pool's activationType (Calculate in slots if activationType is 0 (slots) | Calculate in seconds if activationType is 1 (timestamp))
"escrowFee": 0, // Fee amount (in quote token) charged when creating a stake escrow account
"whitelistMode": "permissionless" // Whitelist mode: permissionless | permissioned_with_merkle_proof | permissioned_with_authority
/* Optional Configuration: whitelistFilePath
* Only use when whitelistMode is permissioned_with_merkle_proof or permissioned_with_authority
*/
// "whitelistFilepath": "./data/whitelist_wallet.csv", // Optional path to CSV file containing whitelisted wallet addresses and their deposit caps (format: wallet,deposit_cap)
/* Optional Configuration: merkleProofBaseUrl, chunkSize, kvProofFilepath, cloudflareKvProofUpload
* Only use when whitelistMode is permissioned_with_merkle_proof
*/
// "merkleProofBaseUrl": "https://example.workers.dev/", // Base URL endpoint where merkle proofs are stored and can be retrieved for whitelisted wallet verification
// "chunkSize": 1000, // Optional batch size for processing large whitelist files or merkle tree operations to avoid memory/performance issues
// "kvProofFilepath": "./data/kv_proofs", // Optional path to key-value file storing pre-computed merkle proofs for whitelisted addresses
// "cloudflareKvProofUpload": {
// "kvNamespaceId": "YOUR_KV_NAMESPACE_ID",
// "accountId": "YOUR_ACCOUNT_ID",
// "apiKey": "YOUR_API_KEY"
// }
}
}
```
The toolkit contains logic to make it easier for you to create the DLMM pool such as:
* Minting a new `baseMint` token or parsing in an existing `baseMint` token.
* Launching the DLMM pool immediately or at a certain `activationPoint` (in slots or timestamp depending on the `activationType`).
* Optional creation of an Alpha Vault with your DLMM launch pool.
After configuring your DLMM pool settings in `dlmm_config.jsonc`, you can now create your pool by running the following command.
*If you don't have a base mint, you can configure `createBaseToken` in the config file and run the
following command.*
```bash theme={"system"}
pnpm studio dlmm-create-pool
```
*If you already have a base mint created, you can provide it via the CLI with a `--baseMint` flag
and run the following command.*
```bash theme={"system"}
pnpm studio dlmm-create-pool --baseMint
```
This will create your pool and print the pool address and other relevant information to the console.
![]()
After creating your DLMM pool, you can now seed your pool with liquidity.
*If you want to seed your pool with liquidity using the LFG model, you can run the following command.*
Please take note that the `dlmm-seed-liquidity-lfg` command will only work when your DLMM launch pool is not activated yet. You can configure the pool activation time using the `activationPoint` parameter in the `dlmm_config.jsonc` file.
```bash Terminal theme={"system"}
pnpm studio dlmm-seed-liquidity-lfg --baseMint
```
This will seed your DLMM pool with liquidity based on the `curvature`, `minPrice` and `maxPrice` parameters that you have set in the `dlmm_config.jsonc` file.
If you want to learn how the liquidity curvature works, you can head to [https://ilm.jup.ag/](https://ilm.jup.ag/) to learn more.
![]()
*If you want to seed your pool with liquidity in a single bin, you can run the following command.*
Please take note that the `dlmm-seed-liquidity-single-bin` command will only work when your DLMM launch pool is not activated yet. You can configure the pool activation time using the `activationPoint` parameter in the `dlmm_config.jsonc` file.
```bash Terminal theme={"system"}
pnpm studio dlmm-seed-liquidity-single-bin --baseMint
```
This will seed your DLMM pool with liquidity in a single bin based on the `price` and `seedAmount` parameters that you have set in the `dlmm_config.jsonc` file.
![]()
DLMM pools created with the limit order function type (`concreteFunctionType: 0`, the default) support onchain limit orders. A limit order deposits tokens into one or more bins and fills automatically as the market price crosses them.
To learn how DLMM limit orders work under the hood, head to [DLMM Limit Order](/core-products/dlmm/limit-order).
*After configuring the `placeLimitOrder` settings in `dlmm_config.jsonc`, place an order with the following command.*
```bash theme={"system"}
pnpm studio dlmm-place-limit-order --poolAddress
```
This will place the order and print the limit order address to the console. Save the address if you want to cancel a specific order later.
*To inspect your open orders — per-bin fill status, fees earned, and withdrawable amounts — run the following command.*
```bash theme={"system"}
pnpm studio dlmm-get-limit-orders --poolAddress
```
*To cancel an order and withdraw unfilled deposits, filled proceeds, and earned fees, run the following command.*
```bash theme={"system"}
pnpm studio dlmm-cancel-limit-order --poolAddress --limitOrder
```
Omit the `--limitOrder` flag and set `cancelLimitOrder.cancelAll` to `true` in `dlmm_config.jsonc` to cancel every open order on the pool in one run.
Voilà! You've successfully created your DLMM pool on Meteora. You can now see your pool in action on Meteora either on Meteora's [mainnet](https://app.meteora.ag) or [devnet](https://devnet.meteora.ag) app.
# Overview
Source: https://docs.meteora.ag/invent/launch-pools/index
Choose a Meteora Invent launch-pool path for DBC, DLMM, DAMM v2, or DAMM v1 token liquidity.
Launch pools are the Meteora Invent workflows for creating token liquidity with a configuration file and CLI commands. Use this overview to choose between Dynamic Bonding Curve (DBC), DLMM, DAMM v2, and DAMM v1 launch paths before jumping into the step-by-step guide.
Launch a new token on a customizable bonding curve — with or without a Token 2022 transfer hook — then graduate the pool to DAMM v1 or DAMM v2 when the migration threshold is reached.
Create a DLMM pool with dynamic fees and precise liquidity concentration, then seed liquidity with an LFG curve or a single bin and place onchain limit orders.
Create a balanced or one-sided DAMM v2 constant-product pool with configurable fee schedules, dynamic fees, optional compounding, and position NFTs.
Create a DAMM v1 constant-product pool with optional liquidity locking and Stake2Earn workflows.
## Which launch pool should you use?
| Use case | Recommended pool | Why |
| ----------------------------------------------------------------------------------------------------- | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| You are launching a brand-new token and want users to buy along a curve before AMM graduation. | DBC | DBC creates the token pool first, handles bonding curve trading (including Token 2022 transfer-hook launches), and can migrate liquidity to DAMM v1 or DAMM v2. |
| You want concentrated liquidity with dynamic fees and custom liquidity seeding before trading starts. | DLMM | DLMM gives LPs discrete-bin liquidity concentration, volatility-aware fees, and onchain limit orders. |
| You want a modern constant-product AMM launch with flexible fee logic and NFT positions. | DAMM v2 | DAMM v2 supports balanced and one-sided pool creation, dynamic fees, fee schedulers, optional compounding, and more flexible liquidity management. |
| You need the legacy DAMM v1 flow, liquidity locks, or Stake2Earn. | DAMM v1 | DAMM v1 is the legacy constant-product AMM path with existing lock-liquidity and Stake2Earn tooling. |
## Shared setup
All launch-pool guides use the same Meteora Invent Studio setup:
```bash Terminal theme={"system"}
git clone https://github.com/MeteoraAg/meteora-invent.git
cd meteora-invent
pnpm install
cp studio/.env.example studio/.env
pnpm studio generate-keypair
```
Each guide then points you to its matching config file in `studio/config`:
* `dlmm_config.jsonc`
* `damm_v2_config.jsonc`
* `damm_v1_config.jsonc`
* `dbc_config.jsonc`
Start with `"dryRun": true` while validating your configuration. Set it to `false` only when you understand which transactions will be sent on-chain.
# Fun Launch
Source: https://docs.meteora.ag/invent/scaffold/fun-launch
Build a token launchpad scaffold powered by Meteora's Dynamic Bonding Curve program.
This guide walks you through the steps to create a launchpad platform for launching tokens with Meteora's Dynamic Bonding Curve Program.
# Features
Built-in integration for Meteora's DBC program to create token pools with your DBC config key. You can configure your DBC config key on [launch.meteora.ag](https://launch.meteora.ag) and get started within minutes.
Productin-grade search functionalities and real-time data from websocket APIs. Provide up-to-date information including token price, volume and holder count on your launchpad platform without worrying about the nitty-gritty details of indexing data.
Ready-to-use trading interface with all the features you need for users to trade your tokens without leaving the platform. Comprises of with Trading View's charts and open source Jupiter APIs that includes volume analysis and trading marks.
# Tech Stack
* Next.js 15
* React 19
* TypeScript
* Tailwind CSS (with light and dark theme support)
* Solana Web3.js
* Dynamic Bonding Curve SDK
* Cloudflare R2 for storage (via `@aws-sdk/client-s3`)
# Prerequisites
* Node.js >= 22.12.0
* pnpm >= 10.0.0
## Setup
Meteora Invent is a toolkit consisting of everything you need to invent innovative token launches on Meteora. Run the following command in your terminal to get started.
```bash Terminal theme={"system"}
git clone https://github.com/MeteoraAg/meteora-invent.git
```
Once you've cloned the repository, you'll have a new project directory with a meteora-invent folder. Run the following to install pnpm and the project dependencies.
```bash Terminal theme={"system"}
cd meteora-invent
pnpm install
```
![]()
Copy the `.env.example` file to `.env` and configure the environment variables.
```bash theme={"system"}
cp scaffolds/fun-launch/.env.example scaffolds/fun-launch/.env
```
```env theme={"system"}
# Cloudflare R2 Storage
R2_ACCESS_KEY_ID=your_r2_access_key_id
R2_SECRET_ACCESS_KEY=your_r2_secret_access_key
R2_ACCOUNT_ID=your_r2_account_id
R2_BUCKET=your_r2_bucket_name
# Solana RPC URL
RPC_URL=your_rpc_url
# Pool Configuration
POOL_CONFIG_KEY=your_pool_config_key
```
**Getting R2 Credentials**
1. Go to [Cloudflare Dashboard](https://dash.cloudflare.com)
2. Navigate to R2
3. Create a new bucket or select an existing one
4. Go to "Manage R2 API Tokens"
5. Create a new API token with the following permissions:
* Account R2 Storage: Edit
* Bucket: Your bucket name
6. Copy the Access Key ID and Secret Access Key
7. Your Account ID can be found in the Cloudflare dashboard URL or in the Account Home page
**Getting RPC URL**
You can get your RPC URL from any 3rd party provider like [Triton](https://triton.one/) or [Helius](https://www.helius.dev).
**Getting Pool Config Key**
You can get your pool config key from [Meteora Launch](https://launch.meteora.ag) or create a DBC config with the [Meteora Invent actions](/invent/actions#dbc).
```bash theme={"system"}
pnpm --filter @meteora-invent/scaffold/fun-launch dev
```
![]()
```bash theme={"system"}
pnpm --filter @meteora-invent/scaffold/fun-launch build
```
![]()
# DAMM v1 Fee and APY Calculation
Source: https://docs.meteora.ag/legacy-products/damm-v1/damm-v1-fee-and-apy-calculation
How DAMM v1 trading fees, protocol fees, base APY, fee-over-TVL, Dynamic Vault yield, and farm APR are interpreted for LPs.
DAMM v1 LP returns can come from several sources, so APY needs to be read carefully. A pool may show fee performance, base APY, Dynamic Vault yield, and farming incentives. These are related, but they are not the same thing.
This page explains how to think about the metrics at a product level.
## Total trading fee
Every swap can charge a trading fee. The trading fee is calculated from the input amount:
```math theme={"system"}
\text{trading fee} = \text{input amount} \times \frac{\text{trade fee numerator}}{\text{trade fee denominator}}
```
The LP-relevant portion of the fee remains with the pool and increases the value backing LP tokens. In practice, LPs do not need to manually collect this fee from a DAMM v1 LP-token pool. The fee is reflected in pool share value.
## Protocol fee
DAMM v1 can also charge a protocol fee:
```math theme={"system"}
\text{protocol fee} = \text{total trading fee} \times \frac{\text{protocol fee numerator}}{\text{protocol fee denominator}}
```
The protocol fee is separate from the LP value. Depending on pool configuration, protocol, host, and partner fee settings can determine how swap fees are split.
### Constant Product pools
* **Standard Pools:** **20%** Protocol Fee, **80%** LP Fee (0.25% trade fee)
* **Launch Pools:** **20%** Protocol Fee, **80%** LP Fee (customizable trade fee)
### Stable Swap pools
* **0%** Protocol Fee, **100%** LP Fee (0.01% trade fee)
### Swaps
Swap hosts can include a host fee account in the swap transaction to receive **20%** of the protocol fee.
For LPs, the key question is: what portion of the trading fee remains in the pool and increases LP token value?
## Host and partner fee routing
DAMM v1 also has fee routing logic for partner fee arrangements. A configured partner can accrue up to **50%** of protocol-side fees after any host fee routing.
This does not change the core LP concept: LPs evaluate the net value accruing to the pool after applicable fee splits.
## Base APY
Base APY measures how much the value of a pool share has increased over a period, annualized.
```math theme={"system"}
\text{base APY} = \left(\left(\frac{\text{Virtual Price}_{2}}{\text{Virtual Price}_{1}}\right)^{\frac{\text{1 year}}{\text{timeframe}}} - 1\right) \times 100
```
Where:
* `Virtual Price 1` is the older virtual price.
* `Virtual Price 2` is the newer virtual price.
* `timeframe` is the measurement period.
Virtual price is:
```math theme={"system"}
\text{virtual price} = \frac{D}{\text{LP token supply}}
```
`D` is the curve invariant computed from the pool's token amounts after converting vault LP shares into underlying token balances. For constant-product pools, `D = sqrt(x * y)`. For stable pools, `D` comes from the stable-swap invariant.
Virtual price can rise because of:
* Swap fees.
* Eligible Dynamic Vault yield.
* Any value that increases pool assets relative to LP token supply.
Base APY is backward-looking. It annualizes what happened during a measurement window. It is not a promise that the same return will continue.
## 365-day fee over TVL
This metric annualizes recent swap fee generation against pool liquidity:
```math theme={"system"}
\text{365d fee / TVL} = \frac{\text{24h fees} \times 365}{\text{pool TVL}}
```
Where:
* `24h fees` is the fee value generated over the last 24 hours.
* `pool TVL` is the current value of liquidity in the pool.
This is useful for comparing how efficiently different pools are generating trading fees. A smaller pool with heavy volume may show a high fee-over-TVL number. A large pool with quiet volume may show a lower number.
## Dynamic Vault yield
Some DAMM v1 pools can earn additional yield through Dynamic Vaults. This yield comes from eligible idle assets being allocated to supported external strategies.
Vault yield can contribute to base APY because it can increase the value backing the pool's vault LP positions. The important distinction:
* **Trading fee yield** comes from swaps.
* **Vault yield** comes from eligible vault strategies.
* **Farm APR** comes from reward token emissions.
These can all appear in the LP return profile, but each has different drivers and risks.
## External farm APR
External liquidity mining APR estimates the annualized value of farm rewards relative to farm TVL:
```math theme={"system"}
\text{LM APR} = \left(\left(1 + \frac{\text{farm reward per day}}{\text{farm TVL}}\right)^{365} - 1\right) \times 100
```
Where:
* `farm reward per day` is the daily value of reward emissions.
* `farm TVL` is the value of LP tokens staked in the farm.
Farm APR is only relevant if LPs stake LP tokens in the separate farm program. LP tokens sitting unstaked in a wallet still own pool liquidity, but they do not earn farm rewards from that farm.
## Reading a DAMM v1 pool return stack
When comparing DAMM v1 pools, break the displayed return into layers:
### 1. Organic trading demand
Does the pair have real swap volume? High trading volume can generate sustainable fees.
### 2. Pool depth
How much TVL is competing for those fees? More TVL can reduce slippage, but it also spreads fee revenue across more LP capital.
### 3. Vault yield eligibility
Does one side or both sides of the pool connect to Dynamic Vault yield? If yes, what are the supported assets and risk assumptions?
### 4. Farm incentives
Is there an active farm? What reward token is emitted? How long does it last? How much LP liquidity is staked?
### 5. Asset risk
A high displayed APY does not offset all asset risk. LPs still face price movement, depeg risk, smart contract risk, and incentive changes.
## Practical example
A DAMM v1 stablecoin pool might have:
* Low but steady trading fees.
* Eligible Dynamic Vault yield on one or both stable assets.
* A temporary partner farm.
The combined displayed return may look attractive, but each component behaves differently. Trading fees depend on volume. Vault yield depends on external strategy rates and risk. Farm APR depends on reward funding and how many LP tokens are staked.
A healthy LP decision looks at all three instead of chasing the largest number on the screen.
# DAMM v1 Formulas
Source: https://docs.meteora.ag/legacy-products/damm-v1/damm-v1-formulas
Understand the product math behind DAMM v1 constant-product pools, stable pools, fees, LP shares, virtual price, vault yield, and farming rewards.
DAMM v1 is a full-range AMM with two main curve designs: constant-product pools for volatile assets, and stable-swap pools for assets that should trade close together. The formulas below explain how the product behaves without turning this page into an integration guide.
## Constant-product pools
The basic volatile-pool formula is:
```math theme={"system"}
x \times y = k
```
Where:
* `x` is the amount of token A in the pool.
* `y` is the amount of token B in the pool.
* `k` is the pool invariant.
When a trader adds token A and removes token B, `x` rises and `y` falls. The pool reprices the trade so the relationship between both reserves stays balanced.
For users, this means:
* Larger pools usually create lower price impact.
* Larger trades move price more than smaller trades.
* The pool supports a continuous price range from very low to very high prices.
## Constant-product swap output
Before fees, a simplified output calculation looks like this:
```math theme={"system"}
\text{new source reserve} = \text{source reserve} + \text{input amount}
```
```math theme={"system"}
\text{new destination reserve} = \frac{k}{\text{new source reserve}}
```
```math theme={"system"}
\text{output amount} = \text{destination reserve} - \text{new destination reserve}
```
DAMM v1 uses safe on-chain integer math, so tiny rounding differences can happen at the smallest token unit. Product-wise, the idea is straightforward: every buy makes the bought token scarcer in the pool, which raises its price for the next trade.
## Stable pools
Stable pools are designed for assets that should trade near a target relationship, such as USDC/USDT or SOL/LST markets. Instead of using only `x × y = k`, DAMM v1 stable pools use a StableSwap-style invariant with an amplification factor.
A simplified StableSwap invariant can be represented as:
```math theme={"system"}
A \cdot n^n \cdot \sum x_i + D = A \cdot n^n \cdot D + \frac{D^{n+1}}{n^n \cdot \prod x_i}
```
Where:
* `A` is the amplification factor.
* `n` is the number of assets in the pool. DAMM v1 pools are two-token pools.
* `x_i` represents normalized token balances.
* `D` is the stable pool invariant.
In plain English: amplification makes the pool behave as if it has deeper liquidity near the target price. That helps reduce slippage when both assets are close to their expected relationship.
A higher amplification factor concentrates more liquidity near the target relationship, but it also makes the pool less forgiving when the assets move far away from that relationship.
## Token normalization
Stable pools normalize token amounts before applying the curve. This matters when two tokens have different decimals.
```math theme={"system"}
\text{normalized amount} = \text{raw amount} \times \text{token multiplier}
```
The goal is to compare both assets on a consistent precision scale before calculating swaps, deposits, and withdrawals.
## LST depeg adjustment
For supported LST pools, DAMM v1 can account for the changing value of the staking token relative to SOL. The program stores and updates a base virtual price for the LST side of the pool.
Conceptually:
```math theme={"system"}
\text{pegged LST amount} = \text{LST amount} \times \text{LST virtual price}
```
This lets the pool reason about an LST's value instead of treating one LST as always equal to one SOL. That is important because LSTs generally increase in SOL terms as staking rewards accrue.
## LP share ownership
LP tokens represent a share of the pool. A simplified LP ownership formula is:
```math theme={"system"}
\text{LP ownership share} = \frac{\text{LP tokens held}}{\text{total LP token supply}}
```
The value of that share depends on the pool's underlying token value:
```math theme={"system"}
\text{LP share value} = \text{ownership share} \times \text{total pool value}
```
DAMM v1 pools route token balances through Dynamic Vaults. That means the pool often measures its token A and token B totals by converting vault LP balances back into underlying token amounts.
## Virtual price
Virtual price is a useful way to understand whether a pool share is becoming more valuable over time.
```math theme={"system"}
\text{virtual price} = \frac{D}{\text{LP token supply}}
```
`D` is the curve invariant computed from the pool's vault-backed token amounts. For constant-product pools, DAMM v1 uses `sqrt(x * y)`. For stable pools, it uses the StableSwap invariant.
Virtual price can rise when:
* Swaps generate fees that remain in the pool.
* Eligible vault assets earn yield.
* Rewards or yield increase the underlying value backing pool shares.
For LPs, virtual price is the bridge between pool activity and share value.
## Trading fees
DAMM v1 charges trading fees on swaps. A simplified fee calculation is:
```math theme={"system"}
\text{trading fee} = \text{input amount} \times \frac{\text{trade fee numerator}}{\text{trade fee denominator}}
```
DAMM v1 also supports protocol fees:
```math theme={"system"}
\text{protocol fee} = \text{trading fee} \times \frac{\text{protocol fee numerator}}{\text{protocol fee denominator}}
```
The protocol fee is computed from the total trading fee. The remaining fee value benefits LPs because it stays with the pool and increases the value backing LP tokens.
DAMM v1's fee math has a minimum-fee behavior for non-zero trades when the calculated fee would otherwise round down to zero. This prevents tiny trades from bypassing fees entirely.
## Base APY from virtual price
DAMM v1 APY can be estimated from virtual price growth over a time window:
```math theme={"system"}
\text{base APY} = \left(\left(\frac{\text{Virtual Price}_{2}}{\text{Virtual Price}_{1}}\right)^{\frac{\text{1 year}}{\text{timeframe}}} - 1\right) \times 100
```
Where:
* `Virtual Price 1` is the earlier virtual price.
* `Virtual Price 2` is the later virtual price.
* `timeframe` is the time between the two measurements.
This base APY can include the effect of trading fees and eligible vault yield because both can increase the value backing each LP token.
## 365-day fee over TVL
A simple fee efficiency metric annualizes recent swap fees against pool liquidity:
```math theme={"system"}
\text{365d fee / TVL} = \frac{\text{24h fees} \times 365}{\text{pool TVL}}
```
This helps LPs compare how much fee activity a pool is generating relative to the amount of liquidity supplied.
## External farm rewards
External DAMM v1 farms distribute reward tokens to staked LP tokens over time. Farming is a separate reward layer around the AMM LP token, not core swap logic inside the AMM program. A simplified reward rate is:
```math theme={"system"}
\text{reward rate} = \frac{\text{funded reward amount}}{\text{reward duration}}
```
Reward per staked LP token grows as time passes:
```math theme={"system"}
\text{reward per token} = \text{previous reward per token} + \frac{\text{elapsed time} \times \text{reward rate}}{\text{total staked LP tokens}}
```
A user's pending reward is based on their staked balance:
```math theme={"system"}
\text{user reward} = \text{staked LP tokens} \times \text{reward per token since last update}
```
DAMM v1 farm integrations have historically supported up to two reward tokens. Check the farm program and campaign configuration for exact reward-accounting behavior.
## LM APR
Liquidity mining APR estimates the annualized value of farm emissions relative to farm TVL:
```math theme={"system"}
\text{LM APR} = \left(\left(1 + \frac{\text{farm reward per day}}{\text{farm TVL}}\right)^{365} - 1\right) \times 100
```
Where:
* `farm reward per day` is the daily token emission value in USD.
* `farm TVL` is the value of LP tokens staked in the farm.
* `pool TVL` is the value of all token A and token B liquidity in the pool.
# Dynamic Vault Yield
Source: https://docs.meteora.ag/legacy-products/damm-v1/dynamic-vaults-yield
Learn how DAMM v1 pools can earn additional yield by routing eligible idle liquidity through Meteora Dynamic Vaults.
One of DAMM v1's defining features is that pool liquidity can sit on top of Dynamic Vaults. Instead of leaving every token idle inside a standard pool account, eligible DAMM v1 assets can be connected to vaults that allocate unused liquidity into supported external strategies.
For LPs, this creates an additional return layer. A DAMM v1 pool can earn swap fees from trading activity while eligible idle assets may also earn lending yield through the Dynamic Vault layer.
## What Dynamic Vaults do
Dynamic Vaults are Meteora's capital allocation layer. A vault holds a supported token, keeps part of the liquidity available in reserve, and can allocate part of the liquidity into approved strategies.
A vault tracks:
* The token it supports.
* The total amount of that token controlled by the vault.
* The reserve token account available for immediate liquidity.
* Approved strategies that can receive allocations.
* Vault LP supply, which represents shares of the vault.
* Locked profit accounting, which smooths newly reported gains over time.
DAMM v1 pools use vault LP positions to represent the pool's ownership of each token-side vault.
## How this connects to DAMM v1
A DAMM v1 pool has two token sides. Each side points to a Dynamic Vault. When the pool needs to understand its balances, it converts its vault LP holdings back into the current underlying token amounts.
That means the AMM can continue to price swaps, deposits, withdrawals, and LP share value while the vault layer manages eligible idle liquidity behind the scenes.
In DAMM v1 source, the pool stores vault accounts and vault LP token accounts for both token sides. This is the core reason DAMM v1 is described as an AMM built on Dynamic Vault infrastructure.
## Why this creates additional yield
In a normal AMM, unused liquidity simply waits for the next trade. In a DAMM v1 pool with supported vault assets, a portion of idle liquidity can be allocated to external yield sources.
The return stack becomes:
1. Traders pay swap fees.
2. LP token value can rise as fees remain in the pool.
3. Eligible vault assets may earn strategy yield.
4. Vault yield can increase the value backing the pool's vault LP positions.
5. LPs benefit through pool share value and virtual price growth.
This helps reduce reliance on constant liquidity mining emissions. A pool can be more attractive to LPs even when trading volume is uneven or reward campaigns are not active.
## Reserve liquidity and withdrawals
Dynamic Vaults do not send every token into a strategy. A portion of liquidity can remain in the vault reserve to support normal pool operations.
This reserve matters because DAMM v1 pools still need liquidity for:
* Swaps.
* Balanced withdrawals.
* Single-sided withdrawals where supported.
* LP operations and pool accounting.
If a very large withdrawal exceeds immediately available reserve liquidity for a vault-backed asset, the user experience may require smaller withdrawals or operational support while liquidity is moved back from strategies.
Vault-backed yield improves capital productivity, but it is not the same as instant idle cash. Strategy allocations can affect how much liquidity is immediately available in the reserve at a given moment.
## Locked profit and smoother share value
Dynamic Vaults use locked profit accounting. When a vault reports gains, those gains are not necessarily made fully available to new deposits immediately. Instead, profit can unlock over time.
The product reason is fairness. Without smoothing, someone could deposit immediately before a gain is reported and withdraw after capturing value they did not help earn. Locked profit helps reduce that kind of timing advantage.
For LPs, this means vault yield may show up as gradual share value improvement rather than an instant jump.
## Where LPs see the impact
DAMM v1 LPs typically experience vault yield through pool performance metrics, such as virtual price growth or displayed yield metrics. The exact UI label can vary, but the product idea is consistent: vault yield increases the underlying value backing pool shares when strategies perform positively.
A simplified virtual price view is:
```math theme={"system"}
\text{virtual price} = \frac{\text{total pool value}}{\text{LP token supply}}
```
If pool value rises from fees or vault yield while LP supply stays the same, virtual price increases.
## Eligible assets
Dynamic Vault yield depends on vault support. Historically, DAMM v1 vault yield has been most relevant for major liquid assets such as USDC, USDT, and SOL, where external lending or liquidity strategies exist.
Not every token pair can earn vault yield. A long-tail token may still use DAMM v1's AMM design, but the additional vault yield layer depends on whether the token side has a supported Dynamic Vault strategy.
## Risk considerations
Dynamic Vault yield introduces additional risk considerations beyond basic AMM liquidity:
* External strategy risk.
* Lending market risk.
* Smart contract risk.
* Liquidity availability risk.
* Operational and keeper risk.
* Changes in external yield rates.
Meteora's vault design includes controls such as approved strategy lists, reserve management, operators, and rebalancing, but LPs should still treat vault yield as a DeFi strategy exposure.
## How to think about vault yield
Dynamic Vault yield is best understood as a baseline capital productivity layer. It does not replace trading volume, and it does not replace farms. Instead, it makes DAMM v1 pools more durable by giving eligible idle assets something productive to do between trades.
For a strong DAMM v1 pool, the ideal return mix is:
* **Organic fees** from useful trading volume.
* **Vault yield** from eligible idle assets.
* **Targeted farms** for strategic growth periods.
# DAMM v1 Implementation and Limits
Source: https://docs.meteora.ag/legacy-products/damm-v1/implementation-and-limits
Source-backed DAMM v1 implementation details, account model, fees, curve limits, activation rules, liquidity operations, depeg support, and lock behavior.
This page summarizes the DAMM v1 behavior that is enforced by the on-chain AMM program. Use it when you need exact product limits rather than a high-level explanation.
DAMM v1 mainnet program: `Eo7WjKq67rjJQSZxS6z3YkapzY3eMj6Xy8X5EQVn5UaB`.
## Pool account model
A DAMM v1 pool is a two-token SPL Token pool. The pool account stores:
| Field group | What it controls |
| --------------------- | ------------------------------------------------------------------ |
| LP mint | The fungible LP token mint for pool ownership |
| Token mints | `token_a_mint` and `token_b_mint` |
| Vault accounts | One Dynamic Vault for token A and one Dynamic Vault for token B |
| Vault LP accounts | The pool's vault-share accounts for both token-side vaults |
| Protocol fee accounts | Token A and token B accounts that receive protocol-side fees |
| Pool fees | Trade fee and protocol-trade-fee fractions |
| Curve type | Constant-product or stable-swap parameters |
| Pool type | Permissioned or permissionless |
| Bootstrapping | Optional activation point, activation type, and whitelisted vault |
| Partner info | Optional partner authority and partner share of protocol-side fees |
| Lock accounting | Total locked LP token amount |
The AMM does not price from raw token account balances alone. It converts the pool's vault LP holdings back into underlying token amounts, then uses those amounts for swaps, LP minting, withdrawals, and virtual price.
## Supported curves
DAMM v1 supports two curve families:
| Curve | Source behavior |
| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| Constant product | Uses `x * y = k`; pool invariant `D` is represented as `sqrt(x * y)` for LP minting and virtual price. |
| Stable swap | Uses Saber StableSwap math with token multipliers for decimal normalization, optional depeg handling, and an amplification coefficient. |
Constant-product pools do not support imbalanced deposits or single-sided withdrawals in the curve implementation. Stable pools support imbalanced deposits and single-sided withdrawals because those operations are implemented through the stable-swap math.
## Permissionless constraints
Permissionless pool creation is intentionally constrained:
| Item | Limit |
| ------------------------ | -------------------------------------------------------------------------------------- |
| Stable AMP | Permissionless stable pools must use `amp = 100`. |
| Maximum AMP | Stable-pool AMP is capped at `10000`. |
| AMP updates | Permissioned stable-pool AMP updates must wait at least `600` seconds between changes. |
| Stable depeg | Permissionless stable pools cannot use depeg mode. |
| Stable token multipliers | Must match the token mint decimals. |
| Initial stable liquidity | Initial amounts must be equal after token normalization and depeg adjustment. |
| Initial deposits | Token A and token B amounts must both be non-zero. |
Specialized stable pools, including depeg-aware LST pools, require permissioned pool setup.
## Fee settings
DAMM v1 fee fractions use a denominator of `100000`.
| Pool type | Default trade fee | Default protocol share |
| ---------------- | -----------------------: | ----------------------------------------: |
| Constant product | `250 / 100000` = `0.25%` | `20000 / 100000` = `20%` of the trade fee |
| Stable swap | `10 / 100000` = `0.01%` | `0%` |
The protocol fee is calculated from the total trade fee, not directly from the full input amount. The remaining trade fee stays in the pool and benefits LP token value.
For non-zero fee settings, the fee helper returns a minimum fee of one token unit when integer division would otherwise round the fee to zero.
## Fee tiers and updates
Permissionless fee-tier creation only allows specific trade fee basis points:
| Curve | Allowed trade fee bps |
| ---------------- | ----------------------------- |
| Constant product | `25`, `100`, `400`, `600` bps |
| Stable swap | `1`, `4`, `10`, `100` bps |
Customizable permissionless constant-product pools use a different launch-oriented fee path:
| Item | Limit |
| --------------- | ------------------------------------------------ |
| Trade fee range | `0.25%` to `15%` |
| Step size | Must be divisible by `0.05%` |
| Protocol share | Uses the constant-product default protocol share |
Pool fees can also be updated after creation. The configured fee-update authority can only decrease the trade fee, cannot change the protocol fee, and cannot reduce below `0.25%`. The admin path can set fees and partner fee settings after validating fee fractions and partner limits.
## Host and partner fees
If a swap includes a host fee account in the expected remaining-account position, the program routes `20%` of the protocol fee to that host account and leaves the rest as protocol fee.
Partner fees are tracked separately in pool state. When a partner is configured, the partner can accrue up to `50%` of protocol-side fees. Partner accounting only applies to protocol fees that remain after host fee routing.
## Depeg-aware LST support
Depeg mode exists only on stable pools. The program supports:
| Depeg type | Source of virtual price |
| -------------- | ----------------------- |
| Marinade | mSOL state account |
| Lido/Solido | stSOL state account |
| SPL stake pool | SPL stake pool account |
For a depeg pool, token A must be native SOL and token B is the staking or interest-bearing token. The pool multiplies token A balances by `1_000_000` and token B balances by the cached base virtual price before stable-swap calculations.
The cached base virtual price is refreshed only when more than `10 minutes` have passed since the previous cache update. SPL stake-pool depeg pools store the stake account in pool state and validate the same account on later updates.
## Activation rules
Some permissionless constant-product pools can be created with an activation point. Activation can be based on either:
| Activation type | Meaning |
| --------------- | -------------------------- |
| `0` | Slot-based activation |
| `1` | Timestamp-based activation |
Before activation, normal swaps are disabled. If a whitelisted vault is configured, that vault can buy during the pre-activation window. Balanced withdrawals are also gated until activation.
Mainnet timing limits include:
| Item | Slot mode | Timestamp mode |
| ----------------------- | ----------------: | ------------------: |
| Buffer | `9000` slots | `3600` seconds |
| Max activation duration | `6,696,000` slots | `2,678,400` seconds |
| Last-join buffer | About `5` minutes | `5` minutes |
## Liquidity operations
| Operation | Source-backed behavior |
| ------------------- | --------------------------------------------------------------------------------------------------------- |
| Balanced add | Requires pool enabled; mints a requested LP token amount and computes max token A/B needed. |
| Imbalanced add | Requires pool enabled; implemented by stable-swap curve math. Constant-product curves return unsupported. |
| Balanced remove | Can run even when the pool is disabled, but activation gates can still apply. |
| Single-sided remove | Requires pool enabled and stable-swap support; protocol trading fee is not charged on this operation. |
| Bootstrap liquidity | Can initialize a depleted pool when LP supply is zero and both token amounts are non-zero. |
The code deliberately rounds some share calculations against the user to account for vault-share precision loss. Integrations should use slippage bounds and quoted amounts rather than assuming exact proportional arithmetic.
## Liquidity locks
Liquidity locks escrow DAMM v1 LP tokens and increase `total_locked_lp` on the pool. The underlying assets remain in the AMM and its connected vaults.
For constant-product pools, the lock escrow can accrue claimable fee value when virtual price increases. Claiming those fees burns a portion of escrowed LP tokens and withdraws the corresponding underlying token amounts. The `claim_fee` path rejects non-constant-product pools.
Locks restrict control of the LP tokens; they do not remove price risk, vault risk, or smart-contract risk.
# DAMM v1 Liquidity Locks
Source: https://docs.meteora.ag/legacy-products/damm-v1/liquidity-locks
Understand how DAMM v1 liquidity locks let LP tokens be locked while the underlying liquidity remains in the pool.
DAMM v1 supports liquidity locks. A liquidity lock moves LP tokens into an escrow account so the liquidity remains committed to the pool instead of being freely withdrawable by the owner.
For projects and communities, locked liquidity is a trust signal. It shows that a portion of the pool's liquidity is intended to stay in place, supporting trading depth and reducing concerns that liquidity will be suddenly removed.
## What gets locked?
In DAMM v1, LP tokens represent ownership of the pool. Locking liquidity means locking those LP tokens.
The underlying pool assets remain inside the DAMM v1 pool and its connected vault accounts. Traders can still swap against the liquidity. The pool can still earn fees. Eligible assets can still participate in Dynamic Vault behavior where supported.
The lock is on the owner's ability to freely redeem those LP tokens for underlying assets.
## Why projects lock liquidity
Projects use locked liquidity to send a clear market signal:
* The team is committing pool depth for the long term.
* Traders can see that liquidity is less likely to disappear suddenly.
* The community has more confidence in the pool's durability.
* Launch partners can verify that a liquidity commitment exists.
This is especially important for long-tail tokens and community markets where trust is part of the product experience.
## What LPs still earn
Locked LP tokens still represent pool ownership. Because the liquidity remains in the pool, it can continue to participate in the pool's economics.
Depending on pool configuration, locked liquidity can remain exposed to:
* Trading fee value accrual.
* Dynamic Vault yield on eligible assets.
* Pool value changes caused by price movement.
* Any other pool-level effects that change LP share value.
A lock does not make liquidity risk-free. It changes withdrawal control. The locked LP position still has exposure to the underlying pool assets and DeFi risks.
For constant-product pools, the AMM program can accrue claimable fee value for a lock when virtual price increases. Claiming that value burns a portion of escrowed LP tokens and withdraws the corresponding underlying token amounts. The claim-fee path rejects stable-swap pools.
## How the lock works conceptually
The LP deposits assets into a DAMM v1 pool and receives LP tokens.
The lock action transfers LP tokens into a lock escrow account and records the locked amount.
DAMM v1 tracks total locked LP tokens for the pool, making locked liquidity visible at the pool level.
The underlying liquidity continues supporting swaps because the pool assets were not withdrawn.
## Locked liquidity vs farmed liquidity
Locked liquidity and farmed liquidity are different.
* **Locked liquidity** is about commitment. LP tokens are escrowed to restrict withdrawal.
* **Farmed liquidity** is about incentives. LP tokens are staked to earn reward emissions.
A pool can have both, but they serve different product goals. Locking builds confidence. Farming attracts or retains liquidity through rewards.
## What locks do not solve
Liquidity locks are useful, but they are not a complete safety guarantee.
They do not remove:
* Token price risk.
* Smart contract risk.
* Dynamic Vault strategy risk.
* Depeg risk for stable or LST pairs.
* The possibility that unlocked liquidity leaves.
* The need to evaluate token ownership and supply distribution.
A lock is one positive signal among many. Users should still evaluate the full pool and project context.
## When to use a lock
A DAMM v1 liquidity lock is useful when:
* A project wants to show long-term liquidity commitment.
* A launch pool needs stronger community confidence.
* A partner or community expects liquidity to remain available.
* The team wants pool depth to continue supporting trading even after launch.
For mature pools, locks can also help distinguish strategic liquidity from short-term mercenary liquidity.
# DAMM v1 LST Pools
Source: https://docs.meteora.ag/legacy-products/damm-v1/lst-pools
Learn how DAMM v1 LST pools support SOL/LST liquidity with stable-pool pricing, depeg-aware value tracking, and additional yield opportunities.
DAMM v1 LST pools are permissioned stable-style pools built for supported liquid staking token markets. They help users swap between SOL and an LST while letting the AMM account for the LST's changing SOL value.
An LST, or liquid staking token, represents staked SOL plus accumulated staking rewards. Because staking rewards accrue over time, many LSTs are designed to become worth slightly more SOL over time. That makes a simple 1:1 pool incomplete: the pool needs to understand that the LST side may appreciate.
## Why LST pools exist
Solana has a large amount of directly staked SOL. Liquid staking helps make that capital usable across DeFi, but LST adoption depends on liquidity. Users need to enter and exit LSTs with low slippage. Protocols need enough market depth for their token to be useful across wallets, aggregators, lending markets, and structured products.
DAMM v1 LST pools were built to support that market structure:
* Users get a swap venue between SOL and LSTs.
* LPs can provide passive liquidity without managing active ranges.
* LST protocols can grow liquidity without relying only on emissions.
* Eligible assets can earn additional yield through Dynamic Vaults.
## The core problem: LSTs appreciate
In a standard AMM, a SOL/LST pool can create impermanent loss for LPs if the LST reliably appreciates against SOL. The pool may treat the assets as if they should remain 1:1 even though staking rewards gradually change the fair relationship.
DAMM v1 addresses this with a depeg-aware stable pool design. In the AMM program, depeg pools require token A to be native SOL and token B to be the staking or interest-bearing token. The pool can update a cached base virtual price for the LST side and use that value when calculating stable-swap balances.
Conceptually:
```math theme={"system"}
\text{LST value used by the pool} = \text{LST amount} \times \text{LST virtual price}
```
This lets the pool price swaps based on the LST's underlying value rather than assuming one LST is always equal to one SOL.
DAMM v1 depeg support is implemented for Marinade mSOL, Lido/Solido stSOL, and generic SPL stake-pool tokens. Permissionless stable pools do not support depeg mode.
## How DAMM v1 LST pools work
A DAMM v1 LST pool combines three ideas:
1. **Stable-pool pricing** concentrates liquidity around the expected SOL/LST relationship.
2. **Virtual price tracking** accounts for the LST's changing value over time. The cached value refreshes only after the cache is older than 10 minutes.
3. **Vault-backed liquidity** allows eligible idle assets to participate in Dynamic Vault yield where supported.
The user experience stays simple. Users swap between SOL and the LST. LPs deposit liquidity and receive LP tokens. The pool handles the value adjustment internally.
## Benefits for LPs
DAMM v1 LST pools are designed to make LP participation more passive and more durable.
LPs can benefit from:
* **Lower-slippage routing volume** because stable-style liquidity is efficient near the expected exchange rate.
* **Reduced LST appreciation mismatch** because the pool can account for the staking token's virtual price.
* **Swap fee income** from users entering and exiting LST exposure.
* **Additional vault yield** where eligible liquidity is routed through Dynamic Vaults.
* **Farming rewards** if the LST protocol or partner funds a reward pool for LP tokens.
## Benefits for LST protocols
For an LST protocol, liquidity is distribution. A strong SOL/LST pool can make the token easier to buy, easier to exit, easier to integrate, and more attractive to DeFi users.
DAMM v1 LST pools help protocols:
* Build liquidity around the natural SOL/LST relationship.
* Improve aggregator routing and execution quality.
* Reduce dependence on short-term token emissions.
* Offer LPs multiple potential return sources.
* Support early liquidity growth while the LST is still building adoption.
## Dynamic Vault yield for LST pools
Some DAMM v1 LST pool assets can connect to Dynamic Vaults. When supported, idle liquidity may be allocated into external strategies while the pool remains available for swaps and withdrawals.
This matters because LST liquidity can be strategic and long-lived. Vault yield can help keep LPs engaged during periods when swap volume is not enough on its own.
LST pools still carry risk. LPs should understand LST protocol risk, smart contract risk, liquidity risk, depeg risk, lending strategy risk, and the possibility that incentives change over time.
## When to use an LST pool
A DAMM v1 LST pool is useful when:
* The pair is SOL and a supported liquid staking token.
* The LST has a reliable way to determine virtual price or staking value.
* The goal is low-slippage routing, not wide price discovery.
* The protocol wants passive liquidity that can remain productive over time.
* LPs need more than short-term farming rewards to justify liquidity.
For volatile token launches or pairs without a stable relationship, use a constant-product design instead.
# DAMM v1 Pool Design Guide
Source: https://docs.meteora.ag/legacy-products/damm-v1/pool-design-guide
Choose the right DAMM v1 pool type, yield layers, farm setup, fee interpretation, and liquidity commitment for a legacy Meteora pool.
DAMM v1 is a legacy product, but many teams still need to understand how to evaluate or maintain an existing DAMM v1 pool. This guide helps you think like a product owner: what kind of market are you creating, what LP behavior do you want, and what return stack supports that behavior?
## Step 1: Choose the pool curve
### Use a constant-product pool for volatile markets
Choose a constant-product DAMM v1 pool when the token pair needs open-ended price discovery.
Good fit:
* Project token paired with SOL or USDC.
* Long-tail assets.
* Markets where price can move significantly.
* Liquidity that should cover a wide price range.
Product tradeoff: liquidity is spread across the full curve, so it is simple and robust, but not as capital efficient around a narrow price band.
### Use a stable pool for pegged or correlated assets
Choose a stable pool when both assets should trade close to a target relationship.
Good fit:
* Stablecoin pairs.
* Correlated assets.
* Assets where low slippage near a peg is more important than wide price discovery.
Product tradeoff: stable pools are efficient near the target relationship, but they are not designed for assets that can freely reprice against each other.
### Use an LST pool for supported SOL/LST markets
Choose an LST-aware stable pool when token A is native SOL and token B is a supported liquid staking token. In DAMM v1, this is a permissioned depeg configuration rather than a generic permissionless stable-pool option.
Good fit:
* LST protocols building liquidity.
* SOL/LST swap routes.
* Markets where the LST appreciates against SOL over time.
Product tradeoff: LST pools improve the fit for staking-token markets, but teams still need to account for LST protocol risk and depeg risk.
## Step 2: Understand the LP return stack
DAMM v1 LP returns can come from several layers:
Organic trading demand pays fees that can increase the value backing LP tokens.
Eligible idle assets may earn external strategy yield through Dynamic Vaults.
External farms can distribute campaign rewards to staked LP tokens.
Locked LP tokens can signal long-term support and improve market confidence.
A strong pool does not need every layer, but it should have a clear reason for why LPs will stay.
## Step 3: Decide whether the pool needs a farm
A farm is useful when organic fees and vault yield are not enough to attract the target depth. It is a separate incentive layer around DAMM v1 LP tokens, not a setting inside the AMM pool state.
Use a farm when:
* The market is new and needs bootstrapping.
* The project wants to compete for aggregator routing.
* A partner wants to reward LPs for supporting strategic liquidity.
* The pool needs a campaign window around launch, migration, or growth.
Avoid relying only on farms when:
* The reward budget is too small to change LP behavior.
* There is no plan for liquidity after incentives end.
* The reward token is highly volatile and could distort displayed APR.
* The pool has no expected trading demand.
## Step 4: Evaluate Dynamic Vault fit
Dynamic Vault yield is valuable when the pool contains supported assets such as major stablecoins or SOL. It is less relevant when a token side has no supported vault strategy.
Ask:
* Does one side or both sides of the pool have Dynamic Vault support?
* How much of the return expectation comes from vault yield?
* What external strategy risks does the vault introduce?
* How important is immediate withdrawal liquidity for this LP audience?
Vault yield is best used as a durability layer, not as the only reason to LP.
## Step 5: Decide whether to lock liquidity
Liquidity locks are useful when trust and continuity matter.
Consider a lock when:
* The project wants to demonstrate long-term liquidity commitment.
* The pool is part of a token launch or migration.
* Community members are concerned about sudden liquidity removal.
* A partner or launchpad requires a visible commitment.
A lock improves confidence, but it does not eliminate market risk. Locked LP tokens are still exposed to the pool's assets and the pool's underlying mechanics.
## Step 6: Read APY as components, not one number
When reviewing a DAMM v1 pool, split the displayed return into parts:
* **Base APY** from virtual price growth.
* **Fee-over-TVL** from recent trading fees.
* **Vault yield** from eligible Dynamic Vault strategies.
* **Farm APR** from reward emissions.
This prevents a common mistake: treating a temporary farm APR as if it were permanent pool yield.
## Step 7: Match the pool to the audience
### Traders
Traders care about execution quality: depth, slippage, reliability, and routing.
### LPs
LPs care about return, risk, ease of withdrawal, asset exposure, and incentive duration.
### Projects
Projects care about liquidity depth, market confidence, token distribution, and sustainability after campaigns end.
### Integrators
Integrators care about predictable pool behavior, existing liquidity, and whether the market is still maintained.
A good DAMM v1 pool design aligns all four groups.
## Recommended DAMM v1 patterns
### Stablecoin pool
* Use a stable pool.
* Prioritize low slippage and routing volume.
* Use Dynamic Vault yield where supported.
* Add farms only when you need extra campaign depth.
### SOL/LST pool
* Use an LST-aware stable pool when supported.
* Emphasize virtual price tracking and reduced staking-token mismatch.
* Consider partner rewards during early liquidity growth.
* Educate LPs on LST and depeg risk.
### Long-tail token pool
* Use a constant-product pool.
* Consider a liquidity lock for trust.
* Use farms for launch or migration windows.
* Be realistic about organic volume after incentives end.
## Final checklist
Before promoting or maintaining a DAMM v1 pool, answer:
* What curve does this market need: constant-product, stable, or LST?
* What assets are in the pool, and what risks do they introduce?
* Does the pool have eligible Dynamic Vault yield?
* Is there an active farm, and when does it end?
* How are fees and APY displayed to LPs?
* Is any liquidity locked?
* What is the plan after incentives decline?
The best DAMM v1 pools are not just high-APR pools. They are pools with a clear market purpose, sustainable LP reasons, and transparent tradeoffs.
# DAMM v1 Pools With Farms
Source: https://docs.meteora.ag/legacy-products/damm-v1/pools-with-farms
Understand how DAMM v1 farms let LPs stake LP tokens to earn partner reward tokens on top of trading fees and eligible vault yield.
DAMM v1 pools can be paired with external farms. A farm lets LPs stake their DAMM v1 LP tokens in a separate reward program and earn additional reward tokens funded by a project, partner, or campaign sponsor.
This gives teams a way to incentivize liquidity without changing the underlying AMM pool. The pool continues to support swaps and earn trading fees. The farm adds a separate reward layer around the LP token.
## Why add a farm?
Liquidity is a marketplace. LPs compare expected return, token risk, depth, duration, and opportunity cost. A farm helps a project make its pool more attractive by adding explicit token incentives.
Farms are useful when a project wants to:
* Bootstrap liquidity for a new or strategic market.
* Retain LPs during an important launch or campaign window.
* Compete for routing volume on aggregators.
* Reward early liquidity supporters.
* Add incentives while the pool's organic trading fee revenue is still growing.
## How DAMM v1 farms work
The DAMM v1 farm model is simple:
The LP adds liquidity to a DAMM v1 pool and receives LP tokens representing their pool share.
The LP deposits those LP tokens into a farming program. While staked, the LP tokens earn rewards based on their share of total staked LP tokens.
The farm distributes funded rewards across the configured reward duration. Historical DAMM v1 farm integrations commonly support up to two reward tokens.
The LP can claim earned rewards. To withdraw pool liquidity, the LP first unstakes LP tokens, then removes liquidity from the DAMM v1 pool.
## Reward distribution
External farms distribute rewards based on staked LP token share.
```math theme={"system"}
\text{reward rate} = \frac{\text{funded reward amount}}{\text{reward duration}}
```
```math theme={"system"}
\text{user reward} = \text{user staked share} \times \text{rewards emitted during the period}
```
If a user stakes 10% of all LP tokens in the farm, they earn roughly 10% of the emitted rewards during the period they remain staked, subject to exact on-chain accounting and timing.
## What LPs can earn
A DAMM v1 pool with a farm can have several return layers:
* **Swap fees** from trading activity in the AMM pool.
* **Dynamic Vault yield** if eligible pool assets are connected to Dynamic Vault strategies.
* **Farm rewards** from the reward pool.
* **Partner incentives** when a campaign adds additional reward sources.
Farming rewards are not the same as pool fees. LPs must stake their LP tokens in the farm to earn farm rewards. Holding LP tokens outside the farm still represents pool ownership, but it may not receive farming incentives.
## Farm design choices
A good farm campaign should answer five product questions:
### What behavior are you incentivizing?
Most farms incentivize liquidity depth. The project wants LPs to keep capital in the pool so traders get better execution.
### Which reward token should be used?
Reward tokens should be meaningful to the LP audience. Many campaigns use a project token, partner token, or strategic ecosystem incentive.
### How long should rewards last?
Short campaigns can bootstrap attention, but they may attract mercenary liquidity. Longer campaigns can support stability but require larger budgets. A common starting point is a multi-week campaign.
### How much liquidity is needed?
The reward budget should match the target pool depth. Overpaying can waste emissions. Underpaying may fail to move liquidity.
### What happens when rewards end?
A farm is healthiest when it bridges a pool toward organic sustainability: trading volume, vault yield, integrations, and stronger user demand.
## Permissioned farm creation
Farm creation for legacy DAMM v1 pools is typically coordinated rather than created through the AMM pool itself. If you need a farm for a DAMM v1 pool, prepare the following information before contacting Meteora:
* DAMM v1 pool address or pool link.
* Reward token A mint address.
* Reward token B mint address, if using a second reward token.
* Reward duration in seconds.
* Intended campaign objective and expected start timing.
Once rewards are funded into a farm, they should be treated as committed campaign budget. If a campaign is extended, remaining rewards can be rolled into the new rate, but teams should plan funding carefully before launch.
## Farms vs Dynamic Vault yield
Farms and Dynamic Vault yield solve different problems.
* **Farms** are explicit incentives funded by a project or partner. They are great for targeted campaigns but depend on a finite reward budget.
* **Dynamic Vault yield** comes from eligible idle liquidity being allocated to external strategies. It can support a pool's baseline return profile but depends on available lending yield and strategy risk.
The strongest DAMM v1 pools often combine both: vault yield for ongoing capital productivity, farms for strategic growth moments, and swap fees for organic demand.
# DAMM v1 Stable Pools
Source: https://docs.meteora.ag/legacy-products/damm-v1/stable-pools
Understand DAMM v1 stable pools, the StableSwap-style design used for pegged assets, and why amplification helps create lower-slippage liquidity around a target price.
DAMM v1 stable pools are designed for token pairs that are expected to trade close to a known relationship. Common examples are stablecoin pairs such as USDC/USDT and permissioned SOL/LST pools that can account for a supported staking-token virtual price.
Instead of spreading liquidity evenly across every possible price like a volatile constant-product pool, a stable pool concentrates more of its effective liquidity near the target relationship. The result is a smoother trading experience for assets that should not move far apart.
## What stable pools are best for
Use a DAMM v1 stable pool when the pair has a strong reason to trade close together:
* **Stablecoin pairs** such as USDC/USDT or other dollar-denominated assets.
* **Closely correlated assets** where traders expect a tight exchange rate.
* **Yield-bearing or receipt-style assets** when the pool can account for their value relationship.
* **High-volume routing pairs** where low slippage matters more than supporting a wide speculative price range.
A stable pool is not the right fit for a volatile token launch or a pair where the price can move freely. For those markets, a constant-product pool is usually more appropriate.
## How stable pools work
DAMM v1 stable pools use a StableSwap-style curve. Product-wise, the curve has two behaviors:
* Near the expected relationship, it behaves like the pool has deeper liquidity, so trades can happen with lower slippage.
* Far away from the expected relationship, it becomes more expensive to push the pool further out of balance.
This creates a natural incentive for the pool to support efficient swaps near the target while still protecting LPs when one side becomes scarce.
## Fees and limits
By default, stable-swap pools use a **0.01%** trade fee with **0%** protocol fee, so the full trade fee remains LP-relevant. Permissionless fee-tier creation also allows **0.04%**, **0.10%**, and **1.00%** stable-pool trade fees.
Stable pools support imbalanced deposits and single-sided withdrawals through stable-swap math. Constant-product pools do not support those curve operations.
## The role of amplification
The amplification factor, often called `AMP`, controls how concentrated the pool's liquidity feels around the target relationship.
* **Higher AMP** means tighter pricing and lower slippage near the target.
* **Lower AMP** means the pool behaves more like a normal AMM and is more tolerant of imbalance.
DAMM v1 permissionless stable pools must use `amp = 100`, token multipliers derived from mint decimals, and no depeg mode. More specialized stable pools require permissioned setup.
Think of AMP as the pool's confidence in the relationship between the two assets. If the assets are genuinely stable relative to each other, more amplification can improve the trading experience. If the relationship is uncertain, too much amplification can make the pool brittle when the pair moves away from the target.
## Why stable pools help LPs
Stable pools are built to make LP capital more productive around the prices where trades are expected to happen.
For LPs, that can mean:
* More efficient use of liquidity around the target relationship.
* Better volume capture from routers and aggregators looking for low-slippage paths.
* Less need for active position management compared with concentrated liquidity systems.
* Additional potential yield when eligible assets are connected to Dynamic Vaults.
DAMM v1 stable pools are still passive LP positions. LPs deposit assets, receive LP tokens, and hold a share of the pool. They do not need to manually rebalance a custom price range.
## Dynamic Vault composition
Stable pools can compose with Dynamic Vaults when the assets are supported by the vault layer. That means some idle pool liquidity can be allocated into external lending strategies while the pool continues serving swaps and withdrawals.
This matters because stable pairs can sometimes have lower trading fees than volatile pairs. Vault yield can help improve the LP return profile during quieter trading periods.
Dynamic Vault yield is an additional source of return, not a guarantee. Lending strategies introduce their own risks, and pool liquidity must still support withdrawals and swaps.
## Stable pools vs constant-product pools
Choose a **stable pool** when:
* The assets should trade close to a target value.
* Low slippage near the peg is the main goal.
* LPs want passive liquidity without setting active ranges.
* The market is more about efficient routing than price discovery.
Choose a **constant-product pool** when:
* The assets can move significantly against each other.
* The market needs full-range price discovery.
* The pair includes a volatile token.
* You do not want the pool optimized around a specific relationship.
## Example: Stablecoin Liquidity
Suppose a USDC/USDT pool has deep liquidity and both tokens are expected to trade close to \$1. A stable pool can offer tight pricing for users swapping between the two assets. Traders get lower slippage, aggregators can route more volume through the pool, and LPs earn fees from that activity.
If the pool's assets are supported by Dynamic Vault strategies, idle liquidity may also earn additional yield, improving the pool's appeal even when swap volume fluctuates.
# What is DAMM v1?
Source: https://docs.meteora.ag/legacy-products/damm-v1/what-is-damm-v1
Learn how Meteora DAMM v1 combines two-token AMM liquidity, stable pools, LST-aware pools, liquidity locks, and Dynamic Vault-backed reserves into one legacy liquidity product.
DAMM v1 is Meteora's original Dynamic AMM on Solana. It is a legacy liquidity product for teams, integrators, and liquidity providers who need to understand existing Meteora LP-token pools.
At the surface, a DAMM v1 pool feels familiar: two SPL tokens, shared liquidity, LP tokens, swaps, trading fees, and pool ownership represented by LP shares. Under the hood, each side of the pool is represented by a Meteora Dynamic Vault position. The AMM converts those vault LP positions back into token amounts when it prices swaps, mints LP tokens, processes withdrawals, or calculates virtual price.
DAMM v1 runs on the mainnet program `Eo7WjKq67rjJQSZxS6z3YkapzY3eMj6Xy8X5EQVn5UaB`.
## Why DAMM v1 matters
DAMM v1 was built for a simple problem: liquidity is expensive to attract and even more expensive to keep.
Traditional AMMs usually rely on two sources of LP return: swap fees and token incentives. DAMM v1 adds vault-backed composition: when the connected Dynamic Vault for an asset has supported strategies, idle liquidity may earn additional yield while the AMM continues to support swaps and withdrawals.
That makes DAMM v1 especially useful for:
* **Long-tail token markets** that need dependable full-range liquidity.
* **Stable asset pairs** that need low-slippage swaps near a target peg.
* **LST markets** where the staking token appreciates against SOL over time.
* **Partner-incentivized pools** where projects use external farms or campaigns on top of AMM fees.
* **Community confidence pools** where teams want to lock liquidity while fees continue to accrue.
## Product pillars
DAMM v1 supports classic full-range AMM liquidity for assets that can trade across a wide price range.
Stable pools use a StableSwap-style curve to create deeper liquidity around assets expected to trade close to each other.
LST pools account for staking-token appreciation by using a depeg-aware stable pool design for SOL/LST pairs.
Eligible pool assets can sit inside Dynamic Vaults, where idle liquidity may be allocated to supported lending strategies.
Projects can use external farming programs so staked DAMM v1 LP tokens earn campaign rewards.
LP tokens can be locked to signal long-term commitment while the locked liquidity remains part of the pool.
## How DAMM v1 works
A DAMM v1 pool has two token sides: token A and token B. When LPs deposit both assets, they receive LP tokens that represent their share of the pool. Traders swap against the pool, and the pool updates its reserves according to the curve selected for that market.
DAMM v1 supports two major curve families:
* **Constant-product pools** use the familiar `x × y = k` model. They are best for volatile assets where the price can move freely across a wide range.
* **Stable pools** use an amplified StableSwap curve. They are best for assets that should trade close together, such as stablecoins or certain SOL/LST pairs.
The pool itself does not simply hold raw token balances. Each side points to a Dynamic Vault. The DAMM v1 program tracks the pool's vault LP position and converts it back into total token value when swaps, deposits, withdrawals, and locks happen.
For exact limits, see [Implementation and Limits](/legacy-products/damm-v1/implementation-and-limits).
## LP return stack
DAMM v1 LPs can earn from multiple layers depending on the pool configuration:
1. **Trading fees** from swaps through the pool.
2. **Dynamic Vault yield** when eligible assets such as USDC, USDT, or SOL are routed through supported vault strategies.
3. **External farming rewards** when a project or partner funds a separate reward program for staked DAMM v1 LP tokens.
4. **Partner or campaign incentives** when additional programs reward DAMM v1 liquidity.
Not every DAMM v1 pool has every yield source. A volatile pool without a farm is different from a stable pool with Dynamic Vault yield and partner incentives. Always evaluate the specific pool's fee, vault, farm, activation, and risk profile.
## DAMM v1 vs DAMM v2
DAMM v1 is a legacy product. It remains important because many pools and integrations were built around its LP-token model, Dynamic Vault composition, stable pool design, and farming program.
DAMM v2 is the newer configurable AMM. It adds modern product controls such as NFT positions, concentrated liquidity options, launch-ready fee modes, built-in liquidity mining, Token 2022 support, and more granular pool configuration.
Use the DAMM v1 documentation to reference details about existing legacy pools, stable pools, LST pools, earlier farm structures, or vault-backed liquidity. **If you are creating a new pool or want to leverage the latest features, integrations, and controls, we recommend using DAMM v2.** Please refer to the [DAMM v2 documentation](/core-products/damm-v2/what-is-damm-v2) for guidance on building with the current Meteora AMM product suite.
## Explore DAMM v1
Learn why stable pools are optimized for assets that should trade close to a target price.
See how DAMM v1 supports SOL/LST liquidity while accounting for staking-token appreciation.
Understand how eligible idle liquidity can earn additional lending yield.
Learn how external reward pools add token incentives for LPs.
Understand how locked LP tokens keep liquidity committed while the pool remains active.
See how trading fees, vault yield, and external rewards affect displayed returns.
Choose the right DAMM v1 pool type, fee setup, reward design, and LP experience.
See constraints for curves, fees, activation, depeg pools, liquidity operations, and locks.
Use the math appendix for constant-product pricing, StableSwap behavior, LP share value, fees, and rewards.
# Dynamic Vault Access and Limits
Source: https://docs.meteora.ag/legacy-products/dynamic-vault/access-and-limits
Dynamic Vault account model, permissions, supported strategy behavior, token support, and implementation limits.
This page summarizes the on-chain constraints that matter for integrators and operators. It focuses on what the deployed vault program enforces.
## Main Accounts
| Account | Important fields |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Vault` | `enabled`, `total_amount`, `token_vault`, `fee_vault`, `token_mint`, `lp_mint`, `strategies`, `base`, `admin`, `operator`, `locked_profit_tracker`. |
| `Strategy` | `reserve`, `collateral_vault`, `strategy_type`, `current_liquidity`, `bumps`, `vault`, `is_disable`. |
| `LockedProfitTracker` | `last_updated_locked_profit`, `last_report`, `locked_profit_degradation`. |
## Program Addresses
| Value | Address |
| --------------------------------- | ---------------------------------------------- |
| Mainnet program | `24Uqj9JCLxUeoC3hGfh5W3s9FM9uCHDS2SG3LYwBpyTi` |
| Treasury owner | `9kZeN47U2dubGbbzMrzzoRAUvpuxVLRcjW9XiFpYjUo4` |
| Rebalance vault base | `HWzXGcGHy4tcpYfaRDCyLNzXqBTv3E6BttpCH2vJxArv` |
| Production initial admin/operator | `DHLXnJdACTY83yKwnUkeoDjqi4QBbsYGa1v8tJL76ViX` |
Vault PDAs are derived from the token mint and vault base. In practice this means one rebalance vault PDA and one idle vault PDA per token mint for this program.
On non-test builds, the initializer payer can be anyone, but new vaults initialize `admin` and `operator` to the fixed production admin address above. Rebalance vault admin can later transfer admin or set a different operator.
## Roles
| Role | What it can do |
| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| User | Deposit into enabled vaults, withdraw by burning LP tokens, and use the strategy-backed withdrawal path when the required accounts are provided. |
| Admin | Manage rebalance vault settings: enable or disable deposits, set operator, transfer admin, set fee vault, update locked-profit degradation, initialize/add/remove strategies, and submit strategy actions. |
| Operator | Submit `deposit_strategy`, `withdraw_strategy`, and `claim_rewards` for rebalance vaults. The admin can also submit these actions. |
| Treasury owner | Must own the configured fee vault and reward token accounts used by reward claims. |
The program's `enabled` flag gates deposits only. It does not block withdrawals.
## Permissioned Instructions
| Instruction | Permission and constraints |
| ---------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| `enable_vault` | Admin only, rebalance vault only. |
| `set_operator` | Admin only, rebalance vault only. |
| `transfer_admin` | Current admin and new admin sign; rebalance vault only. |
| `transfer_fee_vault` | Admin only; new fee vault must be for the vault LP mint and owned by the treasury address. |
| `update_locked_profit_degradation` | Admin only; value must be greater than `0` and less than or equal to `1,000,000,000,000`. |
| `initialize_strategy` | Admin only; rebalance vault only; fee vault must already be set. |
| `add_strategy` | Admin only; strategy must belong to the vault and must not be disabled. |
| `remove_strategy` | Admin only; withdraws all strategy collateral and requires remaining strategy liquidity to be at most `1` unit. |
| `remove_strategy2` | Admin only; supports advance payment with `max_admin_pay_amount` and permanently disables the strategy. |
| `deposit_strategy` / `withdraw_strategy` | Admin or operator; rebalance vault only; strategy must be listed on the vault. |
| `claim_rewards` | Admin or operator; rebalance vault only; strategy must be listed; reward account must be treasury-owned. |
## Strategy Limits
| Limit | Value |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| Maximum strategies per vault | `30` |
| Maximum bump values stored per strategy | `10` |
| Supported external strategy handler in current source | `JupLend` |
| JupLend deposit precision tolerance | At most `100` smallest units between requested deposit and calculated deposited liquidity. |
| Strategy-backed withdrawal precision loss | At most `1` smallest unit. |
The `StrategyType` enum still includes several legacy variants, but the handler dispatch for those variants panics as unsupported. Documentation should not describe those variants as active integrations unless the deployed program is updated.
For `JupLend`, the reserve mint must match the vault token mint, the collateral mint must match the lending reserve's f-token mint, and the remaining accounts must satisfy Jupiter Lend's deposit or withdrawal account requirements. Jupiter Lend rewards are automatically reflected in the collateral token, so the current `JupLend` `claim_rewards` handler does not transfer a separate reward token.
## Token Support
Vault initialization, deposits, withdrawals, LP minting, and most token accounts use `anchor_spl::token`, the SPL Token program interface. The vault program does not include a general Token-2022 transfer-hook or transfer-fee handling path for user deposits and withdrawals.
Treat Dynamic Vault as SPL Token based unless a specific deployed vault and integration has been separately verified. Do not assume Token-2022 extension support from this program.
## Rebalance Vault vs Idle Vault
Rebalance vaults use Meteora's configured base address and can interact with strategy instructions. Idle vaults use the default base address and are constrained out of rebalance-only instructions.
| Capability | Rebalance vault | Idle vault |
| ------------------------------ | --------------- | ---------- |
| User deposit and withdraw | Yes | Yes |
| Enable or disable deposits | Yes | No |
| Set operator | Yes | No |
| Transfer admin | Yes | No |
| Transfer fee vault | Yes | No |
| Initialize or add strategy | Yes | No |
| Strategy deposit or withdrawal | Yes | No |
| Claim strategy rewards | Yes | No |
## Important Edge Cases
* Deposits with `token_amount = 0` fail.
* Deposits fail when `enabled = 0`; withdrawals do not.
* Slippage is enforced with `minimum_lp_token_amount` on deposit and `min_out_amount` on withdrawal.
* Strategy initialization fails if `fee_vault` is still the default public key.
* A fee vault must be owned by the treasury address and must use the vault LP mint.
* Reward claims must send rewards to a treasury-owned token account.
* Losses from strategy actions reduce locked profit before new gain is added.
* Strategy removal does not automatically claim rewards; comments in the source indicate rewards should be claimed separately when applicable.
# Dynamic Vault Formulas
Source: https://docs.meteora.ag/legacy-products/dynamic-vault/formulas
The core Dynamic Vault formulas for LP shares, unlocked amount, locked profit, strategy profit and loss, and performance-fee LP minting.
Dynamic Vault performs accounting in smallest token units using checked integer arithmetic. Display decimals are a UI concern. Division rounds down unless a strategy handler explicitly requests rounded-up collateral conversion.
The formulas below describe the on-chain accounting model. Strategy-specific conversions, such as JupLend collateral-to-liquidity exchange-rate math, are handled by the strategy handler.
## Core Values
| Value | Meaning |
| ---------------------------- | ----------------------------------------------------------------------------------------- |
| `total_amount` | Vault liquidity tracked by the program, including the token vault and strategy liquidity. |
| `token_vault.amount` | Underlying token amount currently in the vault reserve. |
| `strategy.current_liquidity` | Underlying liquidity value last recorded for a strategy. |
| `lp_mint.supply` | Total supply of vault LP tokens. |
| `last_updated_locked_profit` | Locked profit after the latest locked-profit update. |
| `last_report` | Timestamp of the latest locked-profit update. |
| `locked_profit_degradation` | Per-second unlock rate. |
## Locked Profit
Dynamic Vault uses a denominator of:
```math theme={"system"}
\text{LOCKED\_PROFIT\_DEGRADATION\_DENOMINATOR} = 1{,}000{,}000{,}000{,}000
```
The default degradation rate fully unlocks locked profit over 6 hours:
```math theme={"system"}
\text{defaultDegradation} =
\left\lfloor
\frac{1{,}000{,}000{,}000{,}000}{6 \times 3{,}600}
\right\rfloor
```
For a current timestamp:
```math theme={"system"}
\text{duration} = \text{currentTime} - \text{lastReport}
```
```math theme={"system"}
\text{lockedFundRatio} = \text{duration} \times \text{lockedProfitDegradation}
```
If `lockedFundRatio` is greater than the denominator, locked profit is zero. Otherwise:
```math theme={"system"}
\text{lockedProfit} =
\left\lfloor
\frac{
\text{lastUpdatedLockedProfit}
\times
(1{,}000{,}000{,}000{,}000 - \text{lockedFundRatio})
}{
1{,}000{,}000{,}000{,}000
}
\right\rfloor
```
## Unlocked Amount
The unlocked amount is used for deposit and withdrawal share calculations.
```math theme={"system"}
\text{unlockedAmount} = \text{totalAmount} - \text{lockedProfit}
```
## Deposit LP Tokens
For a non-empty LP supply:
```math theme={"system"}
\text{lpTokensMinted} =
\left\lfloor
\frac{\text{depositAmount} \times \text{lpSupply}}{\text{unlockedAmount}}
\right\rfloor
```
The program then increases `total_amount` by `depositAmount`.
For zero LP supply, the program first adds the deposit to `total_amount`, then mints the current unlocked amount:
```math theme={"system"}
\text{lpTokensMinted} = \text{unlockedAmountAfterDeposit}
```
This also covers the edge case where all LP tokens were previously burned but some profit remains locked.
## Withdrawal Amount
For a direct LP-token withdrawal:
```math theme={"system"}
\text{withdrawAmount} =
\left\lfloor
\frac{\text{lpTokensBurned} \times \text{unlockedAmount}}{\text{lpSupply}}
\right\rfloor
```
The program subtracts `withdrawAmount` from `total_amount`, transfers that amount from the token vault, and burns the user's LP tokens.
For strategy-backed direct withdrawals, the program may refine the LP amount if the strategy cannot return the full desired amount:
```math theme={"system"}
\text{refinedLpBurn} =
\left\lfloor
\frac{\text{actualOutAmount} \times \text{lpSupply}}{\text{unlockedAmount}}
\right\rfloor
```
Precision loss in this path must be at most `1`.
## Strategy Total Amount Update
After a strategy action, the program updates vault total liquidity from before and after values:
```math theme={"system"}
\text{newTotalAmount}
=
\text{oldTotalAmount}
+ \text{tokenVaultAfter}
+ \text{strategyLiquidityAfter}
- \text{tokenVaultBefore}
- \text{strategyLiquidityBefore}
```
Gain and loss are derived by comparing total amount before and after:
```math theme={"system"}
\text{gain} = \max(\text{newTotalAmount} - \text{oldTotalAmount}, 0)
```
```math theme={"system"}
\text{loss} = \max(\text{oldTotalAmount} - \text{newTotalAmount}, 0)
```
## Locked Profit Update
The program first calculates remaining locked profit at the current timestamp. Loss reduces remaining locked profit first:
```math theme={"system"}
\text{lockedAfterLoss} =
\max(\text{remainingLockedProfit} - \text{loss}, 0)
```
Gain is then added:
```math theme={"system"}
\text{newLockedProfit} = \text{lockedAfterLoss} + \text{gain}
```
`last_report` is updated to the current timestamp.
## Performance Fee
The performance-fee constants are:
```math theme={"system"}
\text{PERFORMANCE\_FEE\_NUMERATOR} = 500
```
```math theme={"system"}
\text{PERFORMANCE\_FEE\_DENOMINATOR} = 10{,}000
```
So the fee is 5% of positive strategy gain:
```math theme={"system"}
f =
\left\lfloor
\frac{\text{gain} \times 500}{10{,}000}
\right\rfloor
```
The program does not transfer this fee as underlying tokens. It mints LP tokens to the configured fee vault.
Let:
* `p` be the gain
* `u` be the unlocked amount before the rebalance accounting update
* `s` be the LP supply before fee minting
* `f` be the fee amount above
The amount of newly unlocked value attributed to the fee mint is:
```math theme={"system"}
x =
\left\lfloor
\frac{f \times u}{p + u - f}
\right\rfloor
```
The LP tokens minted to the fee vault are:
```math theme={"system"}
\text{feeLpTokens} =
\left\lfloor
\frac{x \times s}{u}
\right\rfloor
```
If fee LP tokens are minted, `x` is subtracted from `last_updated_locked_profit`. This keeps the virtual price stable at the moment the performance fee is minted, while future locked profit continues to unlock over time.
If gain is zero, or the unlocked amount is zero, no performance-fee LP tokens are minted.
# Rebalance Crank
Source: https://docs.meteora.ag/legacy-products/dynamic-vault/hermes/rebalance-crank
How Dynamic Vault strategy actions update liquidity, locked profit, losses, and LP-token performance fees.
A rebalance crank is a strategy transaction submitted by the vault admin or operator. The vault program exposes two normal rebalance actions:
* `deposit_strategy(amount)`
* `withdraw_strategy(amount)`
Both actions use the same accounting wrapper after the strategy handler runs.
## Required Constraints
Before a rebalance can complete:
* the vault must be a rebalance vault
* the signer must be the vault admin or operator
* the strategy must already be listed on the vault
* the token vault, LP mint, and fee vault must match the vault
* the reserve and collateral vault must match the strategy
* the strategy handler must support the strategy type
In the current source, the implemented external lending handler is `JupLend`.
## Accounting Flow
The program records token vault liquidity, strategy current liquidity, vault total amount, unlocked amount, and LP supply.
For deposits, tokens move from the token vault into the strategy. For withdrawals, strategy collateral is converted back into underlying tokens.
The strategy handler calculates current underlying liquidity from the strategy's collateral amount and exchange rate.
The program updates `total_amount` from before and after token-vault and strategy-liquidity values.
Gain is added to locked profit. Loss is reported and reduces locked profit first.
If gain is positive, the program calculates the 5% performance fee and mints LP tokens to the configured fee vault when the result is nonzero.
## Total Amount Update
```math theme={"system"}
\text{newTotalAmount}
=
\text{oldTotalAmount}
+ \text{tokenVaultAfter}
+ \text{strategyLiquidityAfter}
- \text{tokenVaultBefore}
- \text{strategyLiquidityBefore}
```
Gain or loss is then measured from `oldTotalAmount` and `newTotalAmount`.
## Why Locked Profit Changes During Rebalance
Strategy actions are when the vault observes updated strategy value. If a strategy action increases total vault value, that gain is not made fully withdrawable immediately. It is added to locked profit and unlocks over time.
If the strategy action reports a loss, that loss reduces remaining locked profit before affecting future unlocked value.
## Fee Behavior
The program charges a 5% performance fee only on positive gain. The fee is represented by newly minted vault LP tokens sent to the configured fee vault. Underlying tokens remain inside the vault system.
See [Dynamic Vault Formulas](/legacy-products/dynamic-vault/formulas#performance-fee) for the exact fee minting formula.
Rebalance transactions are not free-form transfers. They are constrained strategy actions. However, connected strategy behavior, available liquidity, exchange-rate conversions, and operator timing still affect the realized result.
# What is Hermes?
Source: https://docs.meteora.ag/legacy-products/dynamic-vault/hermes/what-is-hermes
Understand Hermes as the off-chain operator layer for Dynamic Vault and how the on-chain program constrains its actions.
Hermes is the off-chain operator layer historically used with Dynamic Vault. It monitors markets and submits vault transactions, but it is not a separate on-chain account model in the vault program.
The on-chain program recognizes two authorities for strategy operations:
* the vault `admin`
* the vault `operator`
Hermes normally acts through the configured `operator` authority.
## What Hermes Can Submit
For rebalance vaults, the admin or operator can submit:
| Instruction | Effect |
| --------------------------- | ------------------------------------------------------------------------ |
| `deposit_strategy(amount)` | Moves tokens from the vault reserve into a listed strategy. |
| `withdraw_strategy(amount)` | Withdraws collateral from a listed strategy back into the vault reserve. |
| `claim_rewards` | Claims supported strategy rewards to a treasury-owned token account. |
These actions are constrained by the same account checks as any other caller. The strategy must be listed on the vault, the reserve and collateral vault must match the strategy account, and the fee vault must match the vault.
For the current `JupLend` strategy handler, rewards accrue through the collateral token. Its `claim_rewards` implementation is effectively a no-op.
Allocation choices, market monitoring, APY comparison, utilization checks, and rebalance thresholds are off-chain operator policy. They are not formulas enforced by the vault program.
## What Hermes Cannot Do Through The Vault Program
Hermes cannot use the strategy instructions to bypass vault accounting.
* It cannot deposit into a strategy that is not listed on the vault.
* It cannot claim rewards to a token account that is not owned by the treasury address.
* It cannot mint user LP shares outside the deposit flow.
* It cannot burn user LP shares outside the withdrawal flow.
* It cannot set the fee vault, transfer admin, update locked-profit degradation, or add/remove strategies unless it is also the admin.
## Relationship To On-Chain Accounting
Hermes can decide when to submit a rebalance, but the vault program decides whether the accounts are valid and how the result is accounted for. The accounting details for `deposit_strategy` and `withdraw_strategy` are covered in [Rebalance Crank](/legacy-products/dynamic-vault/hermes/rebalance-crank).
## Practical Risk Model
Hermes matters operationally because a delayed or misconfigured operator can miss yield opportunities or leave too much liquidity in a less attractive strategy. The program still limits the operator to approved vault flows.
Off-chain allocation algorithms and risk scoring are not guaranteed by the on-chain program. Integrators should treat them as operational behavior and verify the current operator configuration for any live vault they integrate.
# What is Dynamic Vault?
Source: https://docs.meteora.ag/legacy-products/dynamic-vault/what-is-dynamic-vault
Understand Meteora Dynamic Vault as a legacy single-asset vault program for LP shares, strategy allocation, locked profit, and performance-fee accounting.
Dynamic Vault is Meteora's legacy single-asset vault program. A user deposits one SPL token into a vault, receives vault LP tokens, and later burns those LP tokens to withdraw a proportional share of the vault's unlocked token value.
For rebalance vaults, liquidity can also be deployed from the vault reserve into approved strategy accounts. The program handles the on-chain accounting: deposits, withdrawals, LP minting and burning, strategy allowlisting, total liquidity updates, locked profit, performance-fee minting, and permission checks.
Dynamic Vault runs on the mainnet program `24Uqj9JCLxUeoC3hGfh5W3s9FM9uCHDS2SG3LYwBpyTi`.
## What Dynamic Vault Does
Each vault is tied to one token mint. The vault reserve token account and LP mint are program-derived accounts for that vault.
Deposits mint LP tokens, withdrawals burn LP tokens, and share calculations use the vault's unlocked amount.
Rebalance vaults can hold up to 30 strategy accounts. Strategy deposits and withdrawals must use a strategy already recorded on the vault.
Profit reported during strategy actions is added to locked profit and released over time before it becomes part of the unlocked amount.
Profitable strategy actions can mint vault LP tokens to the configured fee vault instead of transferring underlying tokens out.
Admins manage vault configuration and strategies. The admin or configured operator can submit strategy rebalances and reward claims.
## Vault Types
The program supports two vault types.
| Type | Program behavior |
| --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Rebalance vault | Uses Meteora's configured base address, can enable or disable deposits, can set an operator, can configure a fee vault, can add strategies, and can rebalance into supported strategies. |
| Idle vault | Uses the default base address and holds all liquidity in the vault reserve. Strategy, operator, enable, fee-vault, and admin-management instructions are constrained to rebalance vaults. |
Most Dynamic Vault product documentation refers to **rebalance vaults**, because those are the vaults that can send liquidity to lending strategies.
## Lifecycle
The program creates the vault account, token vault, and LP mint. The LP mint uses the same decimals as the underlying token mint.
Deposits transfer tokens into the token vault and mint LP tokens to the user. Deposits fail when the vault is disabled or when the minted LP amount is below the user's minimum.
For rebalance vaults, the admin or operator can move liquidity between the token vault and an approved strategy account.
After a strategy action, the program compares before and after liquidity, updates total amount, records gain or loss, updates locked profit, and mints performance-fee LP tokens when applicable.
Withdrawals calculate the user's share of unlocked value. A direct withdrawal uses the token vault; a separate withdrawal path can pull from a strategy first when reserve liquidity is short.
## Current Strategy Support
The `StrategyType` enum contains legacy names from earlier integrations, but most variants now return unsupported behavior. In the current source code, the external lending strategy handler implemented for active deposits and withdrawals is `JupLend`.
The `Vault` strategy handler exists for internal compatibility, especially the advanced strategy-removal path, but it is not a yield destination for new strategy deposits.
## Risk Considerations
Dynamic Vault reduces some operational risk by keeping strategy actions inside program-approved flows, but it does not remove the risks of yield-bearing vaults.
| Risk | What to understand |
| -------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| Variable yield | Returns depend on connected lending markets, utilization, available strategies, and operator timing. |
| Strategy risk | Liquidity deployed through a strategy is exposed to the connected lending protocol and its account state. |
| Liquidity risk | Withdrawals depend on liquidity in the token vault or what can be withdrawn from a strategy at that moment. |
| Operator risk | Hermes or any configured operator can only use approved flows, but delayed or poor rebalancing can still affect allocation quality. |
| Program risk | Dynamic Vault, its strategy handlers, and connected programs can carry smart contract and integration risk. |
Yield is not guaranteed. Risk controls and permission checks bound what the vault can do, but they do not make lending strategies risk-free.
## Product Building Blocks
Understand the off-chain operator role and how it interacts with the on-chain vault constraints.
Review vault accounts, roles, instructions, token support, strategy limits, and important constraints.
See the formulas for LP shares, unlocked amount, locked profit, strategy profit and loss, and performance fees.
Dynamic Vault is a legacy product. Supported strategies are limited by the deployed program and current operator configuration.
# Stake2Earn Configuration and Limits
Source: https://docs.meteora.ag/legacy-products/stake2earn/configuration-and-limits
Review Stake2Earn setup requirements, supported tokens, production limits, admin updates, list behavior, and operational edge cases.
This page summarizes the constraints that matter when configuring or integrating Stake2Earn.
## Vault Requirements
| Requirement | Source Behavior |
| ------------ | ----------------------------------------------------------------------------------------------- |
| Pool type | The pool must be a DAMM v1 `ConstantProduct` pool. |
| Stake mint | Must be one side of the pool and must not be wrapped SOL or USDC. |
| Quote mint | Must be one side of the pool and must be wrapped SOL or USDC. |
| Lock escrow | Must belong to the pool and have the Stake2Earn vault PDA as owner. |
| Vault PDA | Derived from the program vault seed and the DAMM v1 pool address. |
| Token vaults | Associated token accounts for the vault PDA, one for the stake mint and one for the quote mint. |
Supported production quote mints:
| Asset | Mint |
| ----------- | ---------------------------------------------- |
| Wrapped SOL | `So11111111111111111111111111111111111111112` |
| USDC | `EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v` |
The program validates the lock escrow owner and pool relationship. It does not make Stake2Earn a generic staking product for unrelated tokens or pool types.
## Initialization Parameters
| Parameter | Production Range | Notes |
| -------------------------------- | ------------------------------------: | ------------------------------------------------------------------------ |
| `top_list_length` | 5 to 1,000 | Number of stakers eligible for newly released fees. |
| `seconds_to_full_unlock` | 6 hours to 31 days | Duration used to drip collected fees. |
| `unstake_lock_duration` | 6 hours to 31 days | Cooldown applied to newly requested unstakes. |
| `start_fee_distribute_timestamp` | Current time to 31 days in the future | Optional. If omitted, current time is used. Past timestamps are invalid. |
The start timestamp creates a join window before rewards begin releasing. During this window, claimed fees can accumulate as locked fees, but released amount is zero until `current_time > start_fee_distribute_timestamp`.
## Account and List Limits
| Account or List | Production Limit | Purpose |
| ----------------- | -----------------------: | ----------------------------------------------------------------------- |
| Top-staker list | 1,000 stakers | Holds the current eligible reward set. |
| Full-balance list | 10,000 stakers | Tracks candidate balances for top-list promotion. |
| Stake escrow | One per vault-owner pair | Stores active stake, pending fees, checkpoints, and unstake accounting. |
| Unstake account | One per request | Stores amount and release time, then closes on cancel or withdraw. |
When a stake escrow is created, the program attempts to add it to the full-balance list while there is capacity. After the full-balance list reaches its hard limit, a staker outside the list can reclaim the smallest listed index only if their active stake is larger and the transaction supplies the required smallest stake escrow account.
## Instruction Behavior
Stake2Earn does not update continuously by itself. State changes happen when instructions are sent.
| Instruction | Who Can Call | Main Behavior |
| ------------------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `initialize_vault` | Creator or payer | Creates the vault, token vaults, top-staker list, and full-balance list for a supported DAMM v1 pool and lock escrow. |
| `initialize_stake_escrow` | Payer for an owner | Creates one stake escrow for a vault-owner pair and grows list accounts as needed. |
| `stake` | Stake escrow owner | Attempts to claim and drip fees, updates the user's pending rewards if eligible, transfers stake tokens into the vault, and syncs list state. |
| `claim_fee` | Stake escrow owner | Attempts to claim and drip fees, updates pending rewards, transfers quote rewards up to `max_fee`, restakes the stake-mint side, and syncs list state. |
| `request_unstake` | Stake escrow owner | Attempts to claim and drip fees, updates pending rewards, removes active stake into a new unstake account, and syncs list state. |
| `cancel_unstake` | Stake escrow owner | Attempts to claim and drip fees, closes the unstake account, returns the amount to active stake, and syncs list state. |
| `withdraw` | Stake escrow owner | After the release time, transfers the unstaked amount back to the user and closes the unstake account. |
| `claim_fee_crank` | Permissionless | Attempts to claim and drip fees for the vault without updating a specific user's stake escrow. |
## Ranking Rules
Stake2Earn ranks stakers by active `stake_amount`.
| Situation | Result |
| --------------------- | ------------------------------------------------------------------------------------------ |
| Larger active stake | Ranks higher. |
| Equal active stake | Earlier full-balance-list index ranks higher. |
| Entering top list | Fee checkpoints reset to current cumulative values. |
| Leaving top list | Pending rewards are updated before the user is marked out. |
| Requesting unstake | Active stake decreases immediately and the leaderboard can update in the same instruction. |
| Claiming base rewards | Base-token rewards are restaked and can improve rank. |
## Fee Collection Rules
Stake2Earn can collect fees from the connected DAMM v1 lock escrow when fee accounting runs.
| Rule | Production Behavior |
| -------------------------- | ------------------------------------------------------------------------------------ |
| First claim | Allowed when both token sides have pending claimable fees. |
| Subsequent claims | Require at least 5 minutes since the previous lock-escrow claim. |
| Zero pending side | If either pending token fee is zero, the lock-escrow claim is skipped. |
| Dripping without new claim | Existing locked fees can still drip even when no new lock-escrow fee is claimed. |
| No effective stake | Locked fees are preserved for future stakers and `last_updated_at` is moved forward. |
Fee updates are triggered by user actions and by the permissionless `claim_fee_crank` instruction. Interfaces should not assume fee accounting updates continuously without transactions.
## Claim Rules
| Rule | Behavior |
| ------------------- | ------------------------------------------------------------------------------------- |
| Quote side | Transferred to the user's quote token account, capped by `max_fee`. |
| Stake side | Claimed in full and added to active stake. |
| Partial quote claim | Any unclaimed quote reward remains pending. |
| Checkpoint update | Pending rewards are updated before claim logic runs when the user is in the top list. |
Because the stake side is restaked, claiming can change top-staker ordering.
## Unstake Rules
| Action | Behavior |
| --------------- | ----------------------------------------------------------------------------------------------------------------------- |
| Request unstake | Requires enough active stake. Removes the amount from active stake immediately and creates an `Unstake` account. |
| Cancel unstake | Closes the `Unstake` account and returns the amount to active stake. |
| Withdraw | Allowed only after the recorded release time. Transfers stake tokens back to the user and closes the `Unstake` account. |
Updating `unstake_lock_duration` does not rewrite existing unstake accounts. Existing records keep the release time calculated when they were created.
## Admin-Controlled Updates
Approved admin keys can update these values:
| Setting | Constraint |
| ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `unstake_lock_duration` | Must remain between 6 hours and 31 days and must differ from the old value. |
| `seconds_to_full_unlock` | Must remain between 6 hours and 31 days, must differ from the old value, and must be preceded by a valid `claim_fee_crank` for the same vault in the same transaction. |
The program has a private-build access check for vault and stake-escrow initialization, gated by an access mint. That check is behind the `private` feature flag and is not part of the default public program path.
## Interface Checklist
A useful Stake2Earn interface should show:
* vault pool, stake mint, quote mint, and lock escrow;
* configured top-staker count and the user's current top-list status;
* active stake, total active stake, and effective top-list stake;
* the minimum visible stake needed to enter or remain in the top list;
* locked fees, released-fee history, and last fee-claim time where available;
* pending quote rewards and the `max_fee` value used for claims;
* base-token rewards that will be restaked on claim;
* requested unstake amounts, release times, and cancel or withdraw availability;
* clear messaging that only top stakers earn newly released fees.
Avoid promising fixed APY or guaranteed rewards. Rewards depend on trading volume, lock-escrow fee availability, fee claim timing, drip timing, leaderboard position, active stake, and integer rounding.
# Stake2Earn Formulas
Source: https://docs.meteora.ag/legacy-products/stake2earn/formulas
Understand Stake2Earn formulas for top-staker eligibility, fee drips, fee-per-stake accounting, pending rewards, claims, restaking, and unstake cooldowns.
Stake2Earn uses cumulative stake-weighted accounting. Fees released during an update are shared across the current top-staker list according to active stake amount.
All token amounts are integer raw token units. UI values should apply the relevant token decimals.
## Key Terms
| Term | Meaning |
| ------------------------------ | --------------------------------------------------------------------------------- |
| `stake_amount` | A user's active staked amount in raw project-token units. |
| `top_list_length` | Number of stakers eligible for newly released fees. Production range: 5 to 1,000. |
| `effective_stake_amount` | Sum of active stake amounts in the current top-staker list. |
| `locked_fee_a`, `locked_fee_b` | Collected token A and token B fees that have not fully released yet. |
| `seconds_to_full_unlock` | Duration used to drip locked fees. Production range: 6 hours to 31 days. |
| `cumulative_fee_per_liquidity` | Cumulative released fee per unit of eligible stake, scaled by `2^64`. |
| `checkpoint` | User's last accounted cumulative fee-per-stake value. |
| `fee_pending` | User rewards already accounted but not fully claimed. |
| `unstake_lock_duration` | Cooldown duration before a requested unstake can be withdrawn. |
## Top-Staker Eligibility
Only active stake in the top-staker list earns newly released fees.
```math theme={"system"}
\text{Eligible Stakers} = \text{Top } N \text{ stakers by active stake}
```
```math theme={"system"}
N = \text{top\_list\_length}
```
Production deployments enforce:
```math theme={"system"}
5 \leq N \leq 1{,}000
```
If two active stake amounts are equal, the earlier full-balance-list index ranks higher.
## Effective Stake Amount
The effective stake amount is the denominator for reward splitting.
```math theme={"system"}
\text{Effective Stake Amount} =
\sum_{i \in \text{Top Stakers}} \text{Stake Amount}_i
```
If the effective stake amount is zero, released-fee accounting does not advance. The program preserves locked fees for future stakers and updates `last_updated_at` to the current time.
## Fee Collection Gate
When fee accounting runs, the program may claim new fees from the DAMM v1 lock escrow.
After the first claim, production deployments require:
```math theme={"system"}
\text{Current Time} - \text{Last Claim Fee At} \geq 300 \text{ seconds}
```
The program also skips the lock-escrow claim if either pending token fee is zero:
```math theme={"system"}
\text{Pending Fee A} = 0 \quad \text{or} \quad \text{Pending Fee B} = 0
```
Even when no new lock-escrow fee is claimed, existing locked fees can still drip during the update.
## Fee Distribution Start
Fees are not released until after the configured start timestamp.
```math theme={"system"}
\text{Current Time} > \text{Start Fee Distribute Timestamp}
```
At initialization, `last_updated_at` is set to the start timestamp. If the current time is less than or equal to the start timestamp, newly claimed fees are added to locked fees but released amount is zero.
## Fee Drip Release
Each token side is released separately. For one token:
```math theme={"system"}
\text{Locked Fee}_{new} =
\text{Locked Fee}_{old} + \text{Newly Claimed Fee}
```
```math theme={"system"}
\text{Seconds Elapsed} =
\text{Current Time} - \text{Last Updated At}
```
If elapsed time is greater than or equal to the full unlock duration:
```math theme={"system"}
\text{Released Fee} = \text{Locked Fee}_{new}
```
Otherwise:
```math theme={"system"}
\text{Released Fee} =
\left\lfloor
\frac{\text{Locked Fee}_{new} \times \text{Seconds Elapsed}}
{\text{Seconds To Full Unlock}}
\right\rfloor
```
The program then subtracts the released amount:
```math theme={"system"}
\text{Remaining Locked Fee} =
\text{Locked Fee}_{new} - \text{Released Fee}
```
## Fee Per Stake
Released fees increase a cumulative fee-per-stake value for the current top-staker list. The program uses `SCALE_OFFSET = 64`.
```math theme={"system"}
\text{Delta Fee Per Stake} =
\left\lfloor
\frac{\text{Released Fee} \times 2^{64}}
{\text{Effective Stake Amount}}
\right\rfloor
```
```math theme={"system"}
\text{Cumulative Fee Per Stake}_{new} =
\text{Cumulative Fee Per Stake}_{old} + \text{Delta Fee Per Stake}
```
Token A and token B have separate cumulative values.
## Pending User Rewards
A user accrues new pending rewards only while their stake escrow is marked as in the top list.
```math theme={"system"}
\text{Unaccounted Fee Per Stake} =
\text{Current Cumulative Fee Per Stake} - \text{User Checkpoint}
```
```math theme={"system"}
\text{New Pending Fee} =
\left\lfloor
\frac{\text{User Active Stake} \times \text{Unaccounted Fee Per Stake}}
{2^{64}}
\right\rfloor
```
```math theme={"system"}
\text{User Pending Fee}_{new} =
\text{User Pending Fee}_{old} + \text{New Pending Fee}
```
```math theme={"system"}
\text{User Checkpoint}_{new} =
\text{Current Cumulative Fee Per Stake}
```
When a user enters the top-staker list, their checkpoints are set to the current cumulative values. When a user leaves the top-staker list, their pending rewards are updated before they are marked out.
## Claim and Restake
The vault knows which pool token is the stake mint. The stake-mint side is restaked; the quote-mint side is transferred to the user.
If token A is the stake mint:
```math theme={"system"}
\text{Restake Amount} = \text{Pending Fee A}
```
```math theme={"system"}
\text{Quote Claim Amount} = \min(\text{Pending Fee B}, \text{max\_fee})
```
If token B is the stake mint:
```math theme={"system"}
\text{Restake Amount} = \text{Pending Fee B}
```
```math theme={"system"}
\text{Quote Claim Amount} = \min(\text{Pending Fee A}, \text{max\_fee})
```
After claim:
```math theme={"system"}
\text{Active Stake}_{new} =
\text{Active Stake}_{old} + \text{Restake Amount}
```
The quote side can remain partially pending when `max_fee` is lower than the available quote reward. The stake-mint side is claimed in full and restaked.
## Total Active Stake
The vault's total active stake changes when users stake, claim restaked base rewards, request unstake, or cancel unstake.
```math theme={"system"}
\text{Total Active Stake}_{new} =
\text{Total Active Stake}_{old} + \text{Stake Amount}
```
```math theme={"system"}
\text{Total Active Stake}_{new} =
\text{Total Active Stake}_{old} + \text{Restake Amount}
```
```math theme={"system"}
\text{Total Active Stake}_{new} =
\text{Total Active Stake}_{old} - \text{Unstake Amount}
```
```math theme={"system"}
\text{Total Active Stake}_{new} =
\text{Total Active Stake}_{old} + \text{Canceled Unstake Amount}
```
## Unstake Cooldown
A requested unstake records a release time:
```math theme={"system"}
\text{Release Time} =
\text{Request Time} + \text{Unstake Lock Duration}
```
Withdrawal is allowed only when:
```math theme={"system"}
\text{Current Time} \geq \text{Release Time}
```
Production deployments enforce:
```math theme={"system"}
6 \text{ hours} \leq \text{Unstake Lock Duration} \leq 31 \text{ days}
```
Requested unstake amounts stop counting as active stake immediately. They do not earn rewards, do not help leaderboard rank, and cannot be withdrawn until the release time is reached.
## Rounding and Precision
Stake2Earn uses `2^64` scaling for fee-per-stake accounting, but all transfers and stored pending rewards are integer token amounts. Division rounds down. Small residual value can remain in cumulative accounting or locked-fee balances when released fees do not divide evenly across active top-list stake.
For interfaces, display rewards as estimates until claimed. Exact values depend on fee collection timing, drip timing, leaderboard state, active stake, token decimals, `max_fee`, and integer rounding.
# What is Stake2Earn?
Source: https://docs.meteora.ag/legacy-products/stake2earn/what-is-stake2earn
Learn how Stake2Earn routes DAMM v1 lock-escrow fees to top project-token stakers through leaderboard-based reward accounting.
## Overview
Stake2Earn is Meteora's legacy staking product for DAMM v1 pools. It lets holders stake a project's token into a vault and compete for a place in a configurable top-staker list. When the connected DAMM v1 lock escrow has claimable trading fees, the Stake2Earn vault can collect those fees and distribute the released amount to the current top stakers by stake weight.
Stake2Earn is not a fixed-emissions farm. Rewards come from pool fees that are actually collected from the configured lock escrow, then released over time according to the vault's drip settings.
Stake2Earn runs on the mainnet program `FEESngU3neckdwib9X3KWqdL7Mjmqk9XNp3uh5JbP4KP`.
Stake2Earn is a legacy product. This documentation is intended for teams, launchpads, integrators, and users who need to understand existing Stake2Earn deployments.
## Core Features
A vault is tied to one DAMM v1 constant-product pool and one lock escrow owned by the Stake2Earn vault.
Only the configured top stakers earn newly released fees. Production vaults support 5 to 1,000 eligible stakers.
Users stake the non-quote token from the pool. SOL and USDC are accepted only as quote mints, not as the stake mint.
Collected fees are stored as locked fees and released over the configured unlock duration instead of being distributed instantly.
Quote-token rewards are transferred to the user when claimed. Project-token fee rewards are added back into the user's active stake.
Requesting an unstake removes the amount from active stake immediately. The user can withdraw only after the cooldown expires.
## How Stake2Earn Works
```text theme={"system"}
DAMM v1 pool generates lock-escrow fees
|
Stake2Earn vault claims available lock-escrow fees
|
Claimed fees enter the vault's locked-fee balances
|
Fees drip to the current top-staker list
|
Top stakers accrue rewards by stake share
|
Users claim quote rewards; base rewards compound into stake
```
### Vault Setup
A Stake2Earn vault is initialized for one DAMM v1 constant-product pool. At a high level, the pool must contain:
| Role | Requirement |
| ----------- | --------------------------------------------------------------------------------------------------------------------- |
| Stake mint | The project token. It must not be one of the supported quote mints. |
| Quote mint | Wrapped SOL (`So11111111111111111111111111111111111111112`) or USDC (`EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v`). |
| Lock escrow | A DAMM v1 lock escrow for the pool whose owner is the Stake2Earn vault PDA. |
| Curve type | DAMM v1 `ConstantProduct`. |
See [Configuration and Limits](/legacy-products/stake2earn/configuration-and-limits) for the full setup requirements and production limits.
### Staking and Leaderboard Eligibility
Each user has a stake escrow for a specific vault. When the user stakes, project tokens move into the vault's stake token account and the user's active `stake_amount` increases.
Stake2Earn maintains two list accounts:
| List | Purpose | Production Limit |
| ----------------- | -------------------------------------------------------------------- | ---------------: |
| Top-staker list | Stakers currently eligible for newly released fees. | 1,000 |
| Full-balance list | Candidate list used to find users who can enter the top-staker list. | 10,000 |
Ranking is based on active stake amount. If two stakers have the same amount, the earlier full-balance-list index ranks higher.
### Fee Collection and Release
User actions such as staking, claiming, requesting unstake, and canceling unstake attempt to update fee accounting. There is also a permissionless crank instruction that can update vault fee accounting without a user stake escrow.
Collected fees are added to locked fee balances for token A and token B. After the configured fee distribution start time, locked fees drip over `seconds_to_full_unlock`. Released fees increase cumulative fee-per-stake accounting for the current top-staker list. See [Formulas](/legacy-products/stake2earn/formulas) for the exact release and reward math.
### Claiming Rewards
When a user claims:
* the vault first updates fee accounting;
* the user's pending token A and token B rewards are updated if they are currently in the top list;
* the quote-token portion is transferred to the user's quote token account, capped by the `max_fee` argument;
* the project-token portion is claimed in full and restaked into the user's active stake;
* the top-staker list is synced again because restaking can change the user's rank.
### Unstaking
Unstaking has two steps:
1. **Request unstake**: the requested amount is removed from active stake immediately and an `Unstake` account records the release time.
2. **Withdraw**: after `release_at`, the user can withdraw the unstaked tokens from the vault.
The user may also cancel an unstake before withdrawing. Canceling closes the `Unstake` account and returns that amount to active stake.
## Product Building Blocks
See supported tokens, count limits, timing ranges, admin-controlled updates, and operational edge cases.
Review the reward, drip, fee-per-stake, claim, and unstake formulas used by Stake2Earn.
## What Stake2Earn Is Not
* **Not a generic staking vault**: it is tied to one DAMM v1 pool and lock escrow.
* **Not LP staking**: users stake the project token, not LP tokens.
* **Not a fixed APY product**: rewards depend on trading fees, claim timing, release timing, and leaderboard position.
* **Not all-staker rewards**: only current top stakers accrue newly released fees.
* **Not instant-exit staking**: requested unstake amounts leave active stake immediately but cannot be withdrawn until the cooldown ends.
Staking does not guarantee rewards. A wallet earns newly released fees only while it is in the current top-staker list and the vault has released collected fees to distribute.
# Airdrop Disclaimer
Source: https://docs.meteora.ag/protocol/met/airdrop-disclaimer
Important Disclaimers And Acknowledgement of Terms of Use for the Airdrop Checker
**Please Read Carefully Before Checking Your Eligibility for the \$MET Airdrop**
By clicking the "Accept" button below, and using the \$MET airdrop eligibility checker ("**Airdrop Checker**"), you acknowledge and agree to the following:
***
## Applicable Terms and Conditions
Your access and use of the Airdrop Checker is governed by and subject to
**(i)** the Airdrop Terms and
**(ii)** the General Terms of Meteora's website. By clicking the "Accept" button below, you acknowledge and confirm that you have read and understood the Airdrop Terms and the General Terms, and that you agree to be bound by the Airdrop Terms and General Terms in respect of your access and use of the Airdrop Checker.
For avoidance of doubt, the Meteora Foundation is not a party to the Airdrop Terms, and shall not be responsible for any matters relating to the Tokens, any Airdrop Round, Airdrop Terms, the Airdrop Programme and the Airdrop Site.
***
## Purpose and Limitations
The Airdrop Checker is an informational tool provided solely to assist in assessing your preliminary eligibility for the \$MET airdrop programme. Results displayed by the Airdrop Checker do not guarantee final eligibility, participation, or any right to receive tokens or rewards. We reserve the right to disqualify participants who are suspected of fraudulent or illegal activities, bypassing eligibility checks, or failing to meet any eligibility criteria. We reserve the right to change our decisions (and accordingly, any results displayed by the Airdrop Checker) on or prior to the occurrence of the airdrop.
Any acquisition of tokens through third parties (including but not limited to exchanges or other holders) shall not establish any relationship of any kind between you and Meteora Comet Limited and/or its affiliates (“we”, “us”) and we expressly disclaim any and all responsibility or liability arising from or in connection with such transfers. Any acquisition of tokens is strictly at your own risk and does not give rise to any rights against us.
***
## No Guarantees or Warranties
The Airdrop Checker is provided “as is” without warranties, express or implied, regarding accuracy, completeness, or fitness for a particular purpose. We are not liable for any errors, omissions, or potential inaccuracies in the eligibility assessment provided by the Airdrop Checker, nor for any decisions or changes made on or prior to the occurrence of the airdrop that affect the results or accuracy of the eligibility assessment provided by the Airdrop Checker.
***
## Eligibility and Restrictions
The \$MET Airdrop may be restricted in certain jurisdictions. If you are not legally permitted to receive digital tokens in your country or region, you must not participate. You confirm that you are not a citizen or resident of a jurisdiction subject to sanctions or prohibitions on token distribution, or a citizen or resident of any named prohibited jurisdiction set out in our Airdrop Terms.
***
## Privacy and Data Usage
We may collect certain information when you use the Airdrop Checker, such as your wallet addresses or your past interactions with Meteora, to assess your eligibility for the token airdrop. For more information on how your data may be collected, used, disclosed and/or processed, please refer to our Privacy Policy. You hereby consent to the collection, usage, disclosure and processing of information relating to you, including without limitation, your personal data, in accordance with our Privacy Policy.
***
## User Responsibility and Security
Please note that it is your responsibility to ensure the security of your wallets, private keys, and other credentials when using the Airdrop Checker. We will never request your private keys, wallet seed phrases, or sensitive account information.
***
## Assumption of Risk
By using the Airdrop Checker, you assume all risks associated with its use and your reliance on its results. This tool is intended to provide general guidance only, and any actions you take based on its output are at your own risk.
***
**If you do not accept any of these terms, you may not use the Airdrop Checker.**
# Airdrop Terms and Conditions
Source: https://docs.meteora.ag/protocol/met/airdrop-terms-and-conditions
Read the terms governing participation, claims, eligibility, restrictions, taxes, disclaimers, and legal conditions for the $MET Airdrop Campaign.
The following Terms and Conditions (these "**Terms**") govern the participation of any person, individual or corporation eligible to participate ("**You**", "**Your**", "**Participant**") in the \$MET Airdrop Campaign launched by Meteora Comet Limited, a company incorporated in the British Virgin Islands ("**Company**").
Any person, individual or corporation which engages in any activity in connection with the \$MET Airdrop Campaign shall immediately be deemed a Participant and shall be deemed to have agreed to be bound by these Terms. These Terms shall be deemed entered into between the Participant and the Company each a "**Party**", collectively the "**Parties**".
If You do not agree or You do not accept these Terms unreservedly, You may not participate in the \$MET Airdrop Campaign and will not qualify to receive any \$MET in the \$MET Airdrop Campaign.
By accepting these Terms, You shall also be bound by any policies, instructions, schedules, guidelines, operating rules, supplementary terms and/or procedures which the Company may publish from time to time on the website at [https://met.meteora.ag/](https://met.meteora.ag/) and/or the Company's related social media channels (collectively the "**Public Channels**"), which are hereby expressly incorporated herein by reference. In accordance with Clause 7, the Company reserves all rights to disqualify Your participation.
The Company may revise these Terms at any time with or without notice to You by publishing the updated Terms on any of the Public Channels. These changes shall take effect from the date of upload, and Your continued participation in the \$MET Airdrop Campaign from such date shall be deemed to constitute Your acceptance of such revised Terms.
It shall be Your sole responsibility to check the Public Channels for such revisions from time to time. If you do not agree to these Terms, please do not participate in the \$MET Airdrop Campaign.
\$MET is not intended to constitute securities of any form, units in a business trust, units in a collective investment scheme or any other form of investment in any jurisdiction. This document and these Terms do not constitute a prospectus or offer document of any sort and are not intended to constitute an offer of securities of any form, units in a business trust, units in a collective investment scheme or any other form of investment, or a solicitation for any form of investment in any jurisdiction. No regulatory authority has examined or approved of these Terms. No such action has been or will be taken by the Company under the laws, regulatory requirements or rules of any jurisdiction. The provision of these Terms to You does not imply that the Applicable Laws, regulatory requirements or rules have been complied with.
In particular, \$MET:
**(a)** is not a loan to the Company or any Affiliate;
**(b)** does not provide the holder with any ownership or other interest in the Company or any Affiliate, or any other entity, enterprise or undertaking, or any kind of venture;
**(c)** is not intended to be a representation of currency or money (whether fiat or virtual or any form of electronic money), security, commodity, bond, debt instrument, unit in a collective investment scheme or any other kind of financial instrument or investment;
**(d)** is not intended to represent any rights under a contract for differences or under any other contract the purpose or pretended purpose of which is to secure a profit or avoid a loss;
**(e)** is not a commodity or asset that any person is obliged to redeem or purchase;
**(f)** is not any note, debenture, warrant or other certificate that entitles the holder to interest, dividend or any kind of return from any person;
**(g)** is not intended to be a security, commodity, financial derivative, commercial paper or negotiable instrument, or any other kind of financial instrument between the relevant holder and any other person, nor is there any expectation of profit; and
**(h)** is not an offer or solicitation in relation to gaming, gambling, betting, lotteries and/or similar services and products.
***
## Definitions
The following definitions shall apply in the interpretation of these Terms:
| Term | Definition |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **\$MET** | means the cryptographically-secure fungible protocol token of the Meteora protocol (as defined below), which is a transferable representation of attributed utility functions specified in the protocol/code of the Meteora protocol. |
| **Applicable Laws** | means with respect to each Party and any person, any and all applicable laws to which such Party or person is subject, including any and all jurisdictions which may apply. |
| **Affiliate** | means with respect to any person, any other person directly or indirectly controlling, controlled by or under common control with such person. |
| **Digital Wallet** | means the digital asset wallet that is compatible with the Solana blockchain network that the Participant shall use for the purpose of participation in the \$MET Airdrop Campaign. |
| **Indemnified Persons** | means the Company, the Company's group/affiliated entities as well as their respective past, present and future employees, officers, directors, contractors, consultants, equity holders, suppliers, vendors, service providers, parent companies, subsidiaries, Affiliates, agents, representatives, predecessors, successors and assigns. |
| **Meteora protocol** | means the decentralised Dynamic Liquidity Market Maker protocol (DLMM), as more particularly described at [https://docs.meteora.ag/overview/home](https://docs.meteora.ag/overview/home). |
***
**IT IS HEREBY AGREED:**
***
## 1. Participation in \$MET Airdrop Campaign
**1.1.** The Company is launching the \$MET Airdrop Campaign solely for the purpose of increasing awareness of the Meteora protocol, and to encourage users to participate in the Meteora protocol. Participants which successfully participate in the \$MET Airdrop Campaign shall be eligible to receive \$MET in their respective Digital Wallet when the same is distributed at the Company's discretion. You agree and accept that the \$MET Airdrop Campaign shall in no way be construed as a sale of \$MET or any other digital asset. Participants are responsible for ensuring that the Digital Wallet utilised to participate in the \$MET Airdrop Campaign is a self-hosted digital wallet (do NOT utilise an address from an exchange or custodial wallet service as \$MET will be delivered to this address).
**1.2.** The \$MET Airdrop Campaign shall run for a duration of approximately 68 weeks from **31 January 2024** to **30 June 2025**, or such other period as may be specified by the Company at its sole discretion ("**Campaign Duration**").
**1.3.** In order to be eligible for the \$MET Airdrop Campaign, by the last day of the Campaign Duration, Participants should have met any one of the following requirements, including any qualifying conditions as may be determined by the Company from time to time:
**(a)** Qualify as a liquidity provider of the Meteora protocol in accordance with the "LP Stimulus Plan", including DLMM (Dynamic Liquidity Market Maker) beta users and long-term liquidity providers;
**(b)** Qualify as an eligible "Bin Array Creator" for DLMM pools on the Meteora protocol;
**(c)** Participate in the Launchpad / Launchpool ecosystem on the Meteora protocol, based on on-chain trading fees and points earned, as well as integrations with the Meteora protocol;
**(d)** Qualify as a token creator who used Meteora's DBC (Dynamic Bonding Curve) technology;
**(e)** Qualify as an expert or active contributor of the Meteora protocol, based on contributions to underlying software for the Meteora protocol, the Meteorites community, or key roles in the protocol's Discord channel;
**(f)** Qualify as a "Mercurial Stakeholder" in accordance with the "Meteora Plan";
**(g)** Qualify as an "M3M3 Stakeholder" in accordance with the "Phoenix Rising Plan"; and
**(h)** Qualify as a "JUP Staker" in accordance with the "Phoenix Rising Plan"
**1.4.** The Company reserves the right to prescribe, at its sole discretion, such other qualifying conditions or restrictions on a user's participation in the \$MET Airdrop Campaign, modify the weightage allocated to any specific condition/task, or to disqualify or prohibit any person from participating or qualifying in any aspect of the \$MET Airdrop Campaign for any reason, including without limitation due to a user engaging in Disqualifying Conduct (defined below).
**1.5.** There are limited numbers of \$MET available for distribution to Participants in the \$MET Airdrop Campaign, so it will be distributed on a "first-come-first-served" basis.
**1.6.** The Participant acknowledges that the Company reserves the right to suspend, modify, restrict, cancel, withdraw or amend any aspect of the \$MET Airdrop Campaign at its sole discretion without liability to any person.
**1.7.** Each Participant who enters or participates in any aspect of the \$MET Airdrop Campaign represents and acknowledges, without limitation or qualification, that all determinations or decisions made by the Company for the purposes of the \$MET Airdrop Campaign are final and binding. The Company shall not entertain any requests for appeal or review. In particular, the Participant acknowledges and accepts that despite any Participant satisfying all prescribed qualifying conditions / restrictions, the Company shall have the sole discretion to decline to deliver \$MET to such Participant for any reason whatsoever.
***
## 2. Claims Process
**2.1.** Participants may claim awarded \$MET from the relevant underlying smart contract or technical service for \$MET Airdrop Campaign during the “Claim Period”, which starts from 23rd October 2025 until the expiry date on 23rd April 2026. The expiry date will be six (6) months after the start date of 23rd October 2025. Participants may claim \$MET by connecting their Digital Wallet enabling access to the Participant's Digital Wallet address as notified to the Company under 1.1, approving the relevant smart contract permissions as prompted, and calling a "Claim" function in accordance with the Company’s procedures. Any unclaimed \$MET Tokens after the aforementioned claim period shall no longer be available for claim, and shall be dealt with by the Company at its sole and absolute discretion.
**2.2.** Each Participant shall pay for all blockchain network fees or "gas" which may be required to call a "Claim" function for \$MET, or otherwise interacting with any underlying smart contracts deployed on a blockchain network; such fees are typically payable each time a Participant initiates the request to claim \$MET.
**2.3.** Participants are responsible for implementing all reasonable and appropriate measures for securing the Digital Wallet, vault or other storage mechanism that Participants use to store \$MET, including any requisite private key(s) or other credentials necessary to access such storage mechanism(s). If a Participant’s private key(s) or other access credentials are lost, such Participant may lose access to \$MET. The Company shall not be responsible for any security measures relating to the Participant’s receipt, possession, storage, transfer or potential future use of \$MET nor shall the Company be under any obligation to recover or return any such \$MET and the Company hereby excludes (to the fullest extent permitted under Applicable Laws) any and all liability for any security breaches or other acts or omissions which result in the Participant’s loss of (including loss of access to) \$MET airdropped to the Participant under these Terms. In the event of any loss, hack or theft of \$MET, each Participant acknowledges and confirms that it shall have no right(s), claim(s) or causes of action in any way whatsoever against the Company, its Affiliates, representatives, employees, directors and agents.
***
## 3. Representations, Warranties and Undertakings
**3.1.** You, the Participant, agree, represent and warrant that:
**(a)** You have read and understood the provisions of these Terms, including all relevant schedules and annexes that may be attached hereto;
**(b)** You have full power and authority to enter into and give effect to Your obligations and undertakings under these Terms, and in the case where You are a corporation or acting on behalf of a corporation:
**(i)** the corporation is a duly organised and validly existing corporation in its place of incorporation and it is not in receivership or liquidation or judicial management or any analogous situation; and
**(ii)** the corporation has full power and authority to enter into and give effect to its obligations under these Terms and all corporate steps required to give effect to the entry of these Terms have been properly taken.
**(c)** these Terms constitute a legal and binding obligation and undertaking, and may be enforced to the full extent of the law;
**(d)** where required, You have approved any approvals under any Applicable Laws for the participation in the \$MET Airdrop Campaign;
**(e)** any expenses that the You may incur in observing these Terms shall be at Your own expense and cost;
**(f)** You have not engaged in Disqualifying Conduct;
**(g)** You understand that and no materials, commentary, content provided by the Company and/or the Indemnified Parties shall be considered financial advice, and any financial advice sought by the You in relation to Your participation in the \$MET Airdrop Campaign shall be at Your own costs and expense;
**(h)** You are responsible and shall bear all expenses and costs involved (including but not limited to accountant fees) in determining the tax implications in Your participation of the \$MET Airdrop Campaign and the observance of these Terms;
**(i)** You are responsible for ensuring that Your Digital Wallet is functional and the keys for such, secure, and that it is Your responsibility to contact the Company through the appropriate avenue to resolve any issue with the Digital Wallet;
**(j)** You have a good understanding of the operation, functionality, usage, storage, transmission mechanisms and all material characteristics of cryptocurrencies, blockchain-based software systems, cryptocurrency wallets or other related token storage mechanisms, blockchain technology, smart contract technology, and staking mechanism, technology or services;
**(k)** You or (if participating on behalf of a corporation) any of the corporation's related corporations, directors, officers, employees, agents or any person acting on the corporation's behalf is NOT an individual or entity that is or is owned or controlled by an individual or entity that ("**Sanctioned Persons**"):
**(i)** is listed by the \[British Virgin Islands Financial Services Commission] or the Monetary Authority of Singapore as "designated", "sanctioned", "prohibited" or "restricted" (or with other similar terminology) individuals or entities defined in the respective regulations promulgated under the Monetary Authority of Singapore Act (Chapter 186) of Singapore, the United Nations Act (Chapter 339) of Singapore or the Terrorism (Suppression of Financing) Act (Chapter 325) of Singapore or such other law, regulation or rule as may be prescribed by any relevant authority;
**(ii)** is currently the subject of any sanction administered by the United States Office of Foreign Assets Control of the United States Department of the Treasury ("**OFAC**") or any other United States government authority, is not designated as a "Specially Designated National" or "Blocked Person" by OFAC or subject to any similar sanctions or measures imposed or administered by the United Nations Security Council, the European Union, or similar sanctions administered or imposed by any other country (collectively, the "**Sanctions**");
**(iii)** is located, organised or resident in a country or territory that is the subject of such Sanctions (including, without limitation, the Democratic People's Republic of Korea, the Democratic Republic of Congo, Eritrea, Iran, Libya, Somalia, South Sudan, Sudan and Yemen); or
**(iv)** has engaged in and is not now engaged in any dealings or transactions with any government, person, entity or project targeted by, or located in any country or territory, that at the time of the dealing or transaction is or was the subject of any Sanctions.
**(l)** You are not a citizen, resident (tax or otherwise), domiciliary and/or green card holder or other similar certificate of residency of a country (i) where holding tokens, trading tokens, or participating in token sales or distribution, whether as a purchaser or a seller, is prohibited, restricted or unauthorised by applicable laws, decrees, regulations, treaties, or administrative acts, or (ii) where it is likely that the distribution of \$MET would be construed as the sale of a security (howsoever named), financial service or investment product (including without limitation the United States of America, Canada, the People's Republic of China, Democratic People's Republic of Korea, Cuba, Syria, Iran, Sudan, and the People's Republic of Crimea (each a **Restricted Territory**)), nor are you acquiring \$MET from any Restricted Territory, nor are you an entity (including but not limited to any corporation or partnership) incorporated, established or registered in or under the laws of a Restricted Territory, nor are you acquiring \$MET on behalf of any person or entity from a Restricted Territory.
**3.2.** You are aware of and agrees that the \$MET Airdrop Campaign generally involves significant risk, and You hereby agree to accept the full consequences of all risks that may arise during, before, after and in connection to:
**(a)** your participation in the \$MET Airdrop Campaign and the distribution of \$MET;
**(b)** any loss of digital assets in your Digital Wallet;
**(c)** the use of \$MET in Meteora protocol, any other blockchain network, or for any other purpose;
**(d)** any potential delay, postponement, suspension, modification or abandonment of the \$MET Airdrop Campaign.
**3.3.** The list under Clause 3.2 shall not be regarded as an exhaustive list of the potential risks associated with Your participation in the \$MET Airdrop Campaign and You agree to accept full responsibility for Your own knowledge of all risks that may arise.
**3.4.** The Company does not take any responsibility for any circumstance or event that may prevent a person from participating in the \$MET Airdrop Campaign as a result of technical restrictions, issues, or other limitations such as force majeure, which include (but are not limited to) regulatory considerations, government directives, and government intervention of whatsoever nature.
***
## 4. Disclaimers of Warranties
**4.1.** The Company hereby disclaims and does not provide a warranty of any kind, whether implied, express or statutory, including but not limited to the respect of the matters listed in Clause 4.2. Where the Applicable Laws does not allow the disclaimer or exclusion of such warranties, the defective disclaimer shall apply to the full extent as permitted by the Applicable Laws.
**4.2.** You hereby and expressly agree that Your participation in the \$MET Airdrop Campaign is at Your sole risk and agree that in no event shall the Company be liable to You, or any corporation or entity You represent, for any of the following:
**(a)** any interruption, error, defect, flaw or unavailability of the \$MET Airdrop Campaign;
**(b)** any fraudulent or illegal use of Your Digital Wallet, or any loss of possession and destruction of Your private keys of any wallet;
**(c)** Your inability to participate in the \$MET Airdrop Campaign or any transactions You may undertake in connection with the same;
**(d)** any virus, malware, trojan or similar that may affect \$MET, Meteora protocol, or Your devices from use of any resources provided by the Company, despite the Company's best reasonable precautions in place to prevent as such;
**(e)** any delay, postponement, suspension or abortion of the \$MET Airdrop Campaign;
**(f)** the non-disclosure of information relating to the \$MET Airdrop Campaign;
**(g)** Your disqualification for failing to recognise Yourself as a Sanctioned Person or the failure of the Company to recognise You as such;
**(h)** any and all risks to You in Your participation in the \$MET Airdrop Campaign.
**4.3.** You agree that the Company may, at any time and in its absolute discretion, delay, postpone, suspend or abort the \$MET Airdrop Campaign for any reasons, including regulatory concerns or change in business strategy or goals. You agree that, where such should occur, neither the Company nor the Indemnified Parties would be liable for any loss (including but not limited loss of use, revenue, income, profits, damages) in accordance with Clause 9.
***
## 5. Information Provided to the Company
**5.1.** Each Participant shall ensure that any documents and information provided by such Participant in connection with its participation in the \$MET Airdrop Campaign is true, accurate and complete.
**5.2.** Where it occurs any event that may render such provided information under Clause 5.1 false, misleading, incomplete or altered, Participants shall, at the earliest possible, take such acts necessary to notify the Company and/or their Indemnified Parties of the event and corresponding change.
***
## 6. Taxes
The Parties shall seek their own advice on any tax that may be payable in connection with the performance of matter under these Terms. The Parties should be aware that this may include tax consequences including but not limited to tax reporting, income tax, transfer taxes and withholding tax. For the avoidance of doubt, the Company shall not be in any way reasonable for any claims, fines, penalties or other liabilities that any other party these Terms may incur.
***
## 7. Disqualification from Participating
**7.1.** The Company reserves the right, in its absolute discretion, to disqualify any participant from participation in the \$MET Airdrop Campaign, neither Company nor the Indemnified Parties would be liable for any losses or damages that may arise for such disqualification and in accordance with Clause 9.
**7.2.** Such situations of disqualification may include, but is not limited to, situations where such participant has encouraged, instigated and/or engaged in Disqualifying Conduct (defined below) that may be harmful to the Company. The Company reserves the right to take any action as necessary, including but not limited to legal proceedings, to protect the Company from the harm, losses, damage arising or connected to such conduct.
**7.3.** "**Disqualifying Conduct**" refers to exploitative, abusive and excessive conduct, and shall include but is not limited to, at the sole and full discretion and judgement of the Company:
**(a)** Acquiring, creating or controlling multiple user accounts, identities or Digital Wallet addresses in connection with participation in the \$MET Airdrop Campaign or any aspect of Meteora protocol, or otherwise participating in any Sybil attack or "farming" in connection with the \$MET Airdrop Campaign or Meteora protocol;
**(b)** Introducing or using any malware, virus, trojan horses or other material that may alter or be harmful to technology in any way;
**(c)** Gain and/or engage in unauthorised excess and use of any materials of the Company and its Indemnified Parties;
**(d)** Interfering with the operation of \$MET Airdrop Campaign;
**(e)** Impersonating the Company and/or the Indemnified Parties (such as but not limited to the use of e-mail or screen names); or
**(f)** Using any materials produced for the \$MET Airdrop Campaign in a way that is inappropriate and violates any Applicable Laws.
**7.4.** The Company reserves the right to implement the measures it deems necessary and fit to ensure that any Participant that has engaged in Disqualifying Conduct does not have access to the \$MET Airdrop Campaign.
***
## 8. Disclosure of Information
**8.1.** The Company does not warrant the completeness and accuracy of any information relating to the Company, the \$MET Airdrop Campaign that is online, which may originate from but not limited to the following:
**(a)** the website [https://www.meteora.ag/](https://www.meteora.ag/), [https://met.meteora.ag/](https://met.meteora.ag/) and all related sub-domains;
**(b)** the X (prev Twitter) account [https://x.com/meteoraag](https://x.com/meteoraag);
**(c)** the Discord channel [https://discord.gg/meteora](https://discord.gg/meteora);
**(d)** any website or other social media channels directly or indirectly linked to the Company.
**8.2.** You hereby agree that the Company and/or its Indemnified Parties shall be free of any liability arising from any reliance on such materials.
**8.3.** In the event of any conflict or inconsistency between these Terms and any other information, social media posting, brochure, marketing or promotional material relating to the \$MET Airdrop Campaign, these Terms shall prevail.
***
## 9. Liability and Indemnity
**9.1.** To the fullest extent permitted by law, the Company hereby expressly disclaims its liability for any loss incurred or suffered by You or any person in connection with the \$MET Airdrop Campaign, for:
**(a)** any and all changes to the operations, management and organisation of the \$MET Airdrop Campaign including but not limited to any potential delay, postponement, suspension or abandonment of the \$MET Airdrop Campaign as well as calculation of airdrop amounts generally or in any specific case;
**(b)** any mistake or error in delivery or in connection with \$MET due and any subsequent changes to the type or value of, or issues affecting, \$MET (if any);
**(c)** failure, malfunction or breakdown of, or disruption to, the operations of the Company, the Meteora protocol, or any other technology (including but not limited to any smart contract technology), due to any reason, including but not limited to occurrences of hacks, mining attacks (including without limitation double-spend attacks, majority mining power attacks and "selfish-mining" attacks), cyber-attacks, distributed denials of service, errors, vulnerabilities, defects, flaws in programming or source code or otherwise, regardless of when such failure, malfunction, breakdown, or disruption occurs;
**(d)** any virus, error, bug, flaw, defect or otherwise adversely affecting the \$MET Airdrop Campaign or your participation in \$MET Airdrop Campaign;
**(e)** Your failure to disclose information relating to the \$MET Airdrop Campaign at the request of the Company;
**(f)** any prohibition, restriction or regulation by any government or regulatory authority in any jurisdiction applicable to the \$MET Airdrop Campaign or Your participation in \$MET Airdrop Campaign; and
**(g)** all risks, direct, indirect or ancillary, associated with your participation in the \$MET Airdrop Campaign, the Company and/or the Meteora protocol, whether or not expressly stated in these Terms.
**9.2.** To the fullest extent permitted by Applicable Laws, You will indemnify, defend and hold harmless the Company and/or the Indemnified Parties from and against any and all claims, demands, actions, liabilities, costs, expenses for any type of loss (including but is not limited to damages, fines, punitive damages, personal injury, pain and suffering, emotional distress, revenue and profit loss, business and anticipated savings loss and data loss) that may arise in any kind (in tort, contract or otherwise), directly, indirectly, incidental or consequential, from or in connection with the matters dealt with and described in these Terms, including:
**(a)** losses that may be incurred by actions taken by the Company and/or Indemnified Parties against participants engaged in Disqualifying Conduct under Clause 7.3; and
**(b)** any loss that may be incurred as a result of the classification of the Participant as a Sanctioned Person as described under Clause 3.1(k).
**9.3.** You hereby agree that You waive all rights to assert any claims against the Company and/or the Indemnified Parties under any Applicable Laws. This shall include the right to participate in any class action lawsuit or class wide arbitration against the Company, the Indemnified Parties and/or any other Participant and/or any companies related through common ownership or control at any point in time.
***
## 10. Intellectual Property
**10.1.** You acknowledge and agree that save as otherwise indicated in writing, the Company (or, as applicable, its licensor(s)) owns all legal right, title and interest in and all intellectual property and all elements of \$MET and Meteora protocol, or any underlying websites in connection with the distribution and/or usage of \$MET and Meteora protocol, including, without limitation all art, designs, systems, methods, information, computer code, software, services, website design, "look and feel", organisation, compilation of the content, code, data and database, functionality, audio, video, text, photograph, graphics, and all other elements of the same (collectively, the "**Content**").
**10.2.** You acknowledge that the Content are protected by copyright, trade dress, patent, and trademark laws, international conventions, other relevant intellectual property and proprietary rights, and applicable laws. All Content are the copyrighted property of the Company (or, as applicable, its licensor(s), and all trademarks, service marks, and trade names associated with \$MET and Meteora protocol are proprietary to the Company or its licensor(s). Except as expressly set forth herein, your receipt or use of \$MET and Meteora protocol does not grant you ownership of or any other rights with respect to the aforesaid Content.
**10.3.** The Company reserves all rights in and to the Content that are not expressly granted to you in these Terms. In particular, you understand and agree that:
**(a)** your usage of \$MET and Meteora protocol does not give you any rights or licenses in or to the Content (including, without limitation, the Company's copyright in and to the associated art) other than those expressly contained in these Terms;
**(b)** you do not have the right, except as otherwise set forth in these Terms, to reproduce, distribute, or otherwise commercialise any elements of the Content (including, without limitation, any art) without the Company's prior written consent in each case, which consent may be withheld at the Company's sole and absolute discretion;
**(c)** you will not apply for, register, or otherwise use or attempt to use any \$MET or Meteora protocol trademarks or service marks, or any confusingly similar marks, anywhere in the world without the Company's prior written consent in each case, which consent may be withheld at the Company's and absolute discretion; and
**(d)** \$MET and Meteora protocol may potentially include intellectual property elements provided by third parties that are subject to separate ownership and/or license terms, in which case those terms will govern such intellectual property rights.
***
## 11. Third Party Online Products and Services
**11.1.** The Public Channels may contain links to third-party websites and services which are owned and operated by third parties ("**Third Party Online Products and Service(s)**"). These links are provided for Your information and convenience only, and are NOT an endorsement by the Company, its directors, officers, employees, agents, successors, and permitted assignees of the contents of such linked websites or third parties, over which none of the aforementioned entities have any control over.
**11.2.** Your access to and use of any Third Party Online Products and Service(s) is governed by the terms, conditions, disclaimers and notices found on each such website or in connection with such Third Party Online Products and Service(s). The Company has not verified, will not, and is under no obligation to verify the accuracy, suitability or completeness of the contents on such Third Party Online Products and Service(s), and the Company does not control, endorse, warrant, promote, recommend or in any way assume responsibility or liability for any services or products that may be offered by or accessed through such Third Party Online Products and Service(s) or the operators of them, or the suitability or quality of any of such Third Party Online Products and Service(s).
**11.3.** In addition, the Company does not warrant that such Third Party Online Products and Service(s) or the software, data or files contained in, accessed via or linked or referred to in, such Third Party Online Products and Service(s) are free of viruses (or other deleterious data or programs) or defects or that use of such Third Party Online Products and Service(s) will not cause harm or that they conform or will conform with any user expectations. Furthermore, the Company is not responsible for maintaining any materials referenced from another website, and makes no warranties for that website or service in such context.
***
## 12. Company's Remedies
**12.1.** If any Participant breaches any provision in these Terms or is discovered or deemed to be ineligible or disqualified for the \$MET Airdrop Campaign for any reason, the Company is entitled at any time:
**(a)** to withdraw, withhold, or require the forfeiture of any \$MET; or
**(b)** where the \$MET has been delivered to the Participant, to reclaim such \$MET and/or claim liquidated damages from the Participant in an amount of two (2) times the market value of such \$MET.
**12.2.** Upon the occurrence of the above, no person shall be entitled to any payment or compensation from the Company.
***
## 13. Assignment
**13.1.** You may not assign or transfer all or part of its rights or obligations under these Terms without the prior written consent of the Company. The Company may refuse to recognise any such assignment, transfer or any other transaction resembling such.
**13.2.** The Company may assign, as it sees fit and in its full discretion, any of its rights, obligations and duties under these Terms.
***
## 14. No Waiver
**14.1.** The Company's failure or delay to exercise or enforce any right or provision of these Terms will not operate as a waiver of such right or provision, nor will any single or partial exercise of any right or remedy preclude any other or further exercise thereof or the exercise of any other right or remedy.
**14.2.** Any provision in these Terms may be waived by written and signed consent of the Company. A waiver of any provision or terms shall not be deemed a waiver of any breach of the provision or term, or any other provision or term. For the avoidance of doubt, the Company may waive, by written and signed consent, any breach by any other Party to these Terms.
***
## 15. Governing Law and Dispute Resolution
**15.1.** These Terms are governed by the laws of Singapore, without regard to conflict of law rules or principles (whether of Singapore or any other jurisdiction) that would cause the application of the laws of any other jurisdiction.
**15.2.** Any dispute arising out of or related to these Terms, as well as any issue on its validity and existence, shall be referred to and finally resolved by confidential, arbitration administered in accordance with the BVI IAC Arbitration Rules for the time being in force, which rules are deemed to be incorporated by reference in this Clause 15. The place of arbitration shall be Road Town, Tortola, British Virgin Islands, unless the parties agree otherwise. The tribunal shall consist of 1 arbitrator agreed to by the parties within twenty (20) business days of receipt by the respondent of the request for arbitration or, in default thereof, appointed by the British Virgin Islands International Arbitration Centre in accordance with its prevailing rules. The arbitrator shall have exclusive authority to decide all issues relating to the interpretation, applicability, enforceability and scope of this arbitration agreement. The language of the arbitration shall be English. Each party irrevocably submits to the jurisdiction and venue of such tribunal. Judgment upon the award may be entered by any court having jurisdiction thereof or having jurisdiction over the relevant party or its assets.
***
## 16. Entire Agreement
These Terms set forth the entire agreement and understanding between the Parties in connection with the matters dealt with and described herein, and supersedes all prior oral and written agreements, memoranda, understandings and undertakings between the Parties in connection with the matters dealt with and described herein.
***
## 17. Rights of Third Parties
Save as expressly provided for in these Terms, a person who is not a party to these Terms has no right under any law of any jurisdiction to enforce or to enjoy the benefit of any term of these Terms.
***
## 18. Invalidity and Severance
If any provision of these Terms shall be held to be illegal, void, invalid or unenforceable, the provision shall be deemed illegal, void, invalid or unenforceable to that extent. The remaining provisions of these Terms shall remain fully valid, legal and enforceable to the extent that they are unaffected by the defective provision, and the illegality, invalidity or unenforceability of the defective provision in one jurisdiction does not affect its legality, validity and enforceability under any other jurisdiction. The Parties agree to use all commercially reasonable efforts to explore other means of achieving the same result as if the provision had been entirely valid, legal and enforceable.
# FAQ
Source: https://docs.meteora.ag/protocol/met/faq
Frequently asked questions about the Meteora Token Generation Event (TGE)
## Overview
A Token Generation Event is when a project's token is first created on-chain and becomes claimable/tradable. It's the "go-live" for supply and distribution.
23rd October 2025. Exact time will be posted on Meteora's official socials.
Solana.
SPL token. Contract address will be posted only in our official channels at TGE.
## Eligibility
Eligibility is based on points, LP activity, off chain contributions and more. Points are finalised.
On Meteora's official claim page. Connect your wallet to view eligibility and allocation. Make sure to check the link properly.
JUP Stakers will automatically be opted in for a Liquidity Distributor NFT position (3% of supply). The remaining 7% will go to other eligible users on a first come first serve basis, capping the total Liquidity Distributor NFT supply at 10%.
## Claim Process
1. Open the official TGE claim site from our announcements in discord or 𝕏
2. Connect a supported wallet (e.g. Phantom, Jup Mobile, Solflare…)
3. Review your allocation
4. Approve the on-chain transaction to claim. Typical Solana claim UX follows this pattern
Phantom/Backpack/Jupiter/Solflare etc. Make sure to keep your wallet/app updated.
You will need to manually select "Claim MET".
Yes. Claiming your allocation is an on-chain process and gas fees are required (Typically \~0.02 SOL). A small amount of SOL is also required to create your token account for MET.
## Trading, Liquidity & Listing
Initial liquidity will be on the Meteora DAMM v2 pool. Other listings, if any, will be announced separately.
Early trading can be volatile. Confirm slippage settings, check pool TVL/depth, and beware price impact on large orders.
## Security & Official Links
* Only use links from Discord Announcements, 𝕏 Page and our official website
* Never DM seed phrases/private keys
* Never click links in tweets from impersonator accounts
* Be cautious of fake token/NFT's airdropped to your wallet
* Confirm the exact token mint address from our channels before swapping
## Token Details
Posted at TGE in announcements and on the claim page. Do not trust addresses posted elsewhere.
## Points / Airdrops
Allocations are final. If you believe there’s a technical error on the UI, open a support ticket with wallet + tx links. (See [support policy](#support-policy) below.)
If you're a JUP Staker, you'll automatically be opted in for a Liquidity Distributor NFT that can be withdrawn at any time when trading goes live. If you are another eligible airdrop recipient, you can decide to get your MET allocation or the NFT position value. The NFT supply is capped at 10% of total MET supply and on a first come first serve basis.
## Liquidity Distributor NFT & Launch Pool
The Liquidity Distributor NFT represents your position in the DAMMv2 launch pool relative to the percentage of the total supply of MET you own. When you close your position from the initial launch DAMMv2 pool the NFT transfers out of your wallet in exchange for your percentage of liquidity within it.
10% of total MET supply. 3% of this supply will be auto opted in for JUP Stakers. The remaining 7% will be on a first come first serve basis.
Within the DAMMv2 pool, a fee is charged based on swaps. Since the pool is single sided MET you will earn fees when someone swaps their USDC for MET. The pool fees start high and drastically decline overtime through a fee scheduler.
All JUP Stakers are automatically opted in. The remaining 7% supply will be on a first come first serve basis prior to TGE.
On the official TGE site [https://met.meteora.ag](https://met.meteora.ag). The date of claim will be announced on our official socials.
No, you do not need to rush to claim nor will you miss out on fees claiming your NFT later than everyone. Your fees will still be generating in the pool even if you don't claim them immediately at launch.
Unless you're a JUP Staker, that choice is ultimately yours.
No. You can withdraw your position at any time once trading starts.
No. Leave it for as long as you like.
If you selected a Liquidity Position NFT before TGE, no further action is required. Your position will automatically be represented in the pool earning fees. Once you select claim NFT on the site, you are free to manage your position as you wish.
You will receive your share of liquidity in the pool. This may be a mix of MET and USDC, or primarily MET, depending on pool activity.
Yes. Once you've signed and confirmed your registration to switch your MET token allocation to MET liquidity Distributor NFT, you cannot change your choice.
The allocation is capped at 10% of the total supply (100M). However, this limit may be slightly exceeded to accommodate the final deposit, as a minimal overflow is permitted for the last depositor.
Until Sunday, 19 October, 23:00 UTC+8
The MET airdrop claim window closes on 23/01/2026 1 PM UTC. Make sure to claim your tokens before this deadline.
## Support Policy
You can submit a ticket through our [Discord](https://discord.com/invite/meteora) channel. Include:
* Wallet address
* Transaction links (Solscan)
* Device/wallet versions
* Screenshots
* A brief description of your issue
During TGE volumes are high; we'll triage by severity. Please avoid duplicate tickets.
## Troubleshooting
* Check that you’re on the correct wallet and network (Solana).
* Ensure you have SOL for fees.
* Refresh and retry; if it persists, open a ticket with your wallet + tx link.
* For swaps, check slippage, pool TVL, and whether a token has transfer fees (some tokens do enable them).
* Try switching to a different RPC.
Add the token mint address manually or refresh assets.
Try increasing the priority fee caps. If the default/attached priority fee is too low, validators may ignore the transaction during periods of network congestion. If that doesn't work, try switching the RPCs (this can be done by going to "settings").
In times of network congestion, the priority fee required to land the transaction may increase up to a limit set by the user. Set a priority fee cap that is within your budget.
To avoid such failures, it is recommended to maintain at least 0.05 SOL in your wallet at all times. This buffer covers base fees and potential additional fees for most transactions.
No, if a transaction fails, no funds will be deducted.
It is possible that even if a transaction simulation fails, the actual transaction might still be successful. Check if the transaction went through on block scanners (e.g. [https://solscan.io/](https://solscan.io/)).
## Tokenomics
Total supply: 1,000,000,000 tokens. Initial circulating supply: 480,000,000 tokens.
10% of total supply.
The pool range where liquidity is added is from \$0.50 to \$7.50 (\$500M to \$7.5B FDV).
## Compromised Wallets
If your wallet is compromised, you have the option to report your wallet and forfeit all MET allocations tied to the wallet. There is no option to submit a new address.
# Airdrop Disclaimer
Source: https://docs.meteora.ag/protocol/met/s2-airdrop-disclaimer
Important Disclaimers And Acknowledgement of Terms of Use
**Please Read Carefully Before Checking And Claiming Your \$MET Airdrop**
By clicking the "Accept" button below, and using the \$MET airdrop eligibility checker ("**Airdrop Checker**") on the Campaigns page [https://www.meteora.ag/campaigns](https://www.meteora.ag/campaigns), you acknowledge and agree to the following:
***
## Applicable Terms and Conditions
Your access and use of the Airdrop Checker is governed by and subject to
**(i)** the Airdrop Terms and
**(ii)** the General Terms of Meteora's website. By clicking the "Accept" button below, you acknowledge and confirm that you have read and understood the Airdrop Terms and the General Terms, and that you agree to be bound by the Airdrop Terms and General Terms in respect of your access and use of the Airdrop Checker.
For avoidance of doubt, the Meteora Foundation is not a party to the Airdrop Terms, and shall not be responsible for any matters relating to the Tokens, any Airdrop Round, Airdrop Terms, the Airdrop Programme and the Airdrop Site.
***
## Purpose and Limitations
The Airdrop Checker is an informational tool provided solely to assist in assessing your preliminary eligibility for the \$MET airdrop programme. Results displayed by the Airdrop Checker do not guarantee final eligibility, participation, or any right to receive tokens or rewards. We reserve the right to disqualify participants who are suspected of fraudulent or illegal activities, bypassing eligibility checks, or failing to meet any eligibility criteria. We reserve the right to change our decisions (and accordingly, any results displayed by the Airdrop Checker) on or prior to the occurrence of the airdrop.
Any acquisition of tokens through third parties (including but not limited to exchanges or other holders) shall not establish any relationship of any kind between you and Meteora Comet Limited and/or its affiliates (“we”, “us”) and we expressly disclaim any and all responsibility or liability arising from or in connection with such transfers. Any acquisition of tokens is strictly at your own risk and does not give rise to any rights against us.
***
## No Guarantees or Warranties
The Airdrop Checker is provided “as is” without warranties, express or implied, regarding accuracy, completeness, or fitness for a particular purpose. We are not liable for any errors, omissions, or potential inaccuracies in the eligibility assessment provided by the Airdrop Checker, nor for any decisions or changes made on or prior to the occurrence of the airdrop that affect the results or accuracy of the eligibility assessment provided by the Airdrop Checker.
***
## Eligibility and Restrictions
The \$MET Airdrop may be restricted in certain jurisdictions. If you are not legally permitted to receive digital tokens in your country or region, you must not participate. You confirm that you are not a citizen or resident of a jurisdiction subject to sanctions or prohibitions on token distribution, or a citizen or resident of any named prohibited jurisdiction set out in our Airdrop Terms.
***
## Privacy and Data Usage
We may collect certain information when you use the Airdrop Checker, such as your wallet addresses or your past interactions with Meteora, to assess your eligibility for the token airdrop. For more information on how your data may be collected, used, disclosed and/or processed, please refer to our Privacy Policy. You hereby consent to the collection, usage, disclosure and processing of information relating to you, including without limitation, your personal data, in accordance with our Privacy Policy.
***
## User Responsibility and Security
Please note that it is your responsibility to ensure the security of your wallets, private keys, and other credentials when using the Airdrop Checker. We will never request your private keys, wallet seed phrases, or sensitive account information.
***
## Assumption of Risk
By using the Airdrop Checker, you assume all risks associated with its use and your reliance on its results. This tool is intended to provide general guidance only, and any actions you take based on its output are at your own risk.
***
**If you do not accept any of these terms, you may not use the Airdrop Checker.**
# Airdrop Terms and Conditions
Source: https://docs.meteora.ag/protocol/met/s2-airdrop-terms
Read the terms governing participation, claims, eligibility, restrictions, taxes, disclaimers, and legal conditions for the $MET Airdrop Campaign.
**Last updated: 20 July 2026**
The following Terms and Conditions (these "**Terms**") govern the participation of any person, individual or corporation eligible to participate ("**You**", "**Your**", "**Participant**") in the \$MET Airdrop Campaign launched by Meteora Comet Limited, a company incorporated in the British Virgin Islands ("**Company**").
Any person, individual or corporation which engages in any activity in connection with the \$MET Airdrop Campaign shall immediately be deemed a Participant and shall be deemed to have agreed to be bound by these Terms. These Terms shall be deemed entered into between the Participant and the Company each a "**Party**", collectively the "**Parties**".
If You do not agree or You do not accept these Terms unreservedly, You may not participate in the \$MET Airdrop Campaign and will not qualify to receive any \$MET in the \$MET Airdrop Campaign.
By accepting these Terms, You shall also be bound by any policies, instructions, schedules, guidelines, operating rules, supplementary terms and/or procedures which the Company may publish from time to time on the website at [https://meteora.ag/](https://meteora.ag/) ,
[https://www.meteora.ag/campaigns](https://www.meteora.ag/campaigns) ,
and/or the Company's related social media channels (collectively the "**Public Channels**"), which are hereby expressly incorporated herein by reference. In accordance with Clause 7, the Company reserves all rights to disqualify Your participation.
The Company may revise these Terms at any time with or without notice to You by publishing the updated Terms on any of the Public Channels. These changes shall take effect from the date of upload, and Your continued participation in the \$MET Airdrop Campaign from such date shall be deemed to constitute Your acceptance of such revised Terms.
It shall be Your sole responsibility to check the Public Channels for such revisions from time to time. If you do not agree to these Terms, please do not participate in the \$MET Airdrop Campaign.
\$MET is not intended to constitute securities of any form, units in a business trust, units in a collective investment scheme or any other form of investment in any jurisdiction. This document and these Terms do not constitute a prospectus or offer document of any sort and are not intended to constitute an offer of securities of any form, units in a business trust, units in a collective investment scheme or any other form of investment, or a solicitation for any form of investment in any jurisdiction. No regulatory authority has examined or approved of these Terms. No such action has been or will be taken by the Company under the laws, regulatory requirements or rules of any jurisdiction. The provision of these Terms to You does not imply that the Applicable Laws, regulatory requirements or rules have been complied with.
In particular, \$MET:
**(a)** is not a loan to the Company or any Affiliate;
**(b)** does not provide the holder with any ownership or other interest in the Company or any Affiliate, or any other entity, enterprise or undertaking, or any kind of venture;
**(c)** is not intended to be a representation of currency or money (whether fiat or virtual or any form of electronic money), security, commodity, bond, debt instrument, unit in a collective investment scheme or any other kind of financial instrument or investment;
**(d)** is not intended to represent any rights under a contract for differences or under any other contract the purpose or pretended purpose of which is to secure a profit or avoid a loss;
**(e)** is not a commodity or asset that any person is obliged to redeem or purchase;
**(f)** is not any note, debenture, warrant or other certificate that entitles the holder to interest, dividend or any kind of return from any person;
**(g)** is not intended to be a security, commodity, financial derivative, commercial paper or negotiable instrument, or any other kind of financial instrument between the relevant holder and any other person, nor is there any expectation of profit; and
**(h)** is not an offer or solicitation in relation to gaming, gambling, betting, lotteries and/or similar services and products.
***
## Definitions
The following definitions shall apply in the interpretation of these Terms:
| Term | Definition |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **\$MET** | means the cryptographically-secure fungible protocol token of the Meteora protocol (as defined below), which is a transferable representation of attributed utility functions specified in the protocol/code of the Meteora protocol. |
| **Applicable Laws** | means with respect to each Party and any person, any and all applicable laws to which such Party or person is subject, including any and all jurisdictions which may apply. |
| **Affiliate** | means with respect to any person, any other person directly or indirectly controlling, controlled by or under common control with such person. |
| **Digital Wallet** | means the digital asset wallet that is compatible with the Solana blockchain network that the Participant shall use for the purpose of participation in the \$MET Airdrop Campaign. |
| **Indemnified Persons** | means the Company, the Company's group/affiliated entities as well as their respective past, present and future employees, officers, directors, contractors, consultants, equity holders, suppliers, vendors, service providers, parent companies, subsidiaries, Affiliates, agents, representatives, predecessors, successors and assigns. |
| **Meteora protocol** | means a set of programs including the decentralised Dynamic Liquidity Market Maker protocol (DLMM), as more particularly described at [https://docs.meteora.ag/get-started](https://docs.meteora.ag/get-started). |
***
**IT IS HEREBY AGREED:**
***
## 1. Participation in \$MET Airdrop Campaign
**1.1.** The Company is launching the \$MET Airdrop Campaign solely for the purpose of increasing awareness of the Meteora protocol, and to encourage users to participate in the Meteora protocol. Participants which successfully participate in the \$MET Airdrop Campaign shall be eligible to receive \$MET in their respective Digital Wallet when the same is distributed at the Company's discretion. You agree and accept that the \$MET Airdrop Campaign shall in no way be construed as a sale of \$MET or any other digital asset. Participants are responsible for ensuring that the Digital Wallet utilised to participate in the \$MET Airdrop Campaign is a self-hosted digital wallet (do NOT utilise an address from an exchange or custodial wallet service as \$MET will be delivered to this address).
**1.2.** The \$MET Airdrop Campaign shall run for a duration of approximately 52 weeks from **1 July 2025** to **30 June 2026**, or such other period as may be specified by the Company at its sole discretion ("**Campaign Duration**").
**1.3.** In order to be eligible for the \$MET Airdrop Campaign, by the last day of the Campaign Duration, Participants should have met any one of the following requirements, including any qualifying conditions as may be determined by the Company from time to time:
**(a)** Qualify as a liquidity provider of the Meteora protocol in accordance with the "LP Stimulus Season 2 Plan", including DLMM (Dynamic Liquidity Market Maker) and DAMM v2 (Dynamic AMM v2) long-term liquidity providers;
**1.4.** The Company reserves the right to prescribe, at its sole discretion, such other qualifying conditions or restrictions on a user's participation in the \$MET Airdrop Campaign, modify the weightage allocated to any specific condition/task, or to disqualify or prohibit any person from participating or qualifying in any aspect of the \$MET Airdrop Campaign for any reason, including without limitation due to a user engaging in Disqualifying Conduct (defined below).
**1.5.** There are limited numbers of \$MET available for distribution to Participants in the \$MET Airdrop Campaign, so it will be distributed on a "first-come-first-served" basis.
**1.6.** The Participant acknowledges that the Company reserves the right to suspend, modify, restrict, cancel, withdraw or amend any aspect of the \$MET Airdrop Campaign at its sole discretion without liability to any person.
**1.7.** Each Participant who enters or participates in any aspect of the \$MET Airdrop Campaign represents and acknowledges, without limitation or qualification, that all determinations or decisions made by the Company for the purposes of the \$MET Airdrop Campaign are final and binding. The Company shall not entertain any requests for appeal or review. In particular, the Participant acknowledges and accepts that despite any Participant satisfying all prescribed qualifying conditions / restrictions, the Company shall have the sole discretion to decline to deliver \$MET to such Participant for any reason whatsoever.
***
## 2. Claims Process
**2.1.** Participants may claim awarded \$MET from the relevant underlying smart contract or technical service for \$MET Airdrop Campaign during the “Claim Period”, which starts from 21 July 2026 until the expiry date on 21 October 2026. The expiry date will be three (3) months after the start date of 21 July 2026. Participants may claim \$MET by connecting their Digital Wallet enabling access to the Participant's Digital Wallet address as notified to the Company under 1.1, approving the relevant smart contract permissions as prompted, and calling a "Claim" function in accordance with the Company’s procedures. Any unclaimed \$MET Tokens after the aforementioned claim period shall no longer be available for claim, and shall be dealt with by the Company at its sole and absolute discretion.
**2.2.** Each Participant shall pay for all blockchain network fees or "gas" which may be required to call a "Claim" function for \$MET, or otherwise interacting with any underlying smart contracts deployed on a blockchain network; such fees are typically payable each time a Participant initiates the request to claim \$MET.
**2.3.** Participants are responsible for implementing all reasonable and appropriate measures for securing the Digital Wallet, vault or other storage mechanism that Participants use to store \$MET, including any requisite private key(s) or other credentials necessary to access such storage mechanism(s). If a Participant’s private key(s) or other access credentials are lost, such Participant may lose access to \$MET. The Company shall not be responsible for any security measures relating to the Participant’s receipt, possession, storage, transfer or potential future use of \$MET nor shall the Company be under any obligation to recover or return any such \$MET and the Company hereby excludes (to the fullest extent permitted under Applicable Laws) any and all liability for any security breaches or other acts or omissions which result in the Participant’s loss of (including loss of access to) \$MET airdropped to the Participant under these Terms. In the event of any loss, hack or theft of \$MET, each Participant acknowledges and confirms that it shall have no right(s), claim(s) or causes of action in any way whatsoever against the Company, its Affiliates, representatives, employees, directors and agents.
***
## 3. Representations, Warranties and Undertakings
**3.1.** You, the Participant, agree, represent and warrant that:
**(a)** You have read and understood the provisions of these Terms, including all relevant schedules and annexes that may be attached hereto;
**(b)** You have full power and authority to enter into and give effect to Your obligations and undertakings under these Terms, and in the case where You are a corporation or acting on behalf of a corporation:
**(i)** the corporation is a duly organised and validly existing corporation in its place of incorporation and it is not in receivership or liquidation or judicial management or any analogous situation; and
**(ii)** the corporation has full power and authority to enter into and give effect to its obligations under these Terms and all corporate steps required to give effect to the entry of these Terms have been properly taken.
**(c)** these Terms constitute a legal and binding obligation and undertaking, and may be enforced to the full extent of the law;
**(d)** where required, You have approved any approvals under any Applicable Laws for the participation in the \$MET Airdrop Campaign;
**(e)** any expenses that the You may incur in observing these Terms shall be at Your own expense and cost;
**(f)** You have not engaged in Disqualifying Conduct;
**(g)** You understand that and no materials, commentary, content provided by the Company and/or the Indemnified Parties shall be considered financial advice, and any financial advice sought by the You in relation to Your participation in the \$MET Airdrop Campaign shall be at Your own costs and expense;
**(h)** You are responsible and shall bear all expenses and costs involved (including but not limited to accountant fees) in determining the tax implications in Your participation of the \$MET Airdrop Campaign and the observance of these Terms;
**(i)** You are responsible for ensuring that Your Digital Wallet is functional and the keys for such, secure, and that it is Your responsibility to contact the Company through the appropriate avenue to resolve any issue with the Digital Wallet;
**(j)** You have a good understanding of the operation, functionality, usage, storage, transmission mechanisms and all material characteristics of cryptocurrencies, blockchain-based software systems, cryptocurrency wallets or other related token storage mechanisms, blockchain technology, smart contract technology, and staking mechanism, technology or services;
**(k)** You or (if participating on behalf of a corporation) any of the corporation's related corporations, directors, officers, employees, agents or any person acting on the corporation's behalf is NOT an individual or entity that is or is owned or controlled by an individual or entity that ("**Sanctioned Persons**"):
**(i)** is listed by the \[British Virgin Islands Financial Services Commission] or the Monetary Authority of Singapore as "designated", "sanctioned", "prohibited" or "restricted" (or with other similar terminology) individuals or entities defined in the respective regulations promulgated under the Monetary Authority of Singapore Act (Chapter 186) of Singapore, the United Nations Act (Chapter 339) of Singapore or the Terrorism (Suppression of Financing) Act (Chapter 325) of Singapore or such other law, regulation or rule as may be prescribed by any relevant authority;
**(ii)** is currently the subject of any sanction administered by the United States Office of Foreign Assets Control of the United States Department of the Treasury ("**OFAC**") or any other United States government authority, is not designated as a "Specially Designated National" or "Blocked Person" by OFAC or subject to any similar sanctions or measures imposed or administered by the United Nations Security Council, the European Union, or similar sanctions administered or imposed by any other country (collectively, the "**Sanctions**");
**(iii)** is located, organised or resident in a country or territory that is the subject of such Sanctions (including, without limitation, the Democratic People's Republic of Korea, the Democratic Republic of Congo, Eritrea, Iran, Libya, Somalia, South Sudan, Sudan and Yemen); or
**(iv)** has engaged in and is not now engaged in any dealings or transactions with any government, person, entity or project targeted by, or located in any country or territory, that at the time of the dealing or transaction is or was the subject of any Sanctions.
**(l)** You are not a citizen, resident (tax or otherwise), domiciliary and/or green card holder or other similar certificate of residency of a country (i) where holding tokens, trading tokens, or participating in token sales or distribution, whether as a purchaser or a seller, is prohibited, restricted or unauthorised by applicable laws, decrees, regulations, treaties, or administrative acts, or (ii) where it is likely that the distribution of \$MET would be construed as the sale of a security (howsoever named), financial service or investment product (including without limitation the United States of America, Canada, the People's Republic of China, Democratic People's Republic of Korea, Cuba, Syria, Iran, Sudan, and the People's Republic of Crimea (each a **Restricted Territory**)), nor are you acquiring \$MET from any Restricted Territory, nor are you an entity (including but not limited to any corporation or partnership) incorporated, established or registered in or under the laws of a Restricted Territory, nor are you acquiring \$MET on behalf of any person or entity from a Restricted Territory.
**3.2.** You are aware of and agrees that the \$MET Airdrop Campaign generally involves significant risk, and You hereby agree to accept the full consequences of all risks that may arise during, before, after and in connection to:
**(a)** your participation in the \$MET Airdrop Campaign and the distribution of \$MET;
**(b)** any loss of digital assets in your Digital Wallet;
**(c)** the use of \$MET in Meteora protocol, any other blockchain network, or for any other purpose;
**(d)** any potential delay, postponement, suspension, modification or abandonment of the \$MET Airdrop Campaign.
**3.3.** The list under Clause 3.2 shall not be regarded as an exhaustive list of the potential risks associated with Your participation in the \$MET Airdrop Campaign and You agree to accept full responsibility for Your own knowledge of all risks that may arise.
**3.4.** The Company does not take any responsibility for any circumstance or event that may prevent a person from participating in the \$MET Airdrop Campaign as a result of technical restrictions, issues, or other limitations such as force majeure, which include (but are not limited to) regulatory considerations, government directives, and government intervention of whatsoever nature.
***
## 4. Disclaimers of Warranties
**4.1.** The Company hereby disclaims and does not provide a warranty of any kind, whether implied, express or statutory, including but not limited to the respect of the matters listed in Clause 4.2. Where the Applicable Laws does not allow the disclaimer or exclusion of such warranties, the defective disclaimer shall apply to the full extent as permitted by the Applicable Laws.
**4.2.** You hereby and expressly agree that Your participation in the \$MET Airdrop Campaign is at Your sole risk and agree that in no event shall the Company be liable to You, or any corporation or entity You represent, for any of the following:
**(a)** any interruption, error, defect, flaw or unavailability of the \$MET Airdrop Campaign;
**(b)** any fraudulent or illegal use of Your Digital Wallet, or any loss of possession and destruction of Your private keys of any wallet;
**(c)** Your inability to participate in the \$MET Airdrop Campaign or any transactions You may undertake in connection with the same;
**(d)** any virus, malware, trojan or similar that may affect \$MET, Meteora protocol, or Your devices from use of any resources provided by the Company, despite the Company's best reasonable precautions in place to prevent as such;
**(e)** any delay, postponement, suspension or abortion of the \$MET Airdrop Campaign;
**(f)** the non-disclosure of information relating to the \$MET Airdrop Campaign;
**(g)** Your disqualification for failing to recognise Yourself as a Sanctioned Person or the failure of the Company to recognise You as such;
**(h)** any and all risks to You in Your participation in the \$MET Airdrop Campaign.
**4.3.** You agree that the Company may, at any time and in its absolute discretion, delay, postpone, suspend or abort the \$MET Airdrop Campaign for any reasons, including regulatory concerns or change in business strategy or goals. You agree that, where such should occur, neither the Company nor the Indemnified Parties would be liable for any loss (including but not limited loss of use, revenue, income, profits, damages) in accordance with Clause 9.
***
## 5. Information Provided to the Company
**5.1.** Each Participant shall ensure that any documents and information provided by such Participant in connection with its participation in the \$MET Airdrop Campaign is true, accurate and complete.
**5.2.** Where it occurs any event that may render such provided information under Clause 5.1 false, misleading, incomplete or altered, Participants shall, at the earliest possible, take such acts necessary to notify the Company and/or their Indemnified Parties of the event and corresponding change.
***
## 6. Taxes
The Parties shall seek their own advice on any tax that may be payable in connection with the performance of matter under these Terms. The Parties should be aware that this may include tax consequences including but not limited to tax reporting, income tax, transfer taxes and withholding tax. For the avoidance of doubt, the Company shall not be in any way reasonable for any claims, fines, penalties or other liabilities that any other party these Terms may incur.
***
## 7. Disqualification from Participating
**7.1.** The Company reserves the right, in its absolute discretion, to disqualify any participant from participation in the \$MET Airdrop Campaign, neither Company nor the Indemnified Parties would be liable for any losses or damages that may arise for such disqualification and in accordance with Clause 9.
**7.2.** Such situations of disqualification may include, but is not limited to, situations where such participant has encouraged, instigated and/or engaged in Disqualifying Conduct (defined below) that may be harmful to the Company. The Company reserves the right to take any action as necessary, including but not limited to legal proceedings, to protect the Company from the harm, losses, damage arising or connected to such conduct.
**7.3.** "**Disqualifying Conduct**" refers to exploitative, abusive and excessive conduct, and shall include but is not limited to, at the sole and full discretion and judgement of the Company:
**(a)** Acquiring, creating or controlling multiple user accounts, identities or Digital Wallet addresses in connection with participation in the \$MET Airdrop Campaign or any aspect of Meteora protocol, or otherwise participating in any Sybil attack or "farming" in connection with the \$MET Airdrop Campaign or Meteora protocol;
**(b)** Introducing or using any malware, virus, trojan horses or other material that may alter or be harmful to technology in any way;
**(c)** Gain and/or engage in unauthorised excess and use of any materials of the Company and its Indemnified Parties;
**(d)** Interfering with the operation of \$MET Airdrop Campaign;
**(e)** Impersonating the Company and/or the Indemnified Parties (such as but not limited to the use of e-mail or screen names); or
**(f)** Using any materials produced for the \$MET Airdrop Campaign in a way that is inappropriate and violates any Applicable Laws.
**7.4.** The Company reserves the right to implement the measures it deems necessary and fit to ensure that any Participant that has engaged in Disqualifying Conduct does not have access to the \$MET Airdrop Campaign.
***
## 8. Disclosure of Information
**8.1.** The Company does not warrant the completeness and accuracy of any information relating to the Company, the \$MET Airdrop Campaign that is online, which may originate from but not limited to the following:
**(a)** the website [https://www.meteora.ag/](https://www.meteora.ag/), [https://meteora.ag/campaigns](https://meteora.ag/campaigns) and all related sub-domains;
**(b)** the X (prev Twitter) account [https://x.com/meteoraag](https://x.com/meteoraag);
**(c)** the Discord channel [https://discord.gg/meteora](https://discord.gg/meteora);
**(d)** any website or other social media channels directly or indirectly linked to the Company.
**8.2.** You hereby agree that the Company and/or its Indemnified Parties shall be free of any liability arising from any reliance on such materials.
**8.3.** In the event of any conflict or inconsistency between these Terms and any other information, social media posting, brochure, marketing or promotional material relating to the \$MET Airdrop Campaign, these Terms shall prevail.
***
## 9. Liability and Indemnity
**9.1.** To the fullest extent permitted by law, the Company hereby expressly disclaims its liability for any loss incurred or suffered by You or any person in connection with the \$MET Airdrop Campaign, for:
**(a)** any and all changes to the operations, management and organisation of the \$MET Airdrop Campaign including but not limited to any potential delay, postponement, suspension or abandonment of the \$MET Airdrop Campaign as well as calculation of airdrop amounts generally or in any specific case;
**(b)** any mistake or error in delivery or in connection with \$MET due and any subsequent changes to the type or value of, or issues affecting, \$MET (if any);
**(c)** failure, malfunction or breakdown of, or disruption to, the operations of the Company, the Meteora protocol, or any other technology (including but not limited to any smart contract technology), due to any reason, including but not limited to occurrences of hacks, mining attacks (including without limitation double-spend attacks, majority mining power attacks and "selfish-mining" attacks), cyber-attacks, distributed denials of service, errors, vulnerabilities, defects, flaws in programming or source code or otherwise, regardless of when such failure, malfunction, breakdown, or disruption occurs;
**(d)** any virus, error, bug, flaw, defect or otherwise adversely affecting the \$MET Airdrop Campaign or your participation in \$MET Airdrop Campaign;
**(e)** Your failure to disclose information relating to the \$MET Airdrop Campaign at the request of the Company;
**(f)** any prohibition, restriction or regulation by any government or regulatory authority in any jurisdiction applicable to the \$MET Airdrop Campaign or Your participation in \$MET Airdrop Campaign; and
**(g)** all risks, direct, indirect or ancillary, associated with your participation in the \$MET Airdrop Campaign, the Company and/or the Meteora protocol, whether or not expressly stated in these Terms.
**9.2.** To the fullest extent permitted by Applicable Laws, You will indemnify, defend and hold harmless the Company and/or the Indemnified Parties from and against any and all claims, demands, actions, liabilities, costs, expenses for any type of loss (including but is not limited to damages, fines, punitive damages, personal injury, pain and suffering, emotional distress, revenue and profit loss, business and anticipated savings loss and data loss) that may arise in any kind (in tort, contract or otherwise), directly, indirectly, incidental or consequential, from or in connection with the matters dealt with and described in these Terms, including:
**(a)** losses that may be incurred by actions taken by the Company and/or Indemnified Parties against participants engaged in Disqualifying Conduct under Clause 7.3; and
**(b)** any loss that may be incurred as a result of the classification of the Participant as a Sanctioned Person as described under Clause 3.1(k).
**9.3.** You hereby agree that You waive all rights to assert any claims against the Company and/or the Indemnified Parties under any Applicable Laws. This shall include the right to participate in any class action lawsuit or class wide arbitration against the Company, the Indemnified Parties and/or any other Participant and/or any companies related through common ownership or control at any point in time.
***
## 10. Intellectual Property
**10.1.** You acknowledge and agree that save as otherwise indicated in writing, the Company (or, as applicable, its licensor(s)) owns all legal right, title and interest in and all intellectual property and all elements of \$MET and Meteora protocol, or any underlying websites in connection with the distribution and/or usage of \$MET and Meteora protocol, including, without limitation all art, designs, systems, methods, information, computer code, software, services, website design, "look and feel", organisation, compilation of the content, code, data and database, functionality, audio, video, text, photograph, graphics, and all other elements of the same (collectively, the "**Content**").
**10.2.** You acknowledge that the Content are protected by copyright, trade dress, patent, and trademark laws, international conventions, other relevant intellectual property and proprietary rights, and applicable laws. All Content are the copyrighted property of the Company (or, as applicable, its licensor(s), and all trademarks, service marks, and trade names associated with \$MET and Meteora protocol are proprietary to the Company or its licensor(s). Except as expressly set forth herein, your receipt or use of \$MET and Meteora protocol does not grant you ownership of or any other rights with respect to the aforesaid Content.
**10.3.** The Company reserves all rights in and to the Content that are not expressly granted to you in these Terms. In particular, you understand and agree that:
**(a)** your usage of \$MET and Meteora protocol does not give you any rights or licenses in or to the Content (including, without limitation, the Company's copyright in and to the associated art) other than those expressly contained in these Terms;
**(b)** you do not have the right, except as otherwise set forth in these Terms, to reproduce, distribute, or otherwise commercialise any elements of the Content (including, without limitation, any art) without the Company's prior written consent in each case, which consent may be withheld at the Company's sole and absolute discretion;
**(c)** you will not apply for, register, or otherwise use or attempt to use any \$MET or Meteora protocol trademarks or service marks, or any confusingly similar marks, anywhere in the world without the Company's prior written consent in each case, which consent may be withheld at the Company's and absolute discretion; and
**(d)** \$MET and Meteora protocol may potentially include intellectual property elements provided by third parties that are subject to separate ownership and/or license terms, in which case those terms will govern such intellectual property rights.
***
## 11. Third Party Online Products and Services
**11.1.** The Public Channels may contain links to third-party websites and services which are owned and operated by third parties ("**Third Party Online Products and Service(s)**"). These links are provided for Your information and convenience only, and are NOT an endorsement by the Company, its directors, officers, employees, agents, successors, and permitted assignees of the contents of such linked websites or third parties, over which none of the aforementioned entities have any control over.
**11.2.** Your access to and use of any Third Party Online Products and Service(s) is governed by the terms, conditions, disclaimers and notices found on each such website or in connection with such Third Party Online Products and Service(s). The Company has not verified, will not, and is under no obligation to verify the accuracy, suitability or completeness of the contents on such Third Party Online Products and Service(s), and the Company does not control, endorse, warrant, promote, recommend or in any way assume responsibility or liability for any services or products that may be offered by or accessed through such Third Party Online Products and Service(s) or the operators of them, or the suitability or quality of any of such Third Party Online Products and Service(s).
**11.3.** In addition, the Company does not warrant that such Third Party Online Products and Service(s) or the software, data or files contained in, accessed via or linked or referred to in, such Third Party Online Products and Service(s) are free of viruses (or other deleterious data or programs) or defects or that use of such Third Party Online Products and Service(s) will not cause harm or that they conform or will conform with any user expectations. Furthermore, the Company is not responsible for maintaining any materials referenced from another website, and makes no warranties for that website or service in such context.
***
## 12. Company's Remedies
**12.1.** If any Participant breaches any provision in these Terms or is discovered or deemed to be ineligible or disqualified for the \$MET Airdrop Campaign for any reason, the Company is entitled at any time:
**(a)** to withdraw, withhold, or require the forfeiture of any \$MET; or
**(b)** where the \$MET has been delivered to the Participant, to reclaim such \$MET and/or claim liquidated damages from the Participant in an amount of two (2) times the market value of such \$MET.
**12.2.** Upon the occurrence of the above, no person shall be entitled to any payment or compensation from the Company.
***
## 13. Assignment
**13.1.** You may not assign or transfer all or part of its rights or obligations under these Terms without the prior written consent of the Company. The Company may refuse to recognise any such assignment, transfer or any other transaction resembling such.
**13.2.** The Company may assign, as it sees fit and in its full discretion, any of its rights, obligations and duties under these Terms.
***
## 14. No Waiver
**14.1.** The Company's failure or delay to exercise or enforce any right or provision of these Terms will not operate as a waiver of such right or provision, nor will any single or partial exercise of any right or remedy preclude any other or further exercise thereof or the exercise of any other right or remedy.
**14.2.** Any provision in these Terms may be waived by written and signed consent of the Company. A waiver of any provision or terms shall not be deemed a waiver of any breach of the provision or term, or any other provision or term. For the avoidance of doubt, the Company may waive, by written and signed consent, any breach by any other Party to these Terms.
***
## 15. Governing Law and Dispute Resolution
**15.1.** These Terms are governed by the laws of Singapore, without regard to conflict of law rules or principles (whether of Singapore or any other jurisdiction) that would cause the application of the laws of any other jurisdiction.
**15.2.** Any dispute arising out of or related to these Terms, as well as any issue on its validity and existence, shall be referred to and finally resolved by confidential, arbitration administered in accordance with the BVI IAC Arbitration Rules for the time being in force, which rules are deemed to be incorporated by reference in this Clause 15. The place of arbitration shall be Road Town, Tortola, British Virgin Islands, unless the parties agree otherwise. The tribunal shall consist of 1 arbitrator agreed to by the parties within twenty (20) business days of receipt by the respondent of the request for arbitration or, in default thereof, appointed by the British Virgin Islands International Arbitration Centre in accordance with its prevailing rules. The arbitrator shall have exclusive authority to decide all issues relating to the interpretation, applicability, enforceability and scope of this arbitration agreement. The language of the arbitration shall be English. Each party irrevocably submits to the jurisdiction and venue of such tribunal. Judgment upon the award may be entered by any court having jurisdiction thereof or having jurisdiction over the relevant party or its assets.
***
## 16. Entire Agreement
These Terms set forth the entire agreement and understanding between the Parties in connection with the matters dealt with and described herein, and supersedes all prior oral and written agreements, memoranda, understandings and undertakings between the Parties in connection with the matters dealt with and described herein.
***
## 17. Rights of Third Parties
Save as expressly provided for in these Terms, a person who is not a party to these Terms has no right under any law of any jurisdiction to enforce or to enjoy the benefit of any term of these Terms.
***
## 18. Invalidity and Severance
If any provision of these Terms shall be held to be illegal, void, invalid or unenforceable, the provision shall be deemed illegal, void, invalid or unenforceable to that extent. The remaining provisions of these Terms shall remain fully valid, legal and enforceable to the extent that they are unaffected by the defective provision, and the illegality, invalidity or unenforceability of the defective provision in one jurisdiction does not affect its legality, validity and enforceability under any other jurisdiction. The Parties agree to use all commercially reasonable efforts to explore other means of achieving the same result as if the provision had been entirely valid, legal and enforceable.
# Tokenomics
Source: https://docs.meteora.ag/protocol/met/tokenomics
Review the MET token address, TGE date, supply, token burns, allocation table, vesting schedule, and transparency wallets.
**MET SPL Address:** [METvsvVRapdj9cFLzq4Tr43xK4tAjQfwX76z3n6mWQL](https://solscan.io/token/METvsvVRapdj9cFLzq4Tr43xK4tAjQfwX76z3n6mWQL)
* **TGE Date:** 23 October 2025
* **Total \$MET Supply:** 1,000,000,000
* **Circulating \$MET at TGE:** 480,000,000 (48% of total supply)
![]()
\$MET’s current circulating supply can be found at [Coingecko](https://www.coingecko.com/en/coins/meteora), which includes any token burns conducted by token holders (i.e. not Meteora Team), and burns conducted by the Meteora Team.
List of token burns conducted by Meteora Team:
| Date/Time |
# of MET Tokens |
Context |
| 17:01:37 Oct 25, 2025 |
2,261,990 |
[Link](https://x.com/realdezen/status/1982010180796817691?t=4klNX5UMieCQ4I5Ian6MqA\&s=19) |
# Token Allocations and Vesting Schedule
![]()
| Allocation |
% of Total Supply |
% of Total Supply Unlocked at TGE |
Cliff (Months) |
Vest (Months) |
| Mercurial Holders |
15% |
15% |
0 |
0 |
| Mercurial Reserve |
5% |
5% |
0 |
0 |
| LP Stimulus Plan |
15% |
15% |
0 |
0 |
| Launchpads & Launchpool Ecosystem |
3% |
3% |
0 |
0 |
| Offchain Contributors |
2% |
2% |
0 |
0 |
| Jupiter Stakers |
3% |
3% |
0 |
0 |
| M3M3 Plan |
2% |
2% |
0 |
0 |
| TGE Reserve |
3% |
3% |
0 |
0 |
| Team |
18% |
0% |
1 |
72 |
| Meteora Reserve |
34% |
0% |
1 |
72 |
| Allocation |
First Unlock |
Last Unlock |
| Team |
23 Nov 2025 |
23 Oct 2031 |
| Mercurial Reserve |
23 Nov 2025 |
23 Oct 2031 |
# \$MET Token Transparency
## Wallets
| Wallet |
Address |
Main Functions |
| Operations |
[EUBiwQD2quF7v65saSpG4BxpEfaWLgvs4hwyUiMNxYGJ](https://solscan.io/account/EUBiwQD2quF7v65saSpG4BxpEfaWLgvs4hwyUiMNxYGJ) |
CEX & MM tokens (3% of total supply) will be held here |
| Ecosystem |
[6HHtjZMR81LNAF5WFWE4xw72cybz3tPMQ3UJFy7FrvqH](https://solscan.io/account/6HHtjZMR81LNAF5WFWE4xw72cybz3tPMQ3UJFy7FrvqH) |
Tokens here will be used for TGE Airdrop, and hold the tokens for the Mercurial Reserve (45% of total supply) |
| Mercurial Reserve |
[DcHvzKHDpmBGxeRJh16K21EgeYuoLitZnk7MyDxSmr8N](https://solscan.io/account/6HHtjZMR81LNAF5WFWE4xw72cybz3tPMQ3UJFy7FrvqH) |
Locked Meteora Reserve Vault token allocations |
| Mercurial Reserve |
[HDXoxYngoXTziV7bGaPEXgUVRGsRuakagiKa9gA6rQzT](https://solscan.io/account/HDXoxYngoXTziV7bGaPEXgUVRGsRuakagiKa9gA6rQzT) |
Locked Team Vault token allocations |
Read more regarding token distribution at TGE [here](https://meteoraag.medium.com/meteora-genesis-summary-21-october-2025-3a9d914c437f)
# Protocol Revenues
Source: https://docs.meteora.ag/protocol/protocol-revenues
Meteora protocol revenues and protocol fee distribution across DLMM, DAMM v2, DAMM v1, and DBC
Meteora earns a share of the trading fees generated on swaps routed through its pools. These protocol fee percentages apply to the trading fee, not to the full swap notional.
# Fee Distribution Logic
The pool first calculates the total trading fee for the swap. The program then splits that trading fee between LPs, market makers, limit order owners, launch partners, token creators, the protocol, and optional referral or host accounts depending on the product.
```
Trading Fee = LP/MM/LO/Trading Fee Share + Protocol-Side Fee
```
When a referral or host fee account is included, that fee is paid from the protocol-side fee:
```
Protocol Revenue = Protocol-Side Fee - Referral/Host Fee
```
Referral and host fees do not increase the total trading fee paid by the swapper. They are carved out of the protocol-side fee when the swap includes the required referral or host account.
# DLMM
DLMM fees can be split between market-maker liquidity, limit-order liquidity, protocol fees, and host fees.
| Fee Source | Pool Type | Protocol-Side Fee | LP/Owner Fee | Notes |
| ----------- | --------------------------- | ----------------- | --------------------------- | -------------------------------------------------------------- |
| MM position | Standard pools | `10%` | `90%` LP fee | Standard pool protocol share is set by the operator or preset. |
| MM position | Launch pools | `20%` | `80%` LP fee | Launch pools use the ILM protocol share. |
| Limit order | Limit-order supported pools | `50%` | `50%` limit-order owner fee | Applies to the limit-order portion of the trading fee. |
DLMM swaps can include a host fee account. When present, the host fee is `20%` of the eligible protocol-side fee. If no host fee account is provided, the host fee is `0`.
# DAMM v2
DAMM v2 applies the same protocol split to standard pools and launch pools.
| Fee Source | Pool Type | Protocol-Side Fee | LP Fee |
| ----------- | -------------- | ----------------- | ------ |
| MM position | Standard pools | `20%` | `80%` |
| MM position | Launch pools | `20%` | `80%` |
DAMM v2 swaps can include a referral token account. When present, the referral fee is `20%` of the protocol-side fee. If no referral account is provided, the referral fee is `0`.
For DAMM v2 compounding pools, the LP side can be split between claimable fees and auto-compounded fees after the protocol fee is removed.
# DAMM v1
DAMM v1 fee distribution depends on whether the pool is constant product or stable swap.
| Pool Type | Protocol-Side Fee | LP Fee | Trade Fee |
| ------------------------------- | ----------------- | ------ | ------------ |
| Constant product standard pools | `20%` | `80%` | `0.25%` |
| Constant product launch pools | `20%` | `80%` | Customizable |
| Stable swap pools | `0%` | `100%` | `0.01%` |
DAMM v1 swaps can include a referral or host fee account. When present, the referral/host fee is `20%` of the protocol-side fee. If no referral or host account is provided, the referral/host fee is `0`.
# DBC
DBC splits bonding-curve swap fees between protocol fees and the virtual liquidity trading fee share.
| Fee Source | Protocol-Side Fee | Trading Fee Share | Notes |
| -------------------------- | ----------------- | ----------------- | -------------------------------------------------------------------------------------------------------------------- |
| Virtual liquidity position | `20%` | `80%` | The trading fee share is split between partner and creator according to the config's creator trading fee percentage. |
DBC swaps can include a referral token account. When present, the referral fee is `20%` of the protocol-side fee. If no referral account is provided, the referral fee is `0`.
# Collection in Base or Quote Tokens
Revenues are derived from swap fees, which are collected in the tokens currently being swapped. Therefore, Meteora accumulates a diverse basket of base and quote tokens, such as SOL, USDC, MET, and other pool assets.
Meteora's revenues are not automatically converted to stablecoins such as USDC at the moment of collection.
# Alpha Vault
Source: https://docs.meteora.ag/resources/audits/alpha-vault
Download audit reports for the Meteora Alpha Vault program.
# Offside Labs
Download the Offside Labs v0.4.0 audit report.
Download the Offside Labs v0.3.2 audit report.
Download the Offside Labs May 2024 audit report.
# DAMM v1
Source: https://docs.meteora.ag/resources/audits/damm-v1
Download audit reports for the Meteora DAMM v1 program.
# Offside Labs
Download the Offside Labs v0.5.4 audit report.
Download the Offside Labs v0.5.3 audit report.
Download the Offside Labs v0.5.2 audit report.
Download the Offside Labs v0.5.1 audit report.
# Halborn
Download the Halborn July 2022 audit report.
# Oak
Download the Oak October 2022 audit report.
# DAMM v2
Source: https://docs.meteora.ag/resources/audits/damm-v2
Download audit reports for the Meteora DAMM v2 program.
# Zenith
Download the Zenith v0.2.0 audit report.
Download the Zenith v0.1.8 audit report.
Download the Zenith v0.1.7 audit report.
Download the Zenith v0.1.6 audit report.
Download the Zenith v0.1.5 audit report.
Download the Zenith v0.1.4 audit report.
Download the Zenith v0.1.2 audit report.
Download the Zenith June 2025 audit report \[1].
# Offside Labs
Download the Offside Labs v0.2.2 audit report.
Download the Offside Labs v0.2.1 audit report.
Download the Offside Labs v0.2.0 audit report.
Download the Offside Labs v0.1.8 audit report.
Download the Offside Labs v0.1.7 audit report.
Download the Offside Labs v0.1.6 audit report.
Download the Offside Labs v0.1.5 audit report.
Download the Offside Labs June 2025 audit report.
# OtterSec
Download the OtterSec v0.1.5 audit report.
Download the OtterSec April 2025 audit report.
# DBC
Source: https://docs.meteora.ag/resources/audits/dbc
Download audit reports for the Meteora Dynamic Bonding Curve program.
# Offside Labs
Download the Offside Labs v0.2.0 audit report.
Download the Offside Labs v0.1.10 audit report.
Download the Offside Labs v0.1.9 audit report.
Download the Offside Labs v0.1.8 audit report.
Download the Offside Labs v0.1.7 audit report.
Download the Offside Labs v0.1.6 audit report.
Download the Offside Labs v0.1.1 audit report.
# OtterSec
Download the OtterSec v0.1.3 audit report.
# Zenith
Download the Zenith v0.2.0 audit report.
Download the Zenith v0.1.10 audit report.
Download the Zenith v0.1.9 audit report.
Download the Zenith v0.1.8 audit report.
Download the Zenith v0.1.7 audit report.
Download the Zenith v0.1.4 audit report.
Download the Zenith v0.1.3 audit report.
Download the Zenith v0.1.1 audit report.
# DLMM
Source: https://docs.meteora.ag/resources/audits/dlmm
Download audit reports for the Meteora DLMM program.
# Zenith
Download the Zenith v0.12.0 audit report.
Download the Zenith v0.11.0 audit report.
Download the Zenith v0.10.1 audit report.
# Offside Labs
Download the Offside Labs v0.13.0 audit report.
Download the Offside Labs v0.12.0 audit report.
Download the Offside Labs v0.11.0 audit report.
Download the Offside Labs v0.10.0 audit report.
Download the Offside Labs v0.9.0 audit report.
Download the Offside Labs v0.8.2 audit report.
Download the Offside Labs January 2024 audit report.
# OtterSec
Download the OtterSec v0.12.0 audit report.
Download the OtterSec v0.8.5 audit report.
Download the OtterSec February 2024 audit report.
# Sherloc
Download the Sherlock v0.12.0 audit report.
# Sec3
Download the Sec3 February 2024 audit report.
# Dynamic Fee Sharing
Source: https://docs.meteora.ag/resources/audits/dynamic-fee-sharing
Download audit reports for the Meteora Dynamic Fee Sharing program.
# Zenith
Download the Zenith v0.1.1 audit report.
# Dynamic Vault
Source: https://docs.meteora.ag/resources/audits/dynamic-vault
Download audit reports for the Meteora Dynamic Vault program.
# Offside Labs
Download the Offside Labs v0.9.4 audit report.
Download the Offside Labs September 2024 audit report.
# Sherlock
Download the Sherlock v0.9.4 audit report.
# Quantstamp
Download the Quantstamp June 2022 audit report.
# Halborn
Download the Halborn July 2022 audit report.
# Overview
Source: https://docs.meteora.ag/resources/audits/overview
Browse Meteora audit report indexes for DLMM, DAMM, DBC, vaults, Stake2Earn, Dynamic Fee Sharing, and Zap.
Audit reports for DLMM Program
Audit reports for DAMM v1 Program
Audit reports for DAMM v2 Program
Audit reports for Dynamic Bonding Curve Program
Audit reports for Presale Vault Program
Audit reports for Alpha Vault Program
Audit reports for Dynamic Vault Program
Audit reports for Stake2Earn Program
Audit reports for Dynamic Fee Sharing Program
Audit reports for Zap Program
# Presale Vault
Source: https://docs.meteora.ag/resources/audits/presale-vault
Download audit reports for the Meteora Presale Vault program.
# Sherlock
Download the Sherlock v0.1.1 audit report.
# Offside Labs
Download the Offside Labs v0.1.1 audit report.
Download the Offside Labs October 2025 audit report.
# Stake2Earn
Source: https://docs.meteora.ag/resources/audits/stake2earn
Download audit reports for the Meteora Stake2Earn program.
# Offside Labs
Download the Offside Labs October 2024 audit report.
# Zap
Source: https://docs.meteora.ag/resources/audits/zap
Download audit reports for the Meteora Zap program.
# Offside Labs
Download the Offside Labs v0.2.2 audit report.
Download the Offside Labs v0.2.1 audit report.
Download the Offside Labs v0.2.0 audit report.
Download the Offside Labs October 2025 audit report.
# Zenith
Download the Zenith v0.2.2 audit report.
Download the Zenith v0.2.1 audit report.
Download the Zenith v0.2.0 audit report.
# OtterSec
Download the OtterSec October 2025 audit report.
# Bug Bounty
Source: https://docs.meteora.ag/resources/bug-bounty/overview
Help us secure Meteora by responsibly disclosing vulnerabilities. We work with OOO Security to manage our bug bounty program.
Meteora's bug bounty program is managed through [OOO Security](https://ooosec.com), covering vulnerabilities across our on-chain programs and protocol infrastructure.
If you've found a security issue, please report it responsibly through the program — do not disclose publicly before it has been resolved.
Report vulnerabilities and earn rewards for responsible disclosure. Covers DLMM, DAMM v1/v2, DBC, Alpha Vault, and other Meteora programs.
# Cookies Notice and Policy
Source: https://docs.meteora.ag/resources/legal/cookies-notice-and-policy
Read Meteora's Cookies Notice and Policy for website cookies, similar technologies, choices, and contact information.
**Last updated: 10 October 2025**
Welcome to Meteora's website (accessible at [https://www.meteora.ag/](https://www.meteora.ag/)) (the "**Website**"), maintained and operated for the purposes of providing news, information, and updates about Meteora.
This Cookies Notice and Policy (the "**Cookie Policy**") explains the types of cookies and similar technologies that are utilised on the Website. It also explains what rights and choices you have in respect of the cookies and similar technologies that are utilised by us on the Website.
The Cookie Policy is incorporated into and forms part of our Website's Terms of Service which is located at [https://docs.meteora.ag/resources/legal/terms-of-service](https://docs.meteora.ag/resources/legal/terms-of-service) (the "Terms") and our Privacy Policy which is located at [https://docs.meteora.ag/resources/legal/terms-of-service#12-privacy-policy](https://docs.meteora.ag/resources/legal/terms-of-service#12-privacy-policy) and [https://docs.meteora.ag/resources/legal/privacy-policy](https://docs.meteora.ag/resources/legal/privacy-policy) (the "Privacy Policy").
Except as otherwise stated in this Cookie Policy, our Privacy Policy will apply to our processing of the data that we collect via cookies.
We reserve the right to modify this Cookie Policy at any time and encourage you to review this Cookie Policy each time you access the Website.
Capitalised terms in this Cookie Policy shall have the meaning given to them in the Terms or the Privacy Policy, unless the context requires otherwise.
***
## What are Cookies and Why Do We Use Them
1. Cookies are small pieces of text used to store information in web browsers. Cookies are used to store and receive identifiers and other information on computers, phones and other devices. They can also be used for other purposes, such as helping online services troubleshoot errors and better understand how their services are being used. Cookies set by us are called first-party cookies. We also use third-party cookies – which are cookies from a domain different from the domain of the website you are visiting. Other technologies, such as pixels, web beacons, local storage or data that we store on your web browser or device, identifiers associated with your device and other software, may be used for similar purposes. In this Cookie Policy, we refer to all of these technologies as "cookies".
2. The cookies used on the Website or as part of any Content made available on our Website may be necessary for the provision of certain services, features or functionalities, or may be optional and utilised only for your convenience (such as by personalising content), for advertising or marketing purposes (such as for tailoring and measuring advertisements or personalising advertisements), and/or other purposes. Cookies enable us to offer the Website and the Content to you and to understand the information that we receive about you, including information about your use of other websites and apps, whether or not you are registered or logged in.
3. The cookies that we use include session cookies, which are deleted when you close your browser, and persistent cookies, which stay in your browser until they expire, or you delete them.
***
## Types of Cookies that We Use
4. The following types of cookies may be used on the Website:
| Cookie Name | Provider | Type | Duration |
| -------------- | ---------------- | ---------- | ----------------------------------------- |
| `_ga*` | Google Analytics | Optional | Session/persistent cookies up to 400 days |
| `AMP_*` | Amplitude | Optional | Session/persistent cookies up to 1 year |
| `cf_clearance` | Cloudflare | Persistent | Up to 1 year |
5. The cookies that we use and how we use them may change over time as we improve and update the Website and the Content made available therein.
***
## How Do We Use Cookies
6. We may place cookies on your computer or device and receive information stored in cookies when you use or visit:
**(a)** the Website;
**(b)** any Content that are made available on or through the Website; or
**(c)** any websites, services and applications provided by third parties that are made available on or through the Website (such as Third-Party Service and Third-Party Content).
7. Third-party companies (such as Third Party Providers) may also use cookies on their own websites, products, applications and/or services in connection with the Website and/or the Content made available therein. To understand how other companies use cookies, please refer to their respective cookie policies.
***
## Managing Cookies
8. Most browsers allow you to manage how cookies are set and used as you're browsing, and to clear cookies and browsing data. Also, your browser may have settings letting you manage cookies on a site-by-site basis. For example, Google Chrome's settings at `chrome://settings/cookies` allow you to delete existing cookies, allow or block all cookies, and set cookie preferences for websites. Google Chrome also offers Incognito mode, which deletes your browsing history and clears cookies from the Incognito windows on your device after you close all of your Incognito windows.
9. Most mobile devices and applications also allow you to manage how similar technologies, such as unique identifiers used to identify an app or device, are set and used. For example, the Advertising ID on Android devices or Apple's Advertising Identifier can be managed in your device's settings, while app-specific identifiers may typically be managed in the app's settings.
10. Kindly note that if you delete or block certain cookies, you may not be able to use all the Content made available on the Website.
***
## How To Contact Us
11. If you have any enquiries or feedback on our Cookie Policy, or if you wish to make any request, you may contact us by this email:
**Email Address:** [privacy@meteora.ag](mailto:privacy@meteora.ag)
***
## Additional Information
12. For additional information about cookies, including how to see what cookies have been set on your device and how to manage and delete them, please visit:
* [www.allaboutcookies.org](https://www.allaboutcookies.org)
* [www.youronlinechoices.eu](https://www.youronlinechoices.eu)
# MiCAR White Paper - MET Token
Source: https://docs.meteora.ag/resources/legal/mica
White Paper in accordance with Article 6 of the Markets in Crypto Assets Regulation (MiCAR) for the European Union (EU) & European Economic Area (EEA)
Download the full MiCAR - MET Token White Paper
# Privacy Policy
Source: https://docs.meteora.ag/resources/legal/privacy-policy
Read Meteora's Privacy Policy for personal data collection, use, disclosure, rights, cookies, and contact information.
**Last updated: 28 April 2026**
Welcome to Meteora’s website (accessible at [https://www.meteora.ag/](https://www.meteora.ag/)) (the "**Website**"), provided and operated by Meteora Nova Limited (the "**Company**", "**we**", "**our**" or "**us**").
The Company maintains and operates the Website for the purposes of providing news, information, and updates about the Meteora protocol and ecosystem.
We take your privacy rights and the protection of personal data very seriously, and strive to collect, use, disclose and process any personal data collected in a manner that complies with applicable data protection and privacy legislation, including without limitation, the British Virgin Islands’ Data Protection Act, 2021 (the "**Data Protection Legislation**").
This Privacy Policy sets out what personal data we collect, how we use and share your personal data, and your choices concerning our information practices. This Privacy Policy is incorporated into and forms part of our Website’s [Terms of Use](/resources/legal/terms-of-service) (the "**Terms**").
Before accessing and using the Website or any of the Content made available thereon, or submitting any personal data to the Company via the Website, please read through this Privacy Policy and review it carefully. By accessing and/or using the Website or Content, you agree to our collection, use, disclosure and processing of your personal data as set out in this Privacy Policy. If you do not agree to this Privacy Policy, please do not access or use the Website or any of our Content.
We reserve the right to modify this Privacy Policy at any time without notice. You are advised to review this Privacy Policy each time you access the Website.
***
## Definitions and Interpretation
* **"Personal data"** (or "**personal information**" as the case may be) in this Privacy Policy shall have the meaning given to it in the Data Protection Legislation.
* Capitalised terms in this Privacy Policy shall have the meaning given to them in the Terms, unless the context requires otherwise. Other terms used in this Privacy Policy shall have the meanings given to them in the Data Protection Legislation (where the context so permits).
***
## Updates to This Privacy Policy
* We may revise this Privacy Policy from time to time without any prior notice. By continuing to access and/or use the Website or any of the Content made available therein, you are deemed to acknowledge and accept such changes to this Privacy Policy.
***
## What Personal Data We May Collect
* In order to access and/or use the Website and any of the Content made available therein, you may be required to provide us and we may collect the following categories of personal information:
* **Identification Information:** Name, email address, social media handle and phone number (as the case may be) for any communication or marketing purposes.
* **Wallet Information:** Details of your Digital Wallet (such as the wallet address) when you create or link your Digital Wallet with the Website.
* **Communication Information:** Information you share with us as part of any enquiries, emails, surveys, or feedback.
* **Social Media Information:** Information received from your interactions with our social media platforms or information provided by the social media platforms, including aggregate information and analytics of our followers or viewers.
* **Internet Activity Information:** When you visit, use, or interact with the Website or any of the Content made available therein, the following information may be created and automatically logged in our systems:
* **Device Information:** The manufacturer and model, operating system, IP address and unique identifiers of the device, as well as the browser you use to access the Website. The information we collect may vary based on your device type and settings.
* **Usage Information:** Information about how you use our Website, such as the types of content that you view or engage with, the features you use, the actions you take, and the time, frequency, and duration of your activities.
* **Email Open/Click Information:** We may use pixels in our email campaigns that allow us to collect your email and IP address as well as the date and time you open an email or click on any links in the email.
***
## When We May Collect, Use and/or Disclose Your Personal Data
* We generally do not collect your personal data:
* if you are just visiting or browsing the Website without connecting or linking your Digital Wallets;
* unless it is provided to us voluntarily by you directly or via a third party who has been duly authorised by you to disclose your personal data to us (your "authorised representative") after (i) you (or your authorised representative) have been notified of the purposes for which the data is collected, and (ii) you (or your authorised representative) have provided consent (whether written or by conduct) to the collection and usage of your personal data for those purposes; or
* collection and use of personal data without consent is permitted or required by the Data Protection Legislation or other laws. We will seek your consent before collecting any additional personal data and before using your personal data for a purpose which has not been notified to you (except where permitted or authorised by law).
* We may collect and use your personal data for any or all of the following purposes:
* performing obligations in the course of or in connection with allowing you access or use of our Website and any of the Content made available therein;
* verifying your Digital Wallet or identity, where we are required to do so (whether by law or otherwise);
* provision of the Website and any of the Content made available therein, including to provide, operate, maintain, and secure the Website and any of the Content made available therein;
* processing payments for transactions made on or through the Website;
* marketing and advertising purposes, including to send you direct marketing communications as permitted by law, and notify you of special promotions, offers and events by email and other means;
* responding to, handling, and processing queries, requests, applications, complaints, and feedback from you;
* managing your relationship with us;
* contacting you in respect of any matters relating to transactions made on or through the Website;
* complying with any applicable laws, regulations, codes of practice, guidelines, or rules, or to assist in law enforcement and investigations conducted by any governmental and/or regulatory authority;
* any other purposes for which you have provided such information;
* transmitting to any unaffiliated third parties including our third-party service providers and agents, and relevant governmental and/or regulatory authorities, whether in the British Virgin Islands or abroad, for the aforementioned purposes; and
* any other incidental business purposes related to or in connection with the above.
* The purposes listed in the above clauses may continue to apply even in situations where your relationship with us (for example, pursuant to a contract) has been terminated or altered in any way, for a reasonable period thereafter (including, where applicable, a period to enable us to enforce our rights under a contract with you).
***
## When Your Personal Data May Be Disclosed to Third Parties
* We may disclose your personal data described above to third parties or in specific situations without further notice to you, unless required by applicable law. Such disclosures may occur in the following instances:
* **Performance of Services:** When necessary for fulfilling obligations related to transactions made on or through the Website, or your access and use of the Website and/or any Content made available therein, we may disclose personal data to third parties involved in delivering these services.
* **Service Providers:** To support our business operations and provide certain services, we may share personal data with third-party providers, partners, affiliates, and service providers. This includes those offering hosting and cloud services, IT support, email communication and newsletter services, advertising and marketing services, payment processing, customer relationship management, customer support, and analytics services. These third parties may access, process, or store personal data as needed to perform their functions, in accordance with our instructions.
* **Professional Advisors:** We may share personal data with our professional advisors, such as legal and accounting firms, when necessary for them to provide services to us.
* **Business Transfers:** If we are involved in a merger, acquisition, financing, reorganization, bankruptcy, receivership, dissolution, sale of all or a portion of our assets, or transition of service to another provider (collectively a "**Business Transaction**"), your personal data may be shared in the diligence process with counterparties and others assisting with the Business Transaction and transferred to a successor or affiliate as part of or following that Business Transaction along with other assets.
* **Legal Requirements:** While we do not voluntarily share personal data with government authorities or regulators, we may disclose your information when required to do so by law, regulation, court order, or other legal obligation.
* Your personal data may be made publicly available in certain instances, including when you:
* post any content on our Website; and
* make any social media posts with your social media accounts which we may repost or share on our own social media platforms.
* For the purposes of registration, verification or provision of any of our Content, we may rely on third parties who may collect, use, disclose or process your personal data for their own purposes, and without our involvement or reference to us. We are not liable or responsible for the collection, use, disclosure or processing of your personal data by such third parties.
***
## Use of Cookies and Other Technologies
* We may deploy one or more of the following technologies to collect Internet Activity Information in order to enhance your user experience, understand how you interact with any of the Content made available on the Website, and improve our offerings:
* **Cookies:** These are small text files placed on your device that allow us to uniquely identify your browser or store information and settings. Cookies help improve your experience by enabling smooth navigation between pages, remembering your preferences, supporting specific functionalities, analyzing user activity and patterns, and facilitating targeted advertising.
* **Local Storage Technologies:** Technologies such as HTML5 may be used to provide functionality similar to cookies but with the ability to store larger amounts of data. This information can be stored directly on your device, including outside your browser, in relation to specific applications.
* **Web Beacons (Pixel Tags/Clear GIFs):** These help us confirm when a webpage or email has been accessed or opened, or when specific content has been viewed or clicked. Web beacons are typically used to track user engagement and optimize the content we deliver.
* **Data Analytics Tools:** We may use technologies and tools provided by third party partners to collect information from our users through the Website in order to better understand their needs and usage patterns, which can be used to inform future improvements to the Website and provide a more personalized experience. Information being collected may include, without limitation, the following:
1. Users, pageviews, sessions
2. Source (e.g. Google, social, direct)
3. Time spent on site
4. Users info (geographical location, browser type and language, device type and operating system)
For instance, we use the Google Analytics tool on the Website. For more information, please visit Google Analytics’ Privacy Policy. To learn more about how to opt-out of Google Analytics’ use of your information, please [click here](https://tools.google.com/dlpage/gaoptout).
* You should refer to our [Cookies Notice and Policy](/resources/legal/cookies-notice-and-policy) for more information relating to the various cookies and related technologies that are used on our Platform.
***
## Withdrawing Your Consent
* The consent that you provide for the collection, use and disclosure of your personal data will remain valid until such time it is being withdrawn by you in writing. You may withdraw consent and request us to stop collecting, using and/or disclosing your personal data for any or all of the purposes listed above by submitting your request in writing or via email to us at the contact details provided below.
* Upon receipt of your written request to withdraw your consent, we may require reasonable time (depending on the complexity of the request and its impact on our relationship with you) for your request to be processed and for us to notify you of the consequences of us acceding to the same, including any legal consequences which may affect your rights and liabilities to us. In general, we shall seek to process your request within fourteen (14) business days of receiving it.
* Whilst we respect your decision to withdraw your consent, please note that depending on the nature and scope of your request, we may not be in a position to continue to grant you access and/or use of the Website and/or any of the Content made available therein and we shall, in such circumstances, notify you before completing the processing of your request. Should you decide to cancel your withdrawal of consent, please inform us via email.
* Please note that withdrawing consent does not affect our right to continue to collect, use and disclose personal data where such collection, use and disclosure without consent is permitted or required under applicable laws.
***
## How to Access or Correct Your Personal Data
* If you wish to make (a) an access request for access to a copy of the personal data which we hold about you or information about the ways in which we use or disclose your personal data, or (b) a correction request to correct or update any of your personal data which we hold about you, you may submit your request via email to us at the contact details provided below.
* Please note that a reasonable fee may be charged for an access request. If so, we will inform you of the fee before processing your request.
* We will respond to your request as soon as reasonably possible. In general, our response will be within thirty (30) business days. Should we not be able to respond to your request within thirty (30) days after receiving your request, we will inform you in writing within thirty (30) days of the time by which we will be able to respond to your request. If we are unable to provide you with any personal data or to make a correction requested by you, we shall generally inform you of the reasons why we are unable to do so (except where we are not required to do so under the Data Protection Legislation).
***
## Safeguarding Your Personal Data
* To safeguard your personal data from unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks, we have or will implement appropriate administrative, physical and technical safeguards. These include limiting the collection of personal data, enforcing strong authentication and access controls (such as secure password practices and restricting data access to a need-to-know basis), encrypting data, maintaining up-to-date antivirus protection, regularly updating our operating system and other software, securely erasing storage devices before disposal, applying web security measures against risks, and conducting regular security reviews and testing.
* You should be aware, however, that no method of transmission over the Internet or method of electronic storage is completely secure. While security cannot be guaranteed, we strive to protect the security of your information and are constantly reviewing and enhancing our information security measures. However, no security measures are failsafe, and we cannot guarantee the security of your personal data. You use the Website and/or any of the Content made available therein at your own risk.
***
## Accuracy of Personal Data
* We generally rely on personal data provided by you (or your authorised representative). In order to ensure that your personal data is up-to-date, complete and accurate, please update us if there are changes to your personal data by via email at the contact details provided below. Failure to do so may affect or impact your continued use of the Website and/or any Content made available therein.
***
## When We May Retain Your Personal Data
* We may retain your personal data for as long as it is necessary to fulfil the purpose for which it was collected, or as required or permitted by applicable laws.
* We will cease to retain your personal data, or remove the means by which the data can be associated with you, as soon as it is reasonable to assume that such retention no longer serves the purpose for which the personal data was collected, and is no longer necessary for legal or business purposes.
***
## International Transfers of Personal Data
* We generally do not transfer your personal data to countries outside of your country of origin and the British Virgin Islands. However, we may be required to do so in order to complete the fulfilment of any transactions made by you on or through the Website (for example, if we were to facilitate a registration for an event held outside of your country or the British Virgin Islands).
* Apart from as stated above, we will obtain your consent for the transfer of any personal data to countries outside of your country of origin and the British Virgin Islands and we will take steps to ensure that your personal data continues to receive a standard of protection that is at least comparable to that provided under the Data Protection Legislation.
***
## Your California Privacy Rights
The California Consumer Privacy Act or "**CCPA**" (Cal. Civ. Code § 1798.100 et seq.) affords consumers residing in California certain rights with respect to their personal information. If you are a California resident, this section applies to you.
* **California Consumer Privacy Act**
We may collect the following categories of personal information: identifiers, financial information, biometric information, internet or electric network activity information, and geolocation data. Please refer to Clause 4 for more details on the types of personal information that we collect. We collect personal information for the purposes set out in this Privacy Policy. For avoidance of doubt, we do not sell your personal information.
* Subject to certain limitations, you have the right to (1) request to know more about the categories and specific pieces of personal information we collect, use, and disclose, (2) request deletion of your personal information, and (3) not be discriminated against for exercising these rights. You may make these requests by contacting us at [privacy@meteora.ag](mailto:privacy@meteora.ag). We will verify your request by asking you to provide information related to your recent interactions with us. We will not discriminate against you if you exercise your rights under the CCPA.
***
## Additional Disclosures for Individuals in Europe
If you are located in the European Economic Area ("**EEA**"), the United Kingdom, or Switzerland, you have certain rights and protections under the law regarding the processing of your personal data, and this section applies to you.
* **Legal Basis for Processing**
When we process your personal data, we will do so in reliance on the following lawful bases:
* To perform our responsibilities under our contract with you (e.g., processing payments for and providing the products and services you requested).
* When we have a legitimate interest in processing your personal data to operate our business or protect our interests (e.g., to provide, maintain, and improve our products and services, conduct data analytics, and communicate with you).
* To comply with our legal obligations (e.g., to maintain a record of your consents and track those who have opted out of communications).
* When we have your consent to do so (e.g., when you opt in to receive communications from us). When consent is the legal basis for our processing of your personal data, you may withdraw such consent at any time.
* **Data Retention**
We store other personal data for as long as necessary to carry out the purposes for which we originally collected it and for other legitimate business purposes, including to meet our legal, regulatory, or other compliance obligations.
* **Data Subject Requests**
Subject to certain limitations, you have the right to request access to the personal data we hold about you and to receive your data in a portable format, the right to ask that your personal data be corrected or erased, and the right to object to, or request that we restrict, certain processing. If you would like to exercise any of these rights, please contact us at [privacy@meteora.ag](mailto:privacy@meteora.ag).
* **Questions or Complaints**
If you have a concern about our processing of personal data that we are not able to resolve, you have the right to lodge a complaint with the Data Protection Authority where you reside. Contact details for your Data Protection Authority can be found using the links below:
For individuals in the EEA: [https://edpb.europa.eu/about-edpb/board/members\_en](https://edpb.europa.eu/about-edpb/board/members_en)
For individuals in the UK: [https://ico.org.uk/global/contact-us/](https://ico.org.uk/global/contact-us/)
***
## How to Contact Us
* If you have any enquiries or feedback on our personal data protection policies and procedures, or if you wish to make any request, you may contact us by this email:
**Email Address:** [privacy@meteora.ag](mailto:privacy@meteora.ag)
# Stake2Earn Terms of Service
Source: https://docs.meteora.ag/resources/legal/stake2earn-terms-of-service
Read the Stake2Earn Terms of Service for app access, smart contracts, user obligations, risks, fees, disclaimers, and legal terms.
M3M3 is a distributed set of specially-developed smart contracts (each, a "Smart Contract") deployed on the Solana blockchain or such other compatible blockchain network, as the case may be (each, the "relevant Blockchain Network") which allows any user additional tools to interact with automated market maker protocols. The M3M3 Smart Contracts innovate on established protocols such as “Meteora” to provide additional tooling for creators of token projects, for example allowing them to create and customise parameters for specialised “memecoin” liquidity pools, or create staking pools ("Vaults") which represent a customised software package launched by creators of token projects.
M3M3 may be visualised on a user interface that the user can interact with, including but not limited to the website at [https://app.meteora.ag/pools#stake2earnpools](https://app.meteora.ag/pools#stake2earnpools) and each of their subdomains, or our mobile or web applications (the "Site"). The Smart Contracts and the Site are collectively referred to in these Terms as (the "App"). Using the App, users can interact with the underlying Smart Contracts to create Vaults, view their Vaults created or accessed, and interact with other users in M3M3 ecosystem.
The Company's sole role is the deployment of the Smart Contracts, and accordingly any interaction with Vaults take place solely on the relevant Blockchain Network. It is important that you understand that smart contract protocols such as M3M3 simply comprise a set of autonomous blockchain-based smart contracts deployed on the relevant Blockchain Network, operated directly by users calling functions on it (which allows them to interact with other users in a multi-party peer-to-peer manner). There is no further control by or interaction with the original entity which had deployed the smart contract (i.e. the Company), which entity solely functions as a provider of technical tools for users, and is not offering any sort of securities product or regulated service nor does it hold any user assets on custody. Any rewards earned by user interactions arise solely out of their involvement in the protocol by taking on the risk of interacting with other users (in particular, creators launching token projects) and the ecosystem.
Meteora Nova Limited (the "Company", "we", "our" or "us") is making the App available to you. Before you use the App, the Smart Contracts, or the Site, however, you will need to agree to these Terms of Use and any terms and conditions incorporated herein by reference (collectively, these "Terms"). PLEASE READ THESE TERMS CAREFULLY BEFORE USING THE APP, THE SMART CONTRACTS, OR THE SITE. THESE TERMS GOVERN YOUR USE OF THE APP, THE SMART CONTRACTS, AND THE SITE, UNLESS WE HAVE EXECUTED A SEPARATE WRITTEN AGREEMENT WITH YOU FOR THAT PURPOSE. WE ARE ONLY WILLING TO MAKE THE APP, THE SMART CONTRACTS, AND THE SITE AVAILABLE TO YOU IF YOU ACCEPT ALL OF THESE TERMS. BY USING THE APP, THE SMART CONTRACTS, THE SITE, OR ANY PART OF THEM, OR BY CLICKING "I ACCEPT" BELOW OR INDICATING YOUR ACCEPTANCE IN AN ADJOINING BOX, YOU ARE CONFIRMING THAT YOU UNDERSTAND AND AGREE TO BE BOUND BY ALL OF THESE TERMS. IF YOU ARE ACCEPTING THESE TERMS ON BEHALF OF A COMPANY OR OTHER LEGAL ENTITY, YOU REPRESENT THAT YOU HAVE THE LEGAL AUTHORITY TO ACCEPT THESE TERMS ON THAT ENTITY’S BEHALF, IN WHICH CASE "YOU" WILL MEAN THAT ENTITY. IF YOU DO NOT HAVE SUCH AUTHORITY, OR IF YOU DO NOT ACCEPT ALL OF THESE TERMS, THEN WE ARE UNWILLING TO MAKE THE APP, THE SMART CONTRACTS, OR THE SITE AVAILABLE TO YOU. IF YOU DO NOT AGREE TO THESE TERMS, YOU MAY NOT ACCESS OR USE THE APP, THE SMART CONTRACTS, OR THE SITE.
By clicking "I Accept" or otherwise indicating your Acceptance, you agree to be bound by these Terms and affirm that you are of legal age to enter into these Terms where you live and have the legal capacity to enter into these Terms. Without limiting the foregoing, by using the App, you acknowledge and understand that laws regarding digital assets, financial instruments, or investment products which may include digital assets, may vary from jurisdiction to jurisdiction, and it is your sole obligation to ensure that you fully comply with any law, regulation or directive, relevant to your jurisdiction with regard to the use of the App. For the avoidance of doubt, the ability to access the App does not necessarily mean that the App, or your activities through it, are legal under the laws, regulations or directives relevant to your jurisdiction. All of the App or the services made available through the App may not be available to all users, and we reserve the right to assess or reassess at any time your eligibility to use all or part of the App. The App does not constitute, and may not be used for the purposes of, an offer or solicitation to anyone in any jurisdiction in which such offer or solicitation is not authorised, or to any person to whom it is unlawful to make such an offer or solicitation.
Supplemental terms and conditions or documents that may be posted on the App from time to time are hereby expressly incorporated herein by reference. We reserve the right, in our sole discretion, to make changes to the Terms from time to time. We will alert you of any changes by updating the “Last Updated" date of these Terms (on the first page hereof), and you waive any right to receive specific notice of each such change. It is your responsibility to periodically review these Terms to stay informed of updates. You will be subject to and will be deemed to have been made aware of and to have accepted, the changes in any revised Terms by your continued use of the Site, the App, and the Smart Contracts after the date such revised Terms are posted.
***
## Table of Contents
1. [Introduction](#1-introduction)
2. [The App](#2-the-app)
3. [Services](#3-services)
4. [Fees and Payment](#4-fees-and-payment)
5. [Intellectual Property and Content](#5-intellectual-property-and-content)
6. [User Terms](#6-user-terms)
7. [Risks Borne by Users](#7-risks-borne-by-users)
8. [External Sites](#8-external-sites)
9. [Disclaimers](#9-disclaimers)
10. [Limitation of Liability](#10-limitation-of-liability)
11. [Indemnity](#11-indemnity)
12. [Privacy Policy](#12-privacy-policy)
13. [Consent to Electronic Disclosures and Signatures](#13-consent-to-electronic-disclosures-and-signatures)
14. [Governing Law and Dispute Resolution](#14-governing-law-and-dispute-resolution)
15. [Notices](#15-notices)
16. [Entire Agreement](#16-entire-agreement)
17. [Force Majeure](#17-force-majeure)
18. [Third Party Rights](#18-third-party-rights)
19. [No Agency or Partnership](#19-no-agency-or-partnership)
20. [Interpretation](#20-interpretation)
21. [Assignment](#21-assignment)
22. [Illegality](#22-illegality)
23. [Waiver](#23-waiver)
24. [Severability](#24-severability)
25. [Survival](#25-survival)
26. [English Language](#26-english-language)
***
## 1. Introduction
### 1.1 Eligibility and Restricted Territories
To be eligible to use the App, the Smart Contracts, the Site and the Services (as defined below), you must be of legal age to enter into these Terms where you live and have the legal capacity to enter into these Terms. The App, the Smart Contracts, the Site and the Services is strictly NOT offered to persons or entities who reside in, are citizens of, are incorporated in, or have a registered office in any Restricted Territory, as defined below (any such person or entity from a Restricted Territory shall be a Restricted Person). If you are a Restricted Person, then do not attempt to access or use the App, the Smart Contracts, the Site or the Services. Use of a virtual private network (e.g., a VPN) or other means by Restricted Persons to access or use the App, the Smart Contracts, the Site or the Services is prohibited.
**Restricted Territory** means the British Virgin Islands, the United States, China, Myanmar (Burma), Cote D'Ivoire (Ivory Coast), Cuba, Crimea and Sevastopol, Democratic Republic of Congo, Iran, Iraq, Libya, Mali, Nicaragua, Democratic People’s Republic of Korea (North Korea), Somalia, Sudan, Syria, Yemen, Zimbabwe, Russia, or any other state, country or region that is subject to sanctions enforced by the United States or the European Union.
### 1.2 Availability of Services
The App, the Smart Contracts, the Site or the Services made available through the App (or any portion thereof) may not be available to all users, and we reserve the right to assess or reassess at any time your eligibility to use all or part of the App, the Smart Contracts, the Site or the Services.
### 1.3 No Offer or Solicitation
The App, the Smart Contracts, the Site and the Services does not constitute, and may not be used for the purposes of, an offer or solicitation to anyone in any jurisdiction in which such offer or solicitation is not authorised, or to any person to whom it is unlawful to make such an offer or solicitation.
### 1.4 Jurisdictional Compliance
Without limiting the foregoing, by using the App, the Smart Contracts, the Site or the Services, you acknowledge and understand that laws regarding digital assets, cryptocurrency derivatives, financial instruments, or investment products which may include digital assets, may vary from jurisdiction to jurisdiction, and it is your sole obligation to ensure that you fully comply with any law, regulation or directive, relevant to your jurisdiction with regard to the use of the App, the Smart Contracts, the Site or the Services. For the avoidance of doubt, the ability to access the App, the Smart Contracts, the Site or the Services does not necessarily mean that same (or your activities through it) are legal under the laws, regulations or directives relevant to your jurisdiction.
## 2. The App
2.1. To most easily access the App, you may first install a web browser (such as the Google Chrome web browser) and an electronic wallet compatible with the relevant Blockchain Network (such as the Phantom or Solflare electronic wallet). These electronic wallet services provide a visual representation allowing you to interact with the relevant Blockchain Network to purchase, store, and engage in transactions with various digital assets. You will not be able to engage in any transactions on the App other than through your selected electronic wallet service, or other browsers compatible with the relevant Blockchain Network.
2.2. Transactions that take place via the visual user interface on the App are confirmed via the relevant Blockchain Network. You understand that your public address on the relevant Blockchain Network will be made publicly visible whenever you engage in a transaction on the App.
2.3. The visual user interface provided on the Website facilitates your ability to access M3M3. The interface is distinct from the decentralised M3M3 software network. M3M3 is public, permissionless, and runs on open-source self-executing software; while the interface itself merely enables you to initiate messages to M3M3 in order to perform functions or access Services thereon. The interface is one of the means of accessing M3M3, but not the exclusive means of access.
2.4. M3M3 is a non-custodial protocol, therefore the App does not hold or control your digital assets. Any digital assets which you may acquire through the usage of the App will be held and administered solely by you through your selected electronic wallet, and we shall have no access to or responsibility in regard to such electronic wallet or digital asset held therein. It is solely your responsibility to select the wallet service provider to use in connection with the App, and your use of such electronic wallet will be subject to the governing terms of use or privacy policy of the provider of such wallet. We neither own nor control your selected electronic wallet service, Google Chrome, any electronic wallet, the relevant Blockchain Network, or any other third party site, product, or service that you might access, visit, or use for the purpose of enabling you to use the various features of the App. We will not be liable for the acts or omissions of any such third parties, nor will we be liable for any damage that you may suffer as a result of your transactions or any other interaction with any such third parties.
2.5. The Company will not create any hosted wallet for you or otherwise custody digital assets on your behalf, and it is your sole responsibility to maintain the security of your selected electronic wallet. In the event that you lose access to your electronic wallet, private key(s), password(s), or other method(s) of securing your wallet, all digital assets held in such wallet may be irretrievable, and the Company will be unable to assist you in any way. You hereby irrevocably waive, release and discharge all claims, whether known or unknown to you, against the Company, its affiliates and their respective shareholders, members, directors, officers, employees, agents and representatives related to your use of any wallet software, associated loss of digital assets, transaction failures, or any other defects that arise in the course of your use of your electronic wallet, including any losses that may obtain as a result of any failure of any Smart Contracts, the Site or the App.
2.6. The Company reserves the right to modify, suspend or discontinue, temporarily or permanently, all or any part of the Site or the App with or without notice. You agree that the Company will not be liable to you or to any third party for any modification, suspension or discontinuance of all or any part of the Site or the App.
2.7. The publicly deployed Smart Contracts you interact with are experimental in nature and you should not utilise the Smart Contracts or Vaults for deployment of any substantial amount of digital assets.
2.8. We reserve the right to disable access to the App, the Site or the interface at any time in the event of any breach of the Terms, including without limitation, if we, in our sole discretion, believe that you, at any time, fail to satisfy the eligibility requirements set forth in the Terms. Further, we reserve the right to limit or restrict access to the App or the Site by any person or entity, or within any geographic area or legal jurisdiction, at any time and at our sole discretion. We will not be liable to you for any losses or damages you may suffer as a result of or in connection with the App or the Site being inaccessible to you at any time or for any reason.
## 3. Services
3.1. The Company has deployed the Smart Contracts on the relevant Blockchain Network for users to utilise in accordance with these Terms. Users may directly call the functions of the Smart Contracts directly, or access them via the user interface provided by the App.
3.2. The M3M3 Smart Contracts innovate on established protocols such as “Meteora” to provide additional tooling for creators of token projects. For example, M3M3 allows project team to create and customise parameters for specialised “memecoin” liquidity pools or create staking Vaults in order to potentially share trading fees on that project’s native tokens with stakers. The SDK would allow third party projects and launchpads to easily integrate M3M3 functionality into their projects and launchpads.
3.3. Once the pools and/or Vaults are created, projects and users will be able to self-administer their digital holdings based on parameters set by the project or user. All interactions between creator teams launching projects and users on M3M3 operate in a peer-to-peer manner; these parties enter into a direct contractual relationship via the autonomous Smart Contracts and/or other smart contracts deployed by various other third party networks, and therefore creators wholly assume all responsibility towards the participating user in their project, pool or Vault. There is no further control by or interaction with the Company (or the relevant affiliate) which had deployed the Smart Contract(s). The Company and its affiliates shall in no circumstances be construed as a party to said peer-to-peer direct contractual relationship, is not liable for performance of obligations thereunder, nor does it bear any financial or commercial risk or provide any warranties or assurances in connection with the same.
3.4. The App merely provides a visual user interface allowing users to interact with Vaults and to interact with third party project teams, and does not act as an agent for any user or project. Although the App is intended to display accurate and timely information regarding Vaults and possible swaps, the App or relevant tools/information may not always be entirely accurate, complete or current and may also include technical inaccuracies or typographical errors. The pricing information data provided through the App does not represent an offer, a solicitation of an offer, or any advice regarding, or recommendation to enter into, a transaction with the Company or the App. Accordingly, users should verify all information before relying on it, and all decisions based on information contained on the App or tools/information tools are at the sole responsibility of each user. Notwithstanding any of the other provisions in these Terms, any photographs, graphic illustrations, videos, models, charts, designs, or examples on the site are strictly for information purposes only and have no contractual value nor do they form the basis of any contract with the Company.
3.5. Neither the Company, the Site nor the App provides any digital asset exchange or portfolio/fund management services in connection with the Vaults. If you choose to engage in transactions with Vaults or any other users, then such decisions and transactions and any consequences flowing therefrom are your sole responsibility. In no event shall the Company, its affiliates or their respective directors or employees be responsible or liable to you or anyone else, directly or indirectly, for any damage or loss arising from or relating to any interaction or continued interaction with Vaults, or reliance on any information provided on the Site or the App (including, without limitation, directly or indirectly resulting from errors in, omissions of or alterations to any such information).
3.6. THE APP SOLELY FUNCTIONS AS A VISUAL USER INTERFACE. IN NO CIRCUMSTANCES SHALL THE COMPANY, THE SMART CONTRACTS, THE SITE OR THE APP BE CONSTRUED AS A DIGITAL ASSET EXCHANGE, BROKER, DEALER, FUND MANAGER, FINANCIAL INSTITUTION, EXCHANGE, CUSTODIAN, ROBO-ADVISOR, INTERMEDIARY, OR CREDITOR. THE SITE DOES FACILITATE OR ARRANGE TRANSACTIONS BETWEEN BUYERS AND SELLERS, INCLUDING WITH RESPECT TO ANY TRANSACTIONS THAT OCCUR IN CONNECTION WITH ANY VAULT, WHICH TRANSACTIONS OCCUR ON THE RELEVANT BLOCKCHAIN NETWORK. THE COMPANY IS NOT A COUNTERPARTY TO ANY TRANSACTION FACILITATED BY THE SMART CONTRACTS, THE SITE OR THE APP OR FOR ANY USER OF THE SITE. NEITHER THE SMART CONTRACTS, THE SITE OR THE APP PROVIDES FINANCIAL ADVISORY, LEGAL, REGULATORY, OR TAX SERVICES DIRECTLY, INDIRECTLY, IMPLICITLY, OR IN ANY OTHER MANNER, AND YOU SHOULD NOT CONSIDER ANY CONTENT CONTAINED IN THESE TERMS OR OTHERWISE POSTED ON THE SITE TO BE A SUBSTITUTE FOR PROFESSIONAL FINANCIAL, LEGAL, REGULATORY, TAX OR OTHER ADVICE. THE COMPANY DOES NOT SUPPORT OR ENDORSE ANY VAUL OR POOL CREATED BY ANY USER OF M3M3, AND EACH SUCH CREATOR IS AN INDEPENDENT AGENT WITH NO EMPLOYMENT OR OTHER CONTRACTUAL RELATIONSHIP WITH THE COMPANY.
3.7. The Company reserves the right to suspend or terminate access to the Site or the App by any creator of Vaults or user of Vaults for any reason whatsoever (including without limitation for a breach of these Terms). You agree that the Company will not be liable to you or to any third party for any suspension or termination of any user.
3.8. Access to the Smart Contracts, the App or the Site may become degraded or unavailable during times of significant volatility or volume. This could result in the inability to interact with third-party services for periods of time and may also lead to support response time delays. The Company cannot guarantee that the Smart Contracts, the App or the Site will be available without interruption and neither do we guarantee that requests to interact with third-party services will be successful.
## 4. Fees and Payment
4.1. If you elect to interact with Vaults, all transactions will be conducted solely through the relevant Blockchain Network. We will have no insight into or control over these payments or transactions, nor do we have the ability to reverse any transactions. With that in mind, we will have no liability to you or to any third party for any claims or damages that may arise as a result of any transactions that you engage in via the App, or using the Smart Contracts, or any other transactions that you conduct via the relevant Blockchain Network.
4.2. The relevant Blockchain Network typically requires the payment of a transaction fee (a "**Transaction Fee**") for every transaction that occurs on the relevant Blockchain Network. The Transaction Fee funds the network of computers that run the decentralised network. This means that you will need to pay a Transaction Fee for each transaction that occurs via the Smart Contracts. For example, every Solana transaction requires a base fee (SOL) to compensate validators for processing the transaction. An optional prioritization fee is also available to increase the probability that the transaction is processed by the current leader (validator).
4.3. You may be subject to certain additional fees and commissions, including fees imposed by creators of Vaults for accessing and utilising the Vaults as notified to you prior to engaging with any pool or Vault. The Company also reserves the right to levy additional fees for access via the Smart Contracts, the Site or the App in the future. You agree to promptly pay all aforementioned fees and commissions.\[A1]
4.4. Notwithstanding anything in these Terms to the contrary, you will be solely responsible to pay any and all sales, use, value-added and other taxes, duties, and assessments (except taxes on the Company's net income) now or hereafter claimed or imposed by any governmental authority (collectively, "**Taxes**") associated with your use of the App (including, without limitation, any Taxes that may become payable as the result of your ownership or transfer of digital assets or interaction with any Vault, or relating to M3M3).
## 5. Intellectual Property and Content
5.1. The Company owns the Site and the App. You acknowledge and agree that the Company (or, as applicable, its affiliates) owns all legal right, title and interest in and to all other elements of the site and the App, and all intellectual property rights therein (including, without limitation, all designs, systems, methods, information, computer code, software, services, website design, "look and feel", organisation, compilation of the content, code, data and database, functionality, audio, video, text, photograph, graphics, copyright, trademarks (if any), and all other elements of the App (collectively, the "**Materials**"). You acknowledge that the Materials are protected by copyright, trade dress, patent, and trademark laws, international conventions, other relevant intellectual property and proprietary rights, and applicable laws. All Materials are the copyrighted property of The Company or its licensors, and all trademarks, service marks, and trade names associated with the App or otherwise contained in the Materials are proprietary to The Company or its licensors. Except as expressly set forth herein, your use of the App does not grant you ownership of or any other rights with respect to any content, code, data, or other Materials that you may access on or through the App. We reserve all rights in and to the Materials that are not expressly granted to you in these Terms. For the sake of clarity, you understand and agree: that (a) your interaction with Vaults or usage of the Smart Contracts, the Site or the App does not give you any rights or licenses in or to the Materials other than those expressly contained in these Terms; (b) you do not have the right to license, sell, rent, lease, transfer, assign, distribute, host, reproduce, distribute, or otherwise commercialise any elements of the Materials without our prior written consent in each case, which consent we may withhold in our sole and absolute discretion; (c) you shall not modify, make derivative works of, disassemble, reverse compile or reverse engineer any part of the Materials; and (d) you will not apply for, register, or otherwise use or attempt to use any of the Company's trademarks or service marks, or any confusingly similar marks, anywhere in the world.
5.2. By interacting with Vaults, you are granted a limited, non-exclusive, non-transferable, revocable license to use the site and the App for your personal use. Neither these Terms nor your access to the Smart Contracts, the site and the App transfers to you or any third party any rights, title or interest in or to intellectual property rights in the Materials, except for the limited access rights expressly set forth in these Terms. The Company expressly reserves all rights not granted in these Terms. There are no implied licenses granted under these Terms.
5.3. By acceptance of these Terms, you agree and acknowledge that all information and content provided by you, including your username, your contact list, Vaults created or Vaults interacted with, any messages, posts, comments or user generated content (the "**UGC**") in any communication channel (including without limitation Twitter, Discord or Telegram) shall be considered non-confidential and non-proprietary information. By providing such UGC, you specifically grant the Company a non-exclusive, irrevocable, transferable, sub-licensable, royalty-free, worldwide license to use, copy, duplicate store, present and publish all or any part of the UGC, and the Company shall be free to use such UGC in any manner or media whatsoever, on an unrestricted basis and without any attribution or royalties or other compensation to you, including, without limitation, within or outside the Site or the App, and in any digital or printed media.
5.4. You acknowledge that you shall be responsible for any UGC that you submit or transmit through the Site or the App, including your responsibility as to the legality, reliability, appropriateness, originality and copyright of any such information or material. Additionally, you represent and warrant that: (a) you own all right title and interest in any UGC provided by you, (b) such UGC does not violate any applicable laws, and (c) the posting of your UGC by us (in any manner or media whatsoever, on an unrestricted basis) does not (and will not) violate the privacy rights, publicity rights, copyright, contract rights or any other rights of any individual or make derogatory remarks regarding, defame or otherwise criticise any person or entity. You shall be solely liable for any damage resulting from any infringement or other violation of the copyright, trademarks or other proprietary rights of any individual or entity, and for any other harm or losses resulting from any UGC.\[A2]
5.5. You acknowledge and agree that any questions, comments, suggestions, ideas, feedback or other information regarding the Smart Contracts, the Site and the App ("Feedback") provided by you to us are non-confidential and should become our sole property. We should own exclusive rights, including all intellectual property rights, and should be entitled to the unrestricted use and dissemination of these Feedback to any lawful purpose, commercial, or otherwise, without acknowledgment or compensation for you. You hereby waive any moral rights to any such Feedback, and you hereby warrant that any such Feedback are original with you or that you have the right to submit such Feedback. You agree there should be no recourse against us for any alleged or actual infringement or misappropriation of any proprietary right in your Feedback.
## 6. User Terms
6.1. You agree that you are responsible for your own conduct while accessing or using the App, and for any consequences thereof. You agree to use the App only for purposes that are legal, proper and in accordance with these Terms and any applicable laws or regulations, including without limitation you may not, and may not allow any third party to: (a) send, upload, distribute or disseminate any unlawful, defamatory, harassing, abusive, fraudulent, obscene, or otherwise objectionable content; (b) distribute viruses, worms, defects, Trojan horses, corrupted files, hoaxes, or any other items of a destructive or deceptive nature; (c) impersonate another person (via the use of an email address or otherwise); (d) upload, post, transmit or otherwise make available through the App any content that infringes the intellectual proprietary rights of any party; (e) use the App to violate the legal rights (such as rights of privacy and publicity) of others; (f) engage in, promote, or encourage illegal activity (including, without limitation, money laundering); (g) interfere with other users' enjoyment of the App; (h) exploit the App for any unauthorised commercial purpose; (i) modify, adapt, translate, decompile, disassemble or reverse engineer any portion of the App; (j) attempt to bypass any measure of the Site designed to prevent or restrict access to the Site, or any portion of the Site or the App; (k) harass, intimidate, or threaten any of our employees or agents engaged in providing any portion of the Site or the App to you; (l) remove any copyright, trademark or other proprietary rights notices contained in or on the App, the Contents or any part of it; (m) reformat or frame any portion of the App; (n) display any content on the App that contains any hate-related or violent content or contains any other material, products or services that violate or encourage conduct that would violate any criminal laws, any other applicable laws, or any third party rights; (o) use any robot, spider, site search/retrieval application, or other device to retrieve or index any portion of the App or the content posted on the App, or to collect information about its users for any unauthorised purpose; (p) upload or transmit (or attempt to upload or to transmit) any material that acts as a passive or active information collection or transmission mechanism, including without limitation, clear graphics interchange formats (“gifs”), 1×1 pixels, web bugs, cookies, or other similar devices (sometimes referred to as “spyware” or “passive collection mechanisms” or “pcms”); (q) access or use the App by automated means or under false or fraudulent pretences; (r) access or use the App for the purpose of, directly or indirectly, creating or enabling a party to create a product or service that is competitive with any of our products or services; (s) use the Site, the App and the Smart Contracts to advertise or offer to sell goods and services; (t) conduct any activity that violates any applicable law, rule, or regulation concerning the integrity of trading markets, including (but not limited to) the manipulative tactics commonly known as spoofing, wash trading, cornering, accommodation trading, fictitious transactions, "money pass" (i.e. transactions without a net change in either party's open positions but with a resulting profit to one party and a loss to the other party), front-running, or pre-arranged or non-competitive transactions, or transactions designed to mislead external parties, or (u) disparage, tarnish, or otherwise harm, in our opinion, us and/or the Site, the App, and the Smart Contracts. If you engage in any of the activities prohibited by this Section 6, we may, at our sole and absolute discretion, without notice to you, and without limiting any of our other rights or remedies at law or in equity, immediately suspend or terminate your access to the Site or the App and delete your UGC from the Site.
6.2. By using the Site, the App and the Smart Contracts, you represent and warrant that: (a) you have read and understood these Terms and all documentation on the App or the Site; (b) you have good and sufficient experience and understanding of the functionality, usage, storage, transmission mechanisms and other material characteristics of cryptographic tokens, token storage mechanisms (such as token wallets), blockchain technology, blockchain-like technology and blockchain-based software systems to understand these Terms and to appreciate the risks and implications of creating or interacting with Vaults; (c) you acknowledge and agree that we may impose eligibility criteria to access certain functionality in respect of M3M3 which may require you to incur additional time and money costs; (d) you create and interact with Vaults for your own account and shall not do the same on behalf of any other entity or person; (e) your creation or interaction with Vaults complies with applicable law and regulation in your jurisdiction, and the law and regulation of any jurisdiction to which you may be subject (including, but not limited to legal capacity and any other threshold requirements for creating and interacting with Vaults, and interacting with other users of M3M3, any foreign exchange or regulatory restrictions applicable to creating and interacting with Vaults, and any governmental or other consents that may need to be obtained); (f) all information you submit will be true, accurate, current, and complete (if you provide any information that is untrue, inaccurate, not current, or incomplete, we have the right to refuse or terminate your current or future use of the Site and the App (or any portion thereof)); (g) you will maintain the accuracy of such information and promptly update such information as necessary; (h) you have the legal capacity and you agree to comply with these Terms; (i) you are not a minor in the jurisdiction in which you reside; (j) you will not use the Site, the App and the Smart Contracts for any illegal and unauthorised purpose; (k) you will not use the Site, the App and the Smart Contracts for any commercial purpose (save as approved by the Company in writing); (l) your use of the Site, the App and the Smart Contracts will not violate any applicable law or regulation; and (m) any funds or digital assets staked or deposited in Vaults are not derived from or related to any unlawful activities, including but not limited to money laundering or terrorist financing and all applicable statutes of all jurisdictions in which you are located, resident, organised or operating, and/or to which it may otherwise be subject and the rules and regulations thereunder (collectively, the "Compliance Regulations"), and you will not use the Smart Contracts, the Site or the App to finance, engage in, or otherwise support any unlawful activities or in a manner which aids or facilitates another party in the same. To the extent required by applicable laws and regulations, you shall fully comply with all Compliance Regulations.
6.3. We reserve the right to (but shall not be obliged to in any event to) conduct "Know Your Customer" and "Anti-Money Laundering" checks on you (including digital address or wallet screening) if deemed necessary by us (at our sole discretion) or such checks become required under applicable laws in any jurisdiction. Upon our request, you shall immediately provide us with information and documents that we, in our sole discretion, deem necessary or appropriate to conduct "Know Your Customer" and "Anti-Money Laundering" checks. Such documents may include, but are not limited to, passports, driver's licenses, utility bills, photographs of associated individuals, government identification cards or sworn statements before notaries or other equivalent professionals. Notwithstanding anything herein, we may, in its sole discretion, refuse to provide access to the Site or the Site to you until such requested information is provided, or in the event that, based on information available to us, you are suspected of using the Smart Contracts, the Site or the App in connection with any money laundering, terrorism financing, or any other illegal activity. In addition, we shall be entitled to use any possible efforts for preventing money laundering, terrorism financing or any other illegal activity, including without limitation blocking of your access to the Smart Contracts, the App or the Site or providing your information to any regulatory authority.
6.4. You are responsible for complying with applicable laws (including tax laws) in connection with usage of the Smart Contracts, the Site, the App or interactions with Vaults. You agree that we are not responsible for determining whether or which laws may apply to said interactions. You are advised to consult your own lawyers regarding of the legality and implications of any such activities. You are solely responsible for reporting and paying any taxes arising from your usage of the Smart Contracts, the Site, the App or interactions with Vaults.
## 7. Risks Borne by Users
**IMPORTANT RISK NOTICE:** You acknowledge and agree that the Services, the Site and the App are currently in the initial development stages and there are a variety of unforeseeable risks with utilising the foregoing. In the worst scenario, this could lead to the loss of all or part of your digital assets interacting with the Services, the Site, the App or the Smart Contracts.
**IF YOU DECIDE TO UTILISE SERVICES YOU EXPRESSLY ACKNOWLEDGE, ACCEPT AND ASSUME THE BELOW RISKS AND AGREE NOT TO HOLD THE COMPANY OR ANY OF THEIR AFFILIATES RESPONSIBLE FOR THE FOLLOWING RISKS:**
7.1. Using the App and interacting with Vaults carry financial risk. You acknowledge and agree that you are aware of such risks, including the following: (a) transactions relating to digital assets are very risky, and such digital assets are, by their nature, highly experimental, risky, volatile and generally irreversible. You should not make any transactional decision without first conducting your own research. You are solely and exclusively responsible for determining whether any Vault, any transaction, or strategy, or any other product or service in connection with the same is appropriate or suitable for you based on your own objectives and personal and financial situation. You acknowledge and agree that you will access and use the Smart Contracts, the Site and the App and interact with Vaults at your own risk.
7.2. You represent that you have sufficient knowledge, market sophistication, professional advice and experience to make your own evaluation of the merits and risks of any interaction with Vaults and the underlying digital assets. You accept all consequences of participating in such interactions, including the risk that you may lose access to your digital assets indefinitely. All decisions to interact with Vaults are made solely by you. Notwithstanding anything in these Terms, the Company accepts no responsibility whatsoever for and will in no circumstances be liable to you in connection with any interaction with Vaults and the underlying digital assets. Under no circumstances will the operation of all or any portion of the Smart Contracts, the Site or the App be deemed to create a relationship that includes any management of any assets, or the provision or tendering of investment advice.
7.3. Digital assets are not legal tender, are not backed by the government, and are not subject to any "Deposit Insurance Scheme" or protections under any banking or securities laws. The Company is not a bank and does not offer any lending services, fiduciary services, or security broking services.
7.4. The prices of blockchain assets are extremely volatile. Fluctuations in the price of other digital assets could materially and adversely affect the value of your digital assets held in Vaults, which may also be subject to significant price volatility. We cannot guarantee that any users interacting with Vaults will not lose money.
7.5. Neither the Smart Contracts, Site, the App or Vaults hold in custody, store, send, or receive any of your digital assets. This is because your digital assets exist only by virtue of the ownership record maintained on the relevant Blockchain Network. Any transfer of digital assets occurs within the relevant Blockchain Network, and not on the Smart Contracts, Site, the App or Vaults.
7.6. Public blockchain-based transactions (including but not limited to transactions automatically executed by smart contracts) are generally considered irreversible when confirmed. Any transaction that will interact with smart contracts or be recorded on a public blockchain must be recorded with extreme caution.
7.7. All smart contracts (including the Smart Contracts) may contain security vulnerabilities, errors, failures, bugs or economic loopholes which may be exploited by third parties, causing you to suffer losses in connection with any digital assets re-deployed by Vaults. Interaction with these Smart Contracts are entirely at your own responsibility and liability, and the Company is not a party to the Smart Contracts.
7.8. No creator of any Vault will be able to guarantee the future performance of digital assets held in a Vault, any specific level of performance, the success of any strategy or your overall results from interacting with any Vaults. When reviewing the information, portfolio, performance, opinions of these creators, do not assume that such party is unbiased, independent or qualified to provide financial information or opinions. Past performance and risk scores have many inherent limitations and are not indicative of future results. No representation or guarantee is being made that any creator of Vaults will or is likely to achieve gains or losses similar to the past performance. The actual percentage gains or losses experienced by users will vary depending on many factors.
7.9. Hackers or other malicious groups or organisations may attempt to interfere with the Smart Contracts, the Site, the App or Vaults in a variety of ways, including, but not limited to, malware attacks, denial of service attacks, consensus-based attacks, Sybil attacks, smurfing and spoofing, which may result in losses incurred by you. Furthermore, because the relevant Blockchain Network comprises open-source software, there is the risk that the software underlying the Services may contain intentional or unintentional bugs or weaknesses that may negatively affect the Services or the Smart Contracts, or result in the loss of the user’s digital assets, or the loss of the user’s ability to access or control their digital assets. In the event of such a software bug or weakness, there may be no remedy, and users are not guaranteed any remedy, refund or compensation.
7.10. Further, when you interact with Vaults or trade on any blockchain network, you accept that there is the inherent risk of the transaction being vulnerable to automated software programs (MEV bots) deployed by third parties which operate within decentralized finance (DeFi) ecosystem and exploit blockchain mechanics such as transaction ordering and transaction fee/gas price bidding to gain an advantage over specific users, or automated software programs (sniper bots) which executes trades buys or front-runs orders in respect of digital assets as soon as they are available on centralised or decentralised exchanges, which may be deployed by bad actors in connection with market manipulation or insider trading activities. The Company cannot be responsibility for losses suffered due to any of the foregoing, which are inherent to transactions on open blockchain networks.
7.11. The regulatory status of digital assets, and distributed ledger technology is unclear or unsettled in many jurisdictions. While every effort has been taken to ensure that the Services, the Site, the App and the Smart Contracts are compliant with local laws, it is difficult to predict how or whether regulatory agencies may apply existing regulation with respect to the same. It is likewise difficult to predict how or whether legislatures or regulatory agencies may implement changes to law and regulation affecting distributed ledger technology and its applications, including the Services, the Site, the App or the Smart Contracts. Regulatory actions could negatively impact the Company in various ways, and thus the Services may not be available in certain areas.
7.12. The underlying smart contracts run on a variety of supported blockchain networks, using specially-developed smart contracts. Accordingly, upgrades to the relevant Blockchain Network, a hard fork in the relevant Blockchain Network, re-organisations of blockchain structure or blocks, or a change in how transactions are confirmed on the relevant Blockchain Network may have unintended, adverse effects on the smart contracts built thereon, including the Smart Contracts.
7.13. The Site, Services and Smart Contracts may rely on or utilise a variety of external third party services or software, including without limitation decentralised cloud storage services, analytics tools, oracles, hence therefore the Services may be adversely affected by any number of risks related to these third party services/software, which may be compromised in the event of security vulnerabilities, cyberattacks, malicious activity, or technical interruptions.
## 8. External Sites
The Site or the App may include hyperlinks to other web sites or resources (collectively, "External Sites"), which are provided solely for your convenience. We have no control over any External Sites. You acknowledge and agree that we are not responsible for the availability of any External Sites, and that we do not endorse any advertising, products or other materials on or made available from any External Sites. Furthermore, you acknowledge and agree that we are not liable for any loss or damage which may be incurred as a result of the availability or unavailability of the External Sites, or as a result of any reliance placed by you upon the completeness, accuracy or existence of any advertising, products or other materials on, or made available from, any External Sites.
## 9. Disclaimers
9.1. YOU EXPRESSLY UNDERSTAND AND AGREE THAT YOUR ACCESS TO AND USE OF THE SMART CONTRACTS, THE SITE, THE APP AND VAULTS IS AT YOUR SOLE RISK, AND THAT THE APP IS PROVIDED "AS IS" AND "AS AVAILABLE" WITHOUT WARRANTIES OF ANY KIND, WHETHER EXPRESS OR IMPLIED. TO THE FULLEST EXTENT PERMISSIBLE PURSUANT TO APPLICABLE LAW, THE COMPANY, ITS SUBSIDIARIES, AFFILIATES, AND LICENSORS MAKE NO EXPRESS WARRANTIES AND HEREBY DISCLAIM ALL IMPLIED WARRANTIES REGARDING THE APP AND ANY PART OF IT (INCLUDING, WITHOUT LIMITATION, THE SMART CONTRACTS, THE SITE, THE APP, VAULTS, OR ANY EXTERNAL WEBSITES), INCLUDING ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, CORRECTNESS, ACCURACY, OR RELIABILITY. WITHOUT LIMITING THE GENERALITY OF THE FOREGOING, THE COMPANY, ITS SUBSIDIARIES, AFFILIATES, AND LICENSORS DO NOT REPRESENT OR WARRANT TO YOU THAT: (A) YOUR ACCESS TO OR USE OF THE SMART CONTRACTS, THE SITE, THE APP AND VAULTS WILL MEET YOUR REQUIREMENTS, (B) YOUR ACCESS TO OR USE OF THE SMART CONTRACTS, THE SITE, THE APP AND VAULTS WILL BE UNINTERRUPTED, TIMELY, SECURE OR FREE FROM ERROR, (C) USAGE DATA PROVIDED THROUGH THE SMART CONTRACTS, THE SITE, THE APP AND VAULTS WILL BE ACCURATE, (D) THE SMART CONTRACTS, THE SITE, THE APP AND VAULTS, OR ANY CONTENT, SERVICES, OR FEATURES MADE AVAILABLE ON OR THROUGH THE SMART CONTRACTS, THE SITE, THE APP AND VAULTS ARE FREE OF VIRUSES OR OTHER HARMFUL COMPONENTS, OR (E) THAT ANY DATA THAT YOU DISCLOSE WHEN YOU USE THE SMART CONTRACTS, THE SITE, THE APP AND VAULTS WILL BE SECURE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES IN CONTRACTS WITH CONSUMERS, SO SOME OR ALL OF THE ABOVE EXCLUSIONS MAY NOT APPLY TO YOU.
9.2. YOU ACCEPT THE INHERENT SECURITY RISKS OF PROVIDING INFORMATION AND DEALING ONLINE OVER THE INTERNET, AND AGREE THAT THE COMPANY HAS NO LIABILITY OR RESPONSIBILITY FOR ANY BREACH OF SECURITY UNLESS IT IS DUE TO THE COMPANY'S WILFUL DEFAULT.
9.3. DIGITAL ASSETS ARE INTANGIBLE DIGITAL ASSETS THAT EXIST ONLY BY VIRTUE OF THE OWNERSHIP RECORD MAINTAINED IN THE RELEVANT BLOCKCHAIN NETWORK. ALL SMART CONTRACTS IN CONNECTION WITH M3M3 ECOSYSTEM ARE DEPLOYED ON AND INTERACTIONS/TRANSACTIONS WITH THE SAME OCCUR ON THE DECENTRALISED LEDGER WITHIN THE RELEVANT BLOCKCHAIN NETWORK. WE HAVE NO CONTROL OVER AND MAKE NO GUARANTEES OR PROMISES WITH RESPECT TO SMART CONTRACTS.
9.4. THE COMPANY IS NOT RESPONSIBLE FOR LOSSES DUE TO BLOCKCHAINS OR ANY OTHER FEATURES OF THE RELEVANT BLOCKCHAIN NETWORK OR YOUR SELECTED ELECTRONIC WALLET SERVICE, INCLUDING BUT NOT LIMITED TO LATE REPORT BY DEVELOPERS OR REPRESENTATIVES (OR NO REPORT AT ALL) OF ANY ISSUES WITH THE BLOCKCHAIN SUPPORTING THE RELEVANT BLOCKCHAIN NETWORK, INCLUDING FORKS, TECHNICAL NODE ISSUES, OR ANY OTHER ISSUES HAVING FUND LOSSES AS A RESULT.
## 10. Limitation of Liability
10.1. YOU UNDERSTAND AND AGREE THAT WE, OUR SUBSIDIARIES, AFFILIATES, AND LICENSORS WILL NOT BE LIABLE TO YOU OR TO ANY THIRD PARTY FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, OR EXEMPLARY DAMAGES WHICH YOU MAY INCUR IN CONNECTION WITH THE SMART CONTRACTS, THE SITE, THE APP OR VAULTS, HOWSOEVER CAUSED AND UNDER ANY THEORY OF LIABILITY, INCLUDING, WITHOUT LIMITATION, ANY LOSS OF PROFITS (WHETHER INCURRED DIRECTLY OR INDIRECTLY), LOSS OF GOODWILL OR BUSINESS REPUTATION, LOSS OF DATA, COST OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, OR ANY OTHER INTANGIBLE LOSS, EVEN IF WE HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
10.2. YOU AGREE THAT OUR TOTAL, AGGREGATE LIABILITY TO YOU FOR ANY AND ALL CLAIMS ARISING OUT OF OR RELATING TO THESE TERMS OR YOUR ACCESS TO OR USE OF (OR YOUR INABILITY TO ACCESS OR USE) ANY PORTION OF THE SMART CONTRACTS, THE SITE, THE APP OR VAULTS, WHETHER IN CONTRACT, TORT, STRICT LIABILITY, OR ANY OTHER LEGAL THEORY, IS LIMITED TO THE LOWER OF (A) THE AMOUNTS YOU ACTUALLY PAID US UNDER THESE TERMS IN THE 12 MONTH PERIOD PRECEDING THE DATE THE CLAIM AROSE, OR (B) US\$200.
10.3. YOU ACKNOWLEDGE AND AGREE THAT WE HAVE MADE THE SMART CONTRACTS, THE SITE, THE APP AND VAULTS AVAILABLE TO YOU AND ENTERED INTO THESE TERMS IN RELIANCE UPON THE WARRANTY DISCLAIMERS AND LIMITATIONS OF LIABILITY SET FORTH HEREIN, WHICH REFLECT A REASONABLE AND FAIR ALLOCATION OF RISK BETWEEN THE PARTIES AND FORM AN ESSENTIAL BASIS OF THE BARGAIN BETWEEN US. WE WOULD NOT BE ABLE TO PROVIDE THE APP TO YOU WITHOUT THESE LIMITATIONS.
10.4. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, AND SOME JURISDICTIONS ALSO LIMIT DISCLAIMERS OR LIMITATIONS OF LIABILITY FOR PERSONAL INJURY FROM CONSUMER PRODUCTS, SO THE ABOVE LIMITATIONS MAY NOT APPLY TO PERSONAL INJURY CLAIMS.
## 11. Indemnity
You agree to hold harmless and indemnify the Company and its subsidiaries, affiliates, officers, agents, employees, advertisers, licensors, suppliers or partners from and against any claim, liability, loss, damage (actual and consequential) of any kind or nature, suit, judgment, litigation cost, and attorneys' fees arising out of or in any way related to (a) your breach of these Terms, (b) your misuse of the Smart Contracts, the Site, the App or the Vaults, or (c) your violation of any applicable laws, rules or regulations in connection with your access to or use of the App. You agree that the Company will have control of the defence or settlement of any such claims.
## 12. Privacy Policy
12.1. Our Privacy Policy describes the ways the Company collects, uses, stores and discloses your personal information, and is hereby incorporated by this reference into these Terms. You agree to the collection, use, storage, and disclosure of your data in accordance with the aforementioned Privacy Policy.
12.2. The Company will maintain certain data that you transmit to the Site and the App for the purpose of managing the performance of the Site and the App, as well as data relating to your use of the Site or the App. Although we perform regular routine backups of data, the Company is solely responsible for all data that you transmit or that release to any activity you have undertaken using the Site or the App. You agree that we shall have no liability to you for any loss or corruption of any such data, and you hereby waive any right of action against us arising from any such loss or corruption of such data.
## 13. Consent to Electronic Disclosures and Signatures
13.1. Because the Company operates only on the Internet, it is necessary for you to consent to transact business with us online and electronically. As part of doing business with us, therefore, we also need you to consent to our providing you certain disclosures electronically via the Site. By agreeing to these Terms, you agree to receive electronically all documents, communications, notices, contracts, and agreements arising from or relating to your use of the Site and Services.
13.2. By accepting these Terms or contacting us in any manner, you expressly consent to be contacted by us, our agents, representatives, affiliates, or anyone calling on our behalf for any and all purposes, in any way, including notifications, messages and/or calls delivered using automated systems. Notwithstanding the aforementioned, any form of communication from the Company will be provided to you electronically through the Site or (if applicable) via email to the email address provided. If you require paper copies of any agreements or disclosures, you may print such documents desired.
13.3. Your consent to receive disclosures and transact business electronically, and our agreement to do so, applies to any transactions to which such disclosures relate, whether between you and the Company or a third party by and through the Services. Your consent will remain in effect for so long as you are a user and, if you are no longer a user, will continue until such a time as all disclosures relevant to Services received through the Site.
13.4. You may withdraw your consent to receive agreements or disclosures electronically by contacting us at [meteora\_support@meteora.ag](mailto:meteora_support@meteora.ag). However, once you have withdrawn your consent you will not be able to access the Services or the Site.
## 14. Governing Law and Dispute Resolution
14.1. These Terms will be governed by and construed in accordance with the laws of the British Virgin Islands, without regard to conflict of law rules and principles (whether of the British Virgin Islands or any other jurisdiction) that would cause the application of the laws of any other jurisdiction.
14.2. All disputes arising out of or in connection with these Terms (including without limitation the enforceability of this Section 14 or any question regarding its existence, validity or termination, your access or use of the App, the Site, or the Smart Contracts, or to any products sold or distributed through the App, the Site, or the Smart Contracts) shall be referred to and finally resolved by arbitration administered by arbitration in accordance with the BVI IAC Arbitration Rules for the time being in force, which rules are deemed to be incorporated by reference in this Section 14. The place of arbitration shall be Road Town, Tortola, British Virgin Islands, unless the Parties agree otherwise. The number of arbitrators shall be one. The language to be used in the arbitral proceedings shall be English. The award of the arbitrator will be final and binding, and any judgment on the award rendered by the arbitrator may be entered in any court of competent jurisdiction. Each party will cover its own fees and costs associated with the arbitration proceedings. Notwithstanding the foregoing, the Company may seek and obtain injunctive relief in any jurisdiction in any court of competent jurisdiction, and you agree that these Terms are specifically enforceable by the Company through injunctive relief and other equitable remedies without proof of monetary damages.
## 15. Notices
To give us notice under these Terms, the user must contact the Company by email at **[meteora\_support@meteora.ag](mailto:meteora_support@meteora.ag)**
## 16. Entire Agreement
These Terms constitute the entire legal agreement between you and the Company, govern your access to and use of the Smart Contracts, the Site, the App or the Vaults, and completely replace any prior or contemporaneous agreements between the parties related to your access to or use of the Smart Contracts, the Site, the App or the Vaults, whether oral or written.
## 17. Force Majeure
The Company shall not be liable for delays, failure in performance or interruption of service which result directly or indirectly from any cause or condition beyond its reasonable control, including but not limited to, significant market volatility, any delay or failure due to any act of God, act of civil or military authorities, act of terrorists, civil disturbance, war, strike or other labour dispute, fire, interruption in telecommunications or Internet services or network provider services, failure of equipment and/or software, other catastrophe or any other occurrence which is beyond its reasonable control, and shall not affect the validity and enforceability of any remaining provisions.
## 18. Third Party Rights
There are no third party beneficiaries to these Terms. A person who is not a party under these Terms has no right under any applicable law to enforce or to enjoy the benefit of these Terms.
## 19. No Agency or Partnership
Nothing in these Terms create any agency, partnership, joint venture or any similar relationship between the Company and you, nor cause the Company and you to be deemed acting in concert in any respect.
## 20. Interpretation
The language in these Terms will be interpreted as to its fair meaning, and not strictly for or against any party.
## 21. Assignment
You may not assign any or your rights or obligations under these Terms, whether by operation of law or otherwise, without our prior written consent. Notwithstanding anything contained herein, we may assign our rights and obligations under these Terms in our sole discretion (without your consent) to an affiliate for any reason, including without limitation any assignment or novation in connection with a reincorporation to change the Company's domicile.
## 22. Illegality
Should any provision or part-provision of these Terms is or becomes invalid, illegal or unenforceable in any respect under any law of any jurisdiction, it shall be deemed modified to the minimum extent necessary to make it valid, legal and enforceable; if such modification is not possible, the relevant provision or part-provision shall be deemed deleted. Any modification to or deletion of a provision or part-provision pursuant to this Section 22 shall not affect or impair the validity and enforceability of the rest of these Terms, nor the validity and enforceability of such provision or part-provision under the law of any other jurisdiction.
## 23. Waiver
Our failure to enforce any provision of these Terms will not be deemed a waiver of such provision, nor of the right to enforce such provision.
## 24. Severability
If any provision of these Terms shall be determined to be invalid or unenforceable under any rule, law, or regulation of any local, state, or federal government agency, such provision will be changed and interpreted to accomplish the objectives of the provision to the greatest extent possible under any applicable law and the validity or enforceability of any other provision of these Terms shall not be affected. If such construction is not possible, the invalid or unenforceable portion will be severed from these Terms but the rest of these Terms will remain in full force and effect.
## 25. Survival
The following provisions of these Terms shall survive termination of your use or access to the Site: Sections 5, 9, 10, 11, 14, and any other provision that by its terms survives termination of your use or access to the Site.
## 26. English Language
Notwithstanding any other provision of these Terms, any translation of these Terms is provided for your convenience. The meanings of terms, conditions, and representations herein are subject to their definitions and interpretations in the English language. In the event of conflict or ambiguity between the English language version and translated versions of these terms, the English language version shall prevail. You acknowledge that you have read and understood the English language version of these Terms.
# Terms of Service
Source: https://docs.meteora.ag/resources/legal/terms-of-service
Read Meteora's Terms of Service for app access, smart contracts, user obligations, risks, fees, disclaimers, and legal terms.
Meteora is a distributed set of specially-developed smart contracts (each, a "Smart Contract") deployed on the Solana blockchain or such other compatible blockchain network, as the case may be (each, the "relevant Blockchain Network") which allows any user to trade digital asset pairs directly in a peer-to-peer manner via Liquidity Pools (as defined herein). The Dynamic Liquidity Market Maker (DLMM) Smart Contracts underlying Meteora offer a variety of innovations to decentralised exchanges, for example high capital efficiency (supporting high volume trading with low liquidity requirements through the concentrating of tokens at or around the current market value), zero slippage (swap tokens with zero slippage or price impact within active bin), dynamic fees (liquidity providers earn dynamic swap fees during high market volatility to compensate for impermanent loss) and flexible liquidity (liquidity providers can build Liquidity Pools with flexible liquidity distributions according to their volatility strategies, e.g. single-sided liquidity with only one token).
The Liquidity Pools and Meteora may be visualised on a user interface that the user can interact with, including but not limited to the website at [https://www.meteora.ag/](https://www.meteora.ag/) and each of their subdomains, or our mobile or web applications (the "Site"). The Smart Contracts and the Site are collectively referred to in these Terms as (the "App"). Using the App, users can interact with the underlying Smart Contracts to create Liquidity Pools, view their Liquidity Pools created or accessed, and interact with other users in Meteora ecosystem.
The Company's sole role is the deployment of the Smart Contracts, and accordingly any interaction with Liquidity Pools take place solely on the relevant Blockchain Network. It is important that you understand that smart contract protocols such as Meteora simply comprise a set of autonomous blockchain-based smart contracts deployed on the relevant Blockchain Network, operated directly by users calling functions on it (which allows them to interact with other users in a multi-party peer-to-peer manner). There is no further control by or interaction with the original entity which had deployed the smart contract (i.e. the Company), which entity solely functions as a provider of technical tools for users, and is not offering any sort of securities product or regulated service nor does it hold any user assets on custody. Any rewards earned by user interactions arise solely out of their involvement in the protocol by taking on the risk of interacting with other users and the ecosystem.
Meteora Nova Limited (the "Company", "we", "our" or "us") is making the App available to you. Before you use the App, the Smart Contracts, or the Site, however, you will need to agree to these Terms of Use and any terms and conditions incorporated herein by reference (collectively, these "Terms"). PLEASE READ THESE TERMS CAREFULLY BEFORE USING THE APP, THE SMART CONTRACTS, OR THE SITE. THESE TERMS GOVERN YOUR USE OF THE APP, THE SMART CONTRACTS, AND THE SITE, UNLESS WE HAVE EXECUTED A SEPARATE WRITTEN AGREEMENT WITH YOU FOR THAT PURPOSE. WE ARE ONLY WILLING TO MAKE THE APP, THE SMART CONTRACTS, AND THE SITE AVAILABLE TO YOU IF YOU ACCEPT ALL OF THESE TERMS. BY USING THE APP, THE SMART CONTRACTS, THE SITE, OR ANY PART OF THEM, OR BY CLICKING "I ACCEPT" BELOW OR INDICATING YOUR ACCEPTANCE IN AN ADJOINING BOX, YOU ARE CONFIRMING THAT YOU UNDERSTAND AND AGREE TO BE BOUND BY ALL OF THESE TERMS. IF YOU ARE ACCEPTING THESE TERMS ON BEHALF OF A COMPANY OR OTHER LEGAL ENTITY, YOU REPRESENT THAT YOU HAVE THE LEGAL AUTHORITY TO ACCEPT THESE TERMS ON THAT ENTITY’S BEHALF, IN WHICH CASE "YOU" WILL MEAN THAT ENTITY. IF YOU DO NOT HAVE SUCH AUTHORITY, OR IF YOU DO NOT ACCEPT ALL OF THESE TERMS, THEN WE ARE UNWILLING TO MAKE THE APP, THE SMART CONTRACTS, OR THE SITE AVAILABLE TO YOU. IF YOU DO NOT AGREE TO THESE TERMS, YOU MAY NOT ACCESS OR USE THE APP, THE SMART CONTRACTS, OR THE SITE.
By clicking "I Accept" or otherwise indicating your Acceptance, you agree to be bound by these Terms and affirm that you are of legal age to enter into these Terms where you live and have the legal capacity to enter into these Terms. Without limiting the foregoing, by using the App, you acknowledge and understand that laws regarding digital assets, financial instruments, or investment products which may include digital assets, may vary from jurisdiction to jurisdiction, and it is your sole obligation to ensure that you fully comply with any law, regulation or directive, relevant to your jurisdiction with regard to the use of the App. For the avoidance of doubt, the ability to access the App does not necessarily mean that the App, or your activities through it, are legal under the laws, regulations or directives relevant to your jurisdiction. All of the App or the services made available through the App may not be available to all users, and we reserve the right to assess or reassess at any time your eligibility to use all or part of the App. The App does not constitute, and may not be used for the purposes of, an offer or solicitation to anyone in any jurisdiction in which such offer or solicitation is not authorised, or to any person to whom it is unlawful to make such an offer or solicitation.
Supplemental terms and conditions or documents that may be posted on the App from time to time are hereby expressly incorporated herein by reference. We reserve the right, in our sole discretion, to make changes to the Terms from time to time. We will alert you of any changes by updating the “Last Updated" date of these Terms (on the first page hereof), and you waive any right to receive specific notice of each such change. It is your responsibility to periodically review these Terms to stay informed of updates. You will be subject to and will be deemed to have been made aware of and to have accepted, the changes in any revised Terms by your continued use of the Site, the App, and the Smart Contracts after the date such revised Terms are posted.
***
## Table of Contents
1. [Introduction](#1-introduction)
2. [The App](#2-the-app)
3. [Services](#3-services)
4. [Fees and Payment](#4-fees-and-payment)
5. [Intellectual Property and Content](#5-intellectual-property-and-content)
6. [User Terms](#6-user-terms)
7. [Risks Borne by Users](#7-risks-borne-by-users)
8. [External Sites](#8-external-sites)
9. [Disclaimers](#9-disclaimers)
10. [Limitation of Liability](#10-limitation-of-liability)
11. [Indemnity](#11-indemnity)
12. [Privacy Policy](#12-privacy-policy)
13. [Consent to Electronic Disclosures and Signatures](#13-consent-to-electronic-disclosures-and-signatures)
14. [Governing Law and Dispute Resolution](#14-governing-law-and-dispute-resolution)
15. [Notices](#15-notices)
16. [Entire Agreement](#16-entire-agreement)
17. [Force Majeure](#17-force-majeure)
18. [Third Party Rights](#18-third-party-rights)
19. [No Agency or Partnership](#19-no-agency-or-partnership)
20. [Interpretation](#20-interpretation)
21. [Assignment](#21-assignment)
22. [Illegality](#22-illegality)
23. [Waiver](#23-waiver)
24. [Severability](#24-severability)
25. [Survival](#25-survival)
26. [English Language](#26-english-language)
***
## 1. Introduction
1. To be eligible to use the App, the Smart Contracts, the Site and the Services (as defined below), you must be of legal age to enter into these Terms where you live and have the legal capacity to enter into these Terms. The App, the Smart Contracts, the Site and the Services is strictly NOT offered to persons or entities who reside in, are citizens of, are incorporated in, or have a registered office in any Restricted Territory, as defined below (any such person or entity from a Restricted Territory shall be a Restricted Person). If you are a Restricted Person, then do not attempt to access or use the App, the Smart Contracts, the Site or the Services. Use of a virtual private network (e.g., a VPN) or other means by Restricted Persons to access or use the App, the Smart Contracts, the Site or the Services is prohibited. **Restricted Territory** means the British Virgin Islands, the United States, China, Myanmar (Burma), Cote D'Ivoire (Ivory Coast), Cuba, Crimea and Sevastopol, Democratic Republic of Congo, Iran, Iraq, Libya, Mali, Nicaragua, Democratic People’s Republic of Korea (North Korea), Somalia, Sudan, Syria, Yemen, Zimbabwe, Russia, or any other state, country or region that is subject to sanctions enforced by the United States or the European Union.
2. The App, the Smart Contracts, the Site or the Services made available through the App (or any portion thereof) may not be available to all users, and we reserve the right to assess or reassess at any time your eligibility to use all or part of the App, the Smart Contracts, the Site or the Services.
3. The App, the Smart Contracts, the Site and the Services does not constitute, and may not be used for the purposes of, an offer or solicitation to anyone in any jurisdiction in which such offer or solicitation is not authorised, or to any person to whom it is unlawful to make such an offer or solicitation.
4. Without limiting the foregoing, by using the App, the Smart Contracts, the Site or the Services, you acknowledge and understand that laws regarding digital assets, cryptocurrency derivatives, financial instruments, or investment products which may include digital assets, may vary from jurisdiction to jurisdiction, and it is your sole obligation to ensure that you fully comply with any law, regulation or directive, relevant to your jurisdiction with regard to the use of the App, the Smart Contracts, the Site or the Services. For the avoidance of doubt, the ability to access the App, the Smart Contracts, the Site or the Services does not necessarily mean that same (or your activities through it) are legal under the laws, regulations or directives relevant to your jurisdiction.
## 2. The App
1. To most easily access the App, you may first install a web browser (such as the Google Chrome web browser) and an electronic wallet compatible with the relevant Blockchain Network, such as the Phantom or Solflare electronic wallet. These electronic wallet services provide a visual representation allowing you to interact with the relevant Blockchain Network to purchase, store, and engage in transactions with various digital assets. You will not be able to engage in any transactions on the App other than through your selected electronic wallet service, or other browsers compatible with the relevant Blockchain Network.
2. Transactions that take place via the visual user interface on the App are confirmed via the relevant Blockchain Network. You understand that your public address on the relevant Blockchain Network will be made publicly visible whenever you engage in a transaction on the App.
3. The visual user interface provided on the Website facilitates your ability to access Meteora. The interface is distinct from the decentralised Meteora network. Meteora is public, permissionless, and runs on open-source self-executing software; while the interface itself merely enables you to initiate messages to Meteora in order to perform functions or access Services thereon. The interface is one of the means of accessing Meteora, but not the exclusive means of access.
4. Meteora is a non-custodial protocol, therefore the App does not hold or control your digital assets. Any digital assets which you may acquire through the usage of the App will be held and administered solely by you through your selected electronic wallet, and we shall have no access to or responsibility in regard to such electronic wallet or digital asset held therein. It is solely your responsibility to select the wallet service provider to use in connection with the App, and your use of such electronic wallet will be subject to the governing terms of use or privacy policy of the provider of such wallet. We neither own nor control your selected electronic wallet service, Google Chrome, any electronic wallet, the relevant Blockchain Network, or any other third party site, product, or service that you might access, visit, or use for the purpose of enabling you to use the various features of the App. We will not be liable for the acts or omissions of any such third parties, nor will we be liable for any damage that you may suffer as a result of your transactions or any other interaction with any such third parties.
5. The Company will not create any hosted wallet for you or otherwise custody digital assets on your behalf, and it is your sole responsibility to maintain the security of your selected electronic wallet. In the event that you lose access to your electronic wallet, private key(s), password(s), or other method(s) of securing your wallet, all digital assets held in such wallet may be irretrievable, and the Company will be unable to assist you in any way. You hereby irrevocably waive, release and discharge all claims, whether known or unknown to you, against the Company, its affiliates and their respective shareholders, members, directors, officers, employees, agents and representatives related to your use of any wallet software, associated loss of digital assets, transaction failures, or any other defects that arise in the course of your use of your electronic wallet, including any losses that may obtain as a result of any failure of any Smart Contracts, the Site or the App.
6. The Company reserves the right to modify, suspend or discontinue, temporarily or permanently, all or any part of the Site or the App with or without notice. You agree that the Company will not be liable to you or to any third party for any modification, suspension or discontinuance of all or any part of the Site or the App.
7. The publicly deployed Smart Contracts you interact with are experimental in nature and you should not utilise the Smart Contracts or Liquidity Pools for deployment of any substantial amount of digital assets.
8. We reserve the right to disable access to the App, the Site or the interface at any time in the event of any breach of the Terms, including without limitation, if we, in our sole discretion, believe that you, at any time, fail to satisfy the eligibility requirements set forth in the Terms. Further, we reserve the right to limit or restrict access to the App or the Site by any person or entity, or within any geographic area or legal jurisdiction, at any time and at our sole discretion. We will not be liable to you for any losses or damages you may suffer as a result of or in connection with the App or the Site being inaccessible to you at any time or for any reason.
## 3. Services
1. The Company has deployed the Smart Contracts on the relevant Blockchain Network for users to utilise in accordance with these Terms. Users may directly call the functions of the Smart Contracts directly, or access them via the user interface provided by the App.
2. Meteora allows users to trade digital asset pairs directly in a peer-to-peer manner. Users will be able to act as market makers or liquidity providers for these transactions by staking/pooling their digital assets into decentralised liquidity pools (Liquidity Pools) to provide the necessary liquidity for transactions by other users. These digital assets may comprise various fungible cryptocurrencies in the market.
3. Liquidity Pools and the underlying digital asset pairings will be selected and created by liquidity providers, who allow other users to access these Liquidity Pools to conduct trades. Any party may trade and/or become a liquidity provider (LP) for a pool by depositing an equivalent value of each underlying token to the Liquidity Pool in return for pool tokens (LP tokens). All trades conducted via Meteora would be performed in a non-custodial manner and users remain in control of their digital assets. Through allocating different amounts of tokens at diverse price points, project teams are able to build their desired liquidity shape with the DLMM that best fits their liquidity provider (LP) goals.
4. All interactions between liquidity providers and traders on Meteora operate in a peer-to-peer manner. Liquidity providers and traders on Meteora enter into a direct contractual relationship via the autonomous Smart Contracts and/or other smart contracts deployed by various other third party networks, and therefore liquidity providers wholly assume all responsibility towards the user of the Liquidity Pools. There is no further control by or interaction with the Company (or the relevant affiliate) which had deployed the Smart Contract(s). The Company and its affiliates shall in no circumstances be construed as a party to said peer-to-peer direct contractual relationship, is not liable for performance of obligations thereunder, nor does it bear any financial or commercial risk or provide any warranties or assurances in connection with the same.
5. The App merely provides a visual user interface allowing users to interact with Liquidity Pools and to access liquidity provided by liquidity providers, and does not act as an agent for any of the users. Although the App is intended to display accurate and timely information regarding Liquidity Pools and possible swaps, the App or relevant tools/information may not always be entirely accurate, complete or current and may also include technical inaccuracies or typographical errors. The pricing information data provided through the App does not represent an offer, a solicitation of an offer, or any advice regarding, or recommendation to enter into, a transaction with the Company or the App. Accordingly, users should verify all information before relying on it, and all decisions based on information contained on the App or tools/information tools are at the sole responsibility of each user. Notwithstanding any of the other provisions in these Terms, any photographs, graphic illustrations, videos, models, charts, designs, or examples on the site are strictly for information purposes only and have no contractual value nor do they form the basis of any contract with the Company.
6. Neither the Company, the Site nor the App provides any digital asset exchange or portfolio/fund management services in connection with the Liquidity Pools. If you choose to engage in transactions with liquidity providers in Liquidity Pools or any other users, then such decisions and transactions and any consequences flowing therefrom are your sole responsibility. In no event shall the Company, its affiliates or their respective directors or employees be responsible or liable to you or anyone else, directly or indirectly, for any damage or loss arising from or relating to any interaction or continued interaction with Liquidity Pools, or reliance on any information provided on the Site or the App (including, without limitation, directly or indirectly resulting from errors in, omissions of or alterations to any such information).
7. THE APP SOLELY FUNCTIONS AS A VISUAL USER INTERFACE. IN NO CIRCUMSTANCES SHALL THE COMPANY, THE SMART CONTRACTS, THE SITE OR THE APP BE CONSTRUED AS A DIGITAL ASSET EXCHANGE, BROKER, DEALER, FUND MANAGER, FINANCIAL INSTITUTION, EXCHANGE, CUSTODIAN, ROBO-ADVISOR, INTERMEDIARY, OR CREDITOR. THE SITE DOES FACILITATE OR ARRANGE TRANSACTIONS BETWEEN BUYERS AND SELLERS, INCLUDING WITH RESPECT TO ANY TRANSACTIONS THAT OCCUR IN CONNECTION WITH A LIQUIDITY POOL, WHICH TRANSACTIONS OCCUR ON THE RELEVANT BLOCKCHAIN NETWORK. THE COMPANY IS NOT A COUNTERPARTY TO ANY TRANSACTION FACILITATED BY THE SMART CONTRACTS, THE SITE OR THE APP OR FOR ANY USER OF THE SITE. NEITHER THE SMART CONTRACTS, THE SITE OR THE APP PROVIDES FINANCIAL ADVISORY, LEGAL, REGULATORY, OR TAX SERVICES DIRECTLY, INDIRECTLY, IMPLICITLY, OR IN ANY OTHER MANNER, AND YOU SHOULD NOT CONSIDER ANY CONTENT CONTAINED IN THESE TERMS OR OTHERWISE POSTED ON THE SITE TO BE A SUBSTITUTE FOR PROFESSIONAL FINANCIAL, LEGAL, REGULATORY, TAX OR OTHER ADVICE. THE COMPANY DOES NOT SUPPORT OR ENDORSE ANY LIQUIDITY POOL CREATED BY ANY USER OF METEORA, AND EACH SUCH CREATOR IS AN INDEPENDENT AGENT WITH NO EMPLOYMENT OR OTHER CONTRACTUAL RELATIONSHIP WITH THE COMPANY.
8. The Company reserves the right to suspend or terminate access to the Site or the App by any creator of Liquidity Pools or user of Liquidity Pools for any reason whatsoever (including without limitation for a breach of these Terms). You agree that the Company will not be liable to you or to any third party for any suspension or termination of any user.
9. Access to the Smart Contracts, the App or the Site may become degraded or unavailable during times of significant volatility or volume. This could result in the inability to interact with third-party services for periods of time and may also lead to support response time delays. The Company cannot guarantee that the Smart Contracts, the App or the Site will be available without interruption and neither do we guarantee that requests to interact with third-party services will be successful.
## 4. Fees and Payment
1. If you elect to interact with Liquidity Pools, all transactions will be conducted solely through the relevant Blockchain Network. We will have no insight into or control over these payments or transactions, nor do we have the ability to reverse any transactions. With that in mind, we will have no liability to you or to any third party for any claims or damages that may arise as a result of any transactions that you engage in via the App, or using the Smart Contracts, or any other transactions that you conduct via the relevant Blockchain Network.
2. The relevant Blockchain Network typically requires the payment of a transaction fee (a "**Gas Fee**") for every transaction that occurs on the relevant Blockchain Network. The Gas Fee funds the network of computers that run the decentralised network. This means that you will need to pay a Gas Fee for each transaction that occurs via the Smart Contracts.
3. You may be subject to certain additional fees and commissions, including fees imposed by creators of Liquidity Pools for accessing and utilising the Liquidity Pools as notified to you prior to engaging with any digital asset swap or liquidity provision. The Company also reserves the right to levy additional fees for access via the Smart Contracts, the Site or the App in the future. You agree to promptly pay all aforementioned fees and commissions.
4. Notwithstanding anything in these Terms to the contrary, you will be solely responsible to pay any and all sales, use, value-added and other taxes, duties, and assessments (except taxes on the Company's net income) now or hereafter claimed or imposed by any governmental authority (collectively, "**Taxes**") associated with your use of the App (including, without limitation, any Taxes that may become payable as the result of your ownership or transfer of digital assets or interaction with any Liquidity Pool, or relating to Meteora).
## 5. Intellectual Property and Content
1. The Company owns the Site and the App. You acknowledge and agree that the Company (or, as applicable, its affiliates) owns all legal right, title and interest in and to all other elements of the site and the App, and all intellectual property rights therein (including, without limitation, all designs, systems, methods, information, computer code, software, services, website design, "look and feel", organisation, compilation of the content, code, data and database, functionality, audio, video, text, photograph, graphics, copyright, trademarks (if any), and all other elements of the App (collectively, the "**Materials**"). You acknowledge that the Materials are protected by copyright, trade dress, patent, and trademark laws, international conventions, other relevant intellectual property and proprietary rights, and applicable laws. All Materials are the copyrighted property of The Company or its licensors, and all trademarks, service marks, and trade names associated with the App or otherwise contained in the Materials are proprietary to The Company or its licensors. Except as expressly set forth herein, your use of the App does not grant you ownership of or any other rights with respect to any content, code, data, or other Materials that you may access on or through the App. We reserve all rights in and to the Materials that are not expressly granted to you in these Terms. For the sake of clarity, you understand and agree: that (a) your interaction with Liquidity Pools or usage of the Smart Contracts, the Site or the App does not give you any rights or licenses in or to the Materials other than those expressly contained in these Terms; (b) you do not have the right to license, sell, rent, lease, transfer, assign, distribute, host, reproduce, distribute, or otherwise commercialise any elements of the Materials without our prior written consent in each case, which consent we may withhold in our sole and absolute discretion; (c) you shall not modify, make derivative works of, disassemble, reverse compile or reverse engineer any part of the Materials; and (d) you will not apply for, register, or otherwise use or attempt to use any of the Company's trademarks or service marks, or any confusingly similar marks, anywhere in the world.
2. By interacting with Liquidity Pools, you are granted a limited, non-exclusive, non-transferable, revocable license to use the site and the App for your personal use. Neither these Terms nor your access to the Smart Contracts, the site and the App transfers to you or any third party any rights, title or interest in or to intellectual property rights in the Materials, except for the limited access rights expressly set forth in these Terms. The Company expressly reserves all rights not granted in these Terms. There are no implied licenses granted under these Terms.
3. By acceptance of these Terms, you agree and acknowledge that all information and content provided by you, including your username, your contact list, Liquidity Pools created or Liquidity Pools interacted with, any messages, posts, comments or user generated content (the "UGC") in any communication channel (including without limitation Twitter, Discord or Telegram) shall be considered non-confidential and non-proprietary information. By providing such UGC, you specifically grant the Company a non-exclusive, irrevocable, transferable, sub-licensable, royalty-free, worldwide license to use, copy, duplicate store, present and publish all or any part of the UGC, and the Company shall be free to use such UGC in any manner or media whatsoever, on an unrestricted basis and without any attribution or royalties or other compensation to you, including, without limitation, within or outside the Site or the App, and in any digital or printed media.
4. You acknowledge that you shall be responsible for any UGC that you submit or transmit through the Site or the App, including your responsibility as to the legality, reliability, appropriateness, originality and copyright of any such information or material. Additionally, you represent and warrant that: (a) you own all right title and interest in any UGC provided by you, (b) such UGC does not violate any applicable laws, and (c) the posting of your UGC by us (in any manner or media whatsoever, on an unrestricted basis) does not (and will not) violate the privacy rights, publicity rights, copyright, contract rights or any other rights of any individual or make derogatory remarks regarding, defame or otherwise criticise any person or entity. You shall be solely liable for any damage resulting from any infringement or other violation of the copyright, trademarks or other proprietary rights of any individual or entity, and for any other harm or losses resulting from any UGC.
5. You acknowledge and agree that any questions, comments, suggestions, ideas, feedback or other information regarding the Smart Contracts, the Site and the App ("Feedback") provided by you to us are non-confidential and should become our sole property. We should own exclusive rights, including all intellectual property rights, and should be entitled to the unrestricted use and dissemination of these Feedback to any lawful purpose, commercial, or otherwise, without acknowledgment or compensation for you. You hereby waive any moral rights to any such Feedback, and you hereby warrant that any such Feedback are original with you or that you have the right to submit such Feedback. You agree there should be no recourse against us for any alleged or actual infringement or misappropriation of any proprietary right in your Feedback.
## 6. User Terms
1. You agree that you are responsible for your own conduct while accessing or using the App, and for any consequences thereof. You agree to use the App only for purposes that are legal, proper and in accordance with these Terms and any applicable laws or regulations, including without limitation you may not, and may not allow any third party to: (a) send, upload, distribute or disseminate any unlawful, defamatory, harassing, abusive, fraudulent, obscene, or otherwise objectionable content; (b) distribute viruses, worms, defects, Trojan horses, corrupted files, hoaxes, or any other items of a destructive or deceptive nature; (c) impersonate another person (via the use of an email address or otherwise); (d) upload, post, transmit or otherwise make available through the App any content that infringes the intellectual proprietary rights of any party; (e) use the App to violate the legal rights (such as rights of privacy and publicity) of others; (f) engage in, promote, or encourage illegal activity (including, without limitation, money laundering); (g) interfere with other users' enjoyment of the App; (h) exploit the App for any unauthorised commercial purpose; (i) modify, adapt, translate, decompile, disassemble or reverse engineer any portion of the App; (j) attempt to bypass any measure of the Site designed to prevent or restrict access to the Site, or any portion of the Site or the App; (k) harass, intimidate, or threaten any of our employees or agents engaged in providing any portion of the Site or the App to you; (l) remove any copyright, trademark or other proprietary rights notices contained in or on the App, the Contents or any part of it; (m) reformat or frame any portion of the App; (n) display any content on the App that contains any hate-related or violent content or contains any other material, products or services that violate or encourage conduct that would violate any criminal laws, any other applicable laws, or any third party rights; (o) use any robot, spider, site search/retrieval application, or other device to retrieve or index any portion of the App or the content posted on the App, or to collect information about its users for any unauthorised purpose; (p) upload or transmit (or attempt to upload or to transmit) any material that acts as a passive or active information collection or transmission mechanism, including without limitation, clear graphics interchange formats (“gifs”), 1×1 pixels, web bugs, cookies, or other similar devices (sometimes referred to as “spyware” or “passive collection mechanisms” or “pcms”); (q) access or use the App by automated means or under false or fraudulent pretences; (r) access or use the App for the purpose of, directly or indirectly, creating or enabling a party to create a product or service that is competitive with any of our products or services; (s) use the Site, the App and the Smart Contracts to advertise or offer to sell goods and services; (t) conduct any activity that violates any applicable law, rule, or regulation concerning the integrity of trading markets, including (but not limited to) the manipulative tactics commonly known as spoofing, wash trading, cornering, accommodation trading, fictitious transactions, "money pass" (i.e. transactions without a net change in either party's open positions but with a resulting profit to one party and a loss to the other party), front-running, or pre-arranged or non-competitive transactions, or transactions designed to mislead external parties, or (u) disparage, tarnish, or otherwise harm, in our opinion, us and/or the Site, the App, and the Smart Contracts. If you engage in any of the activities prohibited by this Section 6, we may, at our sole and absolute discretion, without notice to you, and without limiting any of our other rights or remedies at law or in equity, immediately suspend or terminate your access to the Site or the App and delete your UGC from the Site.
2. By using the Site, the App and the Smart Contracts, you represent and warrant that: (a) you have read and understood these Terms and all documentation on the App or the Site; (b) you have good and sufficient experience and understanding of the functionality, usage, storage, transmission mechanisms and other material characteristics of cryptographic tokens, token storage mechanisms (such as token wallets), blockchain technology, blockchain-like technology and blockchain-based software systems to understand these Terms and to appreciate the risks and implications of creating or interacting with Liquidity Pools; (c) you acknowledge and agree that we may impose eligibility criteria to access certain functionality in respect of Meteora which may require you to incur additional time and money costs; (d) you create and interact with Liquidity Pools for your own account and shall not do the same on behalf of any other entity or person; (e) your creation or interaction with Liquidity Pools complies with applicable law and regulation in your jurisdiction, and the law and regulation of any jurisdiction to which you may be subject (including, but not limited to legal capacity and any other threshold requirements for creating and interacting with Liquidity Pools, and interacting with other users of Meteora, any foreign exchange or regulatory restrictions applicable to creating and interacting with Liquidity Pools, and any governmental or other consents that may need to be obtained); (f) all information you submit will be true, accurate, current, and complete (if you provide any information that is untrue, inaccurate, not current, or incomplete, we have the right to refuse or terminate your current or future use of the Site and the App (or any portion thereof)); (g) you will maintain the accuracy of such information and promptly update such information as necessary; (h) you have the legal capacity and you agree to comply with these Terms; (i) you are not a minor in the jurisdiction in which you reside; (j) you will not use the Site, the App and the Smart Contracts for any illegal and unauthorised purpose; (k) you will not use the Site, the App and the Smart Contracts for any commercial purpose (save as approved by the Company in writing); (l) your use of the Site, the App and the Smart Contracts will not violate any applicable law or regulation; and (m) any funds or digital assets staked or deposited in Liquidity Pools are not derived from or related to any unlawful activities, including but not limited to money laundering or terrorist financing and all applicable statutes of all jurisdictions in which you are located, resident, organised or operating, and/or to which it may otherwise be subject and the rules and regulations thereunder (collectively, the "Compliance Regulations"), and you will not use the Smart Contracts, the Site or the App to finance, engage in, or otherwise support any unlawful activities or in a manner which aids or facilitates another party in the same. To the extent required by applicable laws and regulations, you shall fully comply with all Compliance Regulations.
3. We reserve the right to (but shall not be obliged to in any event to) conduct "Know Your Customer" and "Anti-Money Laundering" checks on you (including digital address or wallet screening) if deemed necessary by us (at our sole discretion) or such checks become required under applicable laws in any jurisdiction. Upon our request, you shall immediately provide us with information and documents that we, in our sole discretion, deem necessary or appropriate to conduct "Know Your Customer" and "Anti-Money Laundering" checks. Such documents may include, but are not limited to, passports, driver's licenses, utility bills, photographs of associated individuals, government identification cards or sworn statements before notaries or other equivalent professionals. Notwithstanding anything herein, we may, in its sole discretion, refuse to provide access to the Site or the Site to you until such requested information is provided, or in the event that, based on information available to us, you are suspected of using the Smart Contracts, the Site or the App in connection with any money laundering, terrorism financing, or any other illegal activity. In addition, we shall be entitled to use any possible efforts for preventing money laundering, terrorism financing or any other illegal activity, including without limitation blocking of your access to the Smart Contracts, the App or the Site or providing your information to any regulatory authority.
4. You are responsible for complying with applicable laws (including tax laws) in connection with usage of the Smart Contracts, the Site, the App or interactions with Liquidity Pools. You agree that we are not responsible for determining whether or which laws may apply to said interactions. You are advised to consult your own lawyers regarding of the legality and implications of any such activities. You are solely responsible for reporting and paying any taxes arising from your usage of the Smart Contracts, the Site, the App or interactions with Liquidity Pools.
## 7. Risks Borne by Users
**IMPORTANT RISK NOTICE:** You acknowledge and agree that the Services, the Site and the App are currently in the initial development stages and there are a variety of unforeseeable risks with utilising the foregoing. In the worst scenario, this could lead to the loss of all or part of your digital assets interacting with the Services, the Site, the App or the Smart Contracts.
**IF YOU DECIDE TO UTILISE SERVICES YOU EXPRESSLY ACKNOWLEDGE, ACCEPT AND ASSUME THE BELOW RISKS AND AGREE NOT TO HOLD THE COMPANY OR ANY OF THEIR AFFILIATES RESPONSIBLE FOR THE FOLLOWING RISKS:**
2\. Using the App and interacting with Liquidity Pools carry financial risk. You acknowledge and agree that you are aware of such risks, including the following: (a) transactions relating to digital assets are very risky, and such digital assets are, by their nature, highly experimental, risky, volatile and generally irreversible. You should not make any transactional decision without first conducting your own research. You are solely and exclusively responsible for determining whether any Liquidity Pool, any transaction, or strategy, or any other product or service in connection with the same is appropriate or suitable for you based on your own objectives and personal and financial situation. You acknowledge and agree that you will access and use the Smart Contracts, the Site and the App and interact with Liquidity Pools at your own risk.
3\. You represent that you have sufficient knowledge, market sophistication, professional advice and experience to make your own evaluation of the merits and risks of any interaction with Liquidity Pools and the underlying digital assets. You accept all consequences of participating in such interactions, including the risk that you may lose access to your digital assets indefinitely. All decisions to interact with Liquidity Pools are made solely by you. Notwithstanding anything in these Terms, the Company accepts no responsibility whatsoever for and will in no circumstances be liable to you in connection with any interaction with Liquidity Pools and the underlying digital assets. Under no circumstances will the operation of all or any portion of the Smart Contracts, the Site or the App be deemed to create a relationship that includes any management of any assets, or the provision or tendering of investment advice.
4\. Digital assets are not legal tender, are not backed by the government, and are not subject to any "Deposit Insurance Scheme" or protections under any banking or securities laws. The Company is not a bank and does not offer any lending services, fiduciary services, or security broking services.
5\. The prices of blockchain assets are extremely volatile. Fluctuations in the price of other digital assets could materially and adversely affect the value of your digital assets held in Liquidity Pools, which may also be subject to significant price volatility. We cannot guarantee that any users interacting with Liquidity Pools will not lose money.
6\. Neither the Smart Contracts, Site, the App or Liquidity Pools hold in custody, store, send, or receive any of your digital assets. This is because your digital assets exist only by virtue of the ownership record maintained on the relevant Blockchain Network. Any transfer of digital assets occurs within the relevant Blockchain Network, and not on the Smart Contracts, Site, the App or Liquidity Pools.
7\. Public blockchain-based transactions (including but not limited to transactions automatically executed by smart contracts) are generally considered irreversible when confirmed. Any transaction that will interact with smart contracts or be recorded on a public blockchain must be recorded with extreme caution.
8\. All smart contracts (including the Smart Contracts) may contain security vulnerabilities, errors, failures, bugs or economic loopholes which may be exploited by third parties, causing you to suffer losses in connection with any digital assets re-deployed by Liquidity Pools. Interaction with these Smart Contracts are entirely at your own responsibility and liability, and the Company is not a party to the Smart Contracts.
9\. No creator of Liquidity Pools will be able to guarantee the future performance of digital assets held in a Liquidity Pool, any specific level of performance, the success of any strategy or your overall results from interacting with Liquidity Pools. When reviewing the information, portfolio, performance, opinions of these creators, do not assume that such party is unbiased, independent or qualified to provide financial information or opinions. Past performance and risk scores have many inherent limitations and are not indicative of future results. No representation or guarantee is being made that any creator of Liquidity Pools will or is likely to achieve gains or losses similar to the past performance. The actual percentage gains or losses experienced by users will vary depending on many factors.
10\. Hackers or other malicious groups or organisations may attempt to interfere with the Smart Contracts, the Site, the App or Liquidity Pools in a variety of ways, including, but not limited to, malware attacks, denial of service attacks, consensus-based attacks, Sybil attacks, smurfing and spoofing, which may result in losses incurred by you. Furthermore, because the relevant Blockchain Network comprises open-source software, there is the risk that the software underlying the Services may contain intentional or unintentional bugs or weaknesses that may negatively affect the Services or the Smart Contracts, or result in the loss of the user’s digital assets, or the loss of the user’s ability to access or control their digital assets. In the event of such a software bug or weakness, there may be no remedy, and users are not guaranteed any remedy, refund or compensation.
11\. Further, when you interact with Liquidity Pools or trade on any blockchain network, you accept that there is the inherent risk of the transaction being vulnerable to automated software programs (MEV bots) deployed by third parties which operate within decentralized finance (DeFi) ecosystem and exploit blockchain mechanics such as transaction ordering and gas price bidding to gain an advantage over specific users, or automated software programs (sniper bots) which executes trades buys or front-runs orders in respect of digital assets as soon as they are available on centralised or decentralised exchanges, which may be deployed by bad actors in connection with market manipulation or insider trading activities. The Company cannot be responsibility for losses suffered due to any of the foregoing, which are inherent to transactions on open blockchain networks.
12\. The regulatory status of digital assets, and distributed ledger technology is unclear or unsettled in many jurisdictions. While every effort has been taken to ensure that the Services, the Site, the App and the Smart Contracts are compliant with local laws, it is difficult to predict how or whether regulatory agencies may apply existing regulation with respect to the same. It is likewise difficult to predict how or whether legislatures or regulatory agencies may implement changes to law and regulation affecting distributed ledger technology and its applications, including the Services, the Site, the App or the Smart Contracts. Regulatory actions could negatively impact the Company in various ways, and thus the Services may not be available in certain areas.
13\. The underlying smart contracts run on a variety of supported blockchain networks, using specially-developed smart contracts. Accordingly, upgrades to the relevant Blockchain Network, a hard fork in the relevant Blockchain Network, re-organisations of blockchain structure or blocks, or a change in how transactions are confirmed on the relevant Blockchain Network may have unintended, adverse effects on the smart contracts built thereon, including the Smart Contracts.
14\. The Site, Services and Smart Contracts may rely on or utilise a variety of external third party services or software, including without limitation decentralised cloud storage services, analytics tools, oracles, hence therefore the Services may be adversely affected by any number of risks related to these third party services/software, which may be compromised in the event of security vulnerabilities, cyberattacks, malicious activity, or technical interruptions.
## 8. External Sites
The Site or the App may include hyperlinks to other web sites or resources (collectively, "External Sites"), which are provided solely for your convenience. We have no control over any External Sites. You acknowledge and agree that we are not responsible for the availability of any External Sites, and that we do not endorse any advertising, products or other materials on or made available from any External Sites. Furthermore, you acknowledge and agree that we are not liable for any loss or damage which may be incurred as a result of the availability or unavailability of the External Sites, or as a result of any reliance placed by you upon the completeness, accuracy or existence of any advertising, products or other materials on, or made available from, any External Sites.
## 9. Disclaimers
1. YOU EXPRESSLY UNDERSTAND AND AGREE THAT YOUR ACCESS TO AND USE OF THE SMART CONTRACTS, THE SITE, THE APP AND LIQUIDITY POOLS IS AT YOUR SOLE RISK, AND THAT THE APP IS PROVIDED "AS IS" AND "AS AVAILABLE" WITHOUT WARRANTIES OF ANY KIND, WHETHER EXPRESS OR IMPLIED. TO THE FULLEST EXTENT PERMISSIBLE PURSUANT TO APPLICABLE LAW, THE COMPANY, ITS SUBSIDIARIES, AFFILIATES, AND LICENSORS MAKE NO EXPRESS WARRANTIES AND HEREBY DISCLAIM ALL IMPLIED WARRANTIES REGARDING THE APP AND ANY PART OF IT (INCLUDING, WITHOUT LIMITATION, THE SMART CONTRACTS, THE SITE, THE APP, LIQUIDITY POOLS, OR ANY EXTERNAL WEBSITES), INCLUDING ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, CORRECTNESS, ACCURACY, OR RELIABILITY. WITHOUT LIMITING THE GENERALITY OF THE FOREGOING, THE COMPANY, ITS SUBSIDIARIES, AFFILIATES, AND LICENSORS DO NOT REPRESENT OR WARRANT TO YOU THAT: (A) YOUR ACCESS TO OR USE OF THE SMART CONTRACTS, THE SITE, THE APP AND LIQUIDITY POOLS WILL MEET YOUR REQUIREMENTS, (B) YOUR ACCESS TO OR USE OF THE SMART CONTRACTS, THE SITE, THE APP AND LIQUIDITY POOLS WILL BE UNINTERRUPTED, TIMELY, SECURE OR FREE FROM ERROR, (C) USAGE DATA PROVIDED THROUGH THE SMART CONTRACTS, THE SITE, THE APP AND LIQUIDITY POOLS WILL BE ACCURATE, (D) THE SMART CONTRACTS, THE SITE, THE APP AND LIQUIDITY POOLS, OR ANY CONTENT, SERVICES, OR FEATURES MADE AVAILABLE ON OR THROUGH THE SMART CONTRACTS, THE SITE, THE APP AND LIQUIDITY POOLS ARE FREE OF VIRUSES OR OTHER HARMFUL COMPONENTS, OR (E) THAT ANY DATA THAT YOU DISCLOSE WHEN YOU USE THE SMART CONTRACTS, THE SITE, THE APP AND LIQUIDITY POOLS WILL BE SECURE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES IN CONTRACTS WITH CONSUMERS, SO SOME OR ALL OF THE ABOVE EXCLUSIONS MAY NOT APPLY TO YOU.
2. YOU ACCEPT THE INHERENT SECURITY RISKS OF PROVIDING INFORMATION AND DEALING ONLINE OVER THE INTERNET, AND AGREE THAT THE COMPANY HAS NO LIABILITY OR RESPONSIBILITY FOR ANY BREACH OF SECURITY UNLESS IT IS DUE TO THE COMPANY'S WILFUL DEFAULT.
3. DIGITAL ASSETS ARE INTANGIBLE DIGITAL ASSETS THAT EXIST ONLY BY VIRTUE OF THE OWNERSHIP RECORD MAINTAINED IN THE RELEVANT BLOCKCHAIN NETWORK. ALL SMART CONTRACTS IN CONNECTION WITH METEORA ECOSYSTEM ARE DEPLOYED ON AND INTERACTIONS/TRANSACTIONS WITH THE SAME OCCUR ON THE DECENTRALISED LEDGER WITHIN THE RELEVANT BLOCKCHAIN NETWORK. WE HAVE NO CONTROL OVER AND MAKE NO GUARANTEES OR PROMISES WITH RESPECT TO SMART CONTRACTS.
4. THE COMPANY IS NOT RESPONSIBLE FOR LOSSES DUE TO BLOCKCHAINS OR ANY OTHER FEATURES OF THE RELEVANT BLOCKCHAIN NETWORK OR YOUR SELECTED ELECTRONIC WALLET SERVICE, INCLUDING BUT NOT LIMITED TO LATE REPORT BY DEVELOPERS OR REPRESENTATIVES (OR NO REPORT AT ALL) OF ANY ISSUES WITH THE BLOCKCHAIN SUPPORTING THE RELEVANT BLOCKCHAIN NETWORK, INCLUDING FORKS, TECHNICAL NODE ISSUES, OR ANY OTHER ISSUES HAVING FUND LOSSES AS A RESULT.
## 10. Limitation of Liability
1. YOU UNDERSTAND AND AGREE THAT WE, OUR SUBSIDIARIES, AFFILIATES, AND LICENSORS WILL NOT BE LIABLE TO YOU OR TO ANY THIRD PARTY FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, OR EXEMPLARY DAMAGES WHICH YOU MAY INCUR IN CONNECTION WITH THE SMART CONTRACTS, THE SITE, THE APP OR LIQUIDITY POOLS, HOWSOEVER CAUSED AND UNDER ANY THEORY OF LIABILITY, INCLUDING, WITHOUT LIMITATION, ANY LOSS OF PROFITS (WHETHER INCURRED DIRECTLY OR INDIRECTLY), LOSS OF GOODWILL OR BUSINESS REPUTATION, LOSS OF DATA, COST OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, OR ANY OTHER INTANGIBLE LOSS, EVEN IF WE HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
2. YOU AGREE THAT OUR TOTAL, AGGREGATE LIABILITY TO YOU FOR ANY AND ALL CLAIMS ARISING OUT OF OR RELATING TO THESE TERMS OR YOUR ACCESS TO OR USE OF (OR YOUR INABILITY TO ACCESS OR USE) ANY PORTION OF THE SMART CONTRACTS, THE SITE, THE APP OR LIQUIDITY POOLS, WHETHER IN CONTRACT, TORT, STRICT LIABILITY, OR ANY OTHER LEGAL THEORY, IS LIMITED TO THE LOWER OF (A) THE AMOUNTS YOU ACTUALLY PAID US UNDER THESE TERMS IN THE 12 MONTH PERIOD PRECEDING THE DATE THE CLAIM AROSE, OR (B) US\$200.
3. YOU ACKNOWLEDGE AND AGREE THAT WE HAVE MADE THE SMART CONTRACTS, THE SITE, THE APP AND LIQUIDITY POOLS AVAILABLE TO YOU AND ENTERED INTO THESE TERMS IN RELIANCE UPON THE WARRANTY DISCLAIMERS AND LIMITATIONS OF LIABILITY SET FORTH HEREIN, WHICH REFLECT A REASONABLE AND FAIR ALLOCATION OF RISK BETWEEN THE PARTIES AND FORM AN ESSENTIAL BASIS OF THE BARGAIN BETWEEN US. WE WOULD NOT BE ABLE TO PROVIDE THE APP TO YOU WITHOUT THESE LIMITATIONS.
4. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, AND SOME JURISDICTIONS ALSO LIMIT DISCLAIMERS OR LIMITATIONS OF LIABILITY FOR PERSONAL INJURY FROM CONSUMER PRODUCTS, SO THE ABOVE LIMITATIONS MAY NOT APPLY TO PERSONAL INJURY CLAIMS.
## 11. Indemnity
You agree to hold harmless and indemnify the Company and its subsidiaries, affiliates, officers, agents, employees, advertisers, licensors, suppliers or partners from and against any claim, liability, loss, damage (actual and consequential) of any kind or nature, suit, judgment, litigation cost, and attorneys' fees arising out of or in any way related to (a) your breach of these Terms, (b) your misuse of the Smart Contracts, the Site, the App or the Liquidity Pools, or (c) your violation of any applicable laws, rules or regulations in connection with your access to or use of the App. You agree that the Company will have control of the defence or settlement of any such claims.
## 12. Privacy Policy
1. Our [Privacy Policy](/resources/legal/privacy-policy) describes the ways the Company collects, uses, stores and discloses your personal information, and is hereby incorporated by this reference into these Terms. You agree to the collection, use, storage, and disclosure of your data in accordance with the aforementioned Privacy Policy.
2. The Company will maintain certain data that you transmit to the Site and the App for the purpose of managing the performance of the Site and the App, as well as data relating to your use of the Site or the App. Although we perform regular routine backups of data, the Company is solely responsible for all data that you transmit or that release to any activity you have undertaken using the Site or the App. You agree that we shall have no liability to you for any loss or corruption of any such data, and you hereby waive any right of action against us arising from any such loss or corruption of such data.
## 13. Consent to Electronic Disclosures and Signatures
1. Because the Company operates only on the Internet, it is necessary for you to consent to transact business with us online and electronically. As part of doing business with us, therefore, we also need you to consent to our providing you certain disclosures electronically via the Site. By agreeing to these Terms, you agree to receive electronically all documents, communications, notices, contracts, and agreements arising from or relating to your use of the Site and Services.
2. By accepting these Terms or contacting us in any manner, you expressly consent to be contacted by us, our agents, representatives, affiliates, or anyone calling on our behalf for any and all purposes, in any way, including notifications, messages and/or calls delivered using automated systems. Notwithstanding the aforementioned, any form of communication from the Company will be provided to you electronically through the Site or (if applicable) via email to the email address provided. If you require paper copies of any agreements or disclosures, you may print such documents desired.
3. Your consent to receive disclosures and transact business electronically, and our agreement to do so, applies to any transactions to which such disclosures relate, whether between you and the Company or a third party by and through the Services. Your consent will remain in effect for so long as you are a user and, if you are no longer a user, will continue until such a time as all disclosures relevant to Services received through the Site.
4. You may withdraw your consent to receive agreements or disclosures electronically by contacting us at [meteora\_support@meteora.ag](mailto:meteora_support@meteora.ag). However, once you have withdrawn your consent you will not be able to access the Services or the Site.
## 14. Governing Law and Dispute Resolution
1. These Terms will be governed by and construed in accordance with the laws of the British Virgin Islands, without regard to conflict of law rules and principles (whether of the British Virgin Islands or any other jurisdiction) that would cause the application of the laws of any other jurisdiction.
2. All disputes arising out of or in connection with these Terms (including without limitation the enforceability of this Section 14 or any question regarding its existence, validity or termination, your access or use of the App, the Site, or the Smart Contracts, or to any products sold or distributed through the App, the Site, or the Smart Contracts) shall be referred to and finally resolved by arbitration administered by arbitration in accordance with the BVI IAC Arbitration Rules for the time being in force, which rules are deemed to be incorporated by reference in this Section 14. The place of arbitration shall be Road Town, Tortola, British Virgin Islands, unless the Parties agree otherwise. The number of arbitrators shall be one. The language to be used in the arbitral proceedings shall be English. The award of the arbitrator will be final and binding, and any judgment on the award rendered by the arbitrator may be entered in any court of competent jurisdiction. Each party will cover its own fees and costs associated with the arbitration proceedings. Notwithstanding the foregoing, the Company may seek and obtain injunctive relief in any jurisdiction in any court of competent jurisdiction, and you agree that these Terms are specifically enforceable by the Company through injunctive relief and other equitable remedies without proof of monetary damages.
## 15. Notices
To give us notice under these Terms, the user must contact the Company by email at [meteora\_support@meteora.ag](mailto:meteora_support@meteora.ag)
## 16. Entire Agreement
These Terms constitute the entire legal agreement between you and the Company, govern your access to and use of the Smart Contracts, the Site, the App or the Liquidity Pools, and completely replace any prior or contemporaneous agreements between the parties related to your access to or use of the Smart Contracts, the Site, the App or the Liquidity Pools, whether oral or written.
## 17. Force Majeure
The Company shall not be liable for delays, failure in performance or interruption of service which result directly or indirectly from any cause or condition beyond its reasonable control, including but not limited to, significant market volatility, any delay or failure due to any act of God, act of civil or military authorities, act of terrorists, civil disturbance, war, strike or other labour dispute, fire, interruption in telecommunications or Internet services or network provider services, failure of equipment and/or software, other catastrophe or any other occurrence which is beyond its reasonable control, and shall not affect the validity and enforceability of any remaining provisions.
## 18. Third Party Rights
There are no third party beneficiaries to these Terms. A person who is not a party under these Terms has no right under any applicable law to enforce or to enjoy the benefit of these Terms.
## 19. No Agency or Partnership
Nothing in these Terms create any agency, partnership, joint venture or any similar relationship between the Company and you, nor cause the Company and you to be deemed acting in concert in any respect.
## 20. Interpretation
The language in these Terms will be interpreted as to its fair meaning, and not strictly for or against any party.
## 21. Assignment
You may not assign any or your rights or obligations under these Terms, whether by operation of law or otherwise, without our prior written consent. Notwithstanding anything contained herein, we may assign our rights and obligations under these Terms in our sole discretion (without your consent) to an affiliate for any reason, including without limitation any assignment or novation in connection with a reincorporation to change the Company's domicile.
## 22. Illegality
Should any provision or part-provision of these Terms is or becomes invalid, illegal or unenforceable in any respect under any law of any jurisdiction, it shall be deemed modified to the minimum extent necessary to make it valid, legal and enforceable; if such modification is not possible, the relevant provision or part-provision shall be deemed deleted. Any modification to or deletion of a provision or part-provision pursuant to this Section 22 shall not affect or impair the validity and enforceability of the rest of these Terms, nor the validity and enforceability of such provision or part-provision under the law of any other jurisdiction.
## 23. Waiver
Our failure to enforce any provision of these Terms will not be deemed a waiver of such provision, nor of the right to enforce such provision.
## 24. Severability
If any provision of these Terms shall be determined to be invalid or unenforceable under any rule, law, or regulation of any local, state, or federal government agency, such provision will be changed and interpreted to accomplish the objectives of the provision to the greatest extent possible under any applicable law and the validity or enforceability of any other provision of these Terms shall not be affected. If such construction is not possible, the invalid or unenforceable portion will be severed from these Terms but the rest of these Terms will remain in full force and effect.
## 25. Survival
The following provisions of these Terms shall survive termination of your use or access to the Site: Sections 5, 9, 10, 11, 14, and any other provision that by its terms survives termination of your use or access to the Site.
## 26. English Language
Notwithstanding any other provision of these Terms, any translation of these Terms is provided for your convenience. The meanings of terms, conditions, and representations herein are subject to their definitions and interpretations in the English language. In the event of conflict or ambiguity between the English language version and translated versions of these terms, the English language version shall prevail. You acknowledge that you have read and understood the English language version of these Terms.
# Brand Kit
Source: https://docs.meteora.ag/resources/miscellaneous/brand-kit
Download the Meteora brand kit with official logos and symbols.
Download the complete Meteora brand kit consisting of logos and symbols.
# How to become a Liquidity Provider
Source: https://docs.meteora.ag/user-guides/becoming-a-liquidity-provider
Learn what liquidity providers do, how AMMs work, how LPs earn fees and incentives, and how Meteora's DLMM, DAMM v1, and DAMM v2 pools differ.
## What is a Liquidity Provider?
As a liquidity provider (LP), you deposit tokens into a liquidity pool and these tokens can then be used by traders for swapping.
## Why become a Liquidity Provider?
You can earn fees or rewards whenever a trade occurs using the liquidity you deposited into the pool. The fees or rewards are typically proportional to your share of the pool.
You get to earn:
* Swap fees (also known as LP fees)
* Bonus incentives (e.g. yield farming rewards, protocol incentives)
you may not get the same amount of tokens back as you initially deposited into the liquidity pool. You may get less of one token and more of the other depending on price changes (on one or both of the tokens) because you are allowing traders to swap your tokens in exchange for an LP fee.
## What is an AMM?
An Automated Market Maker (AMM) is a type of decentralized exchange (DEX) protocol.
In traditional exchanges, a centralized orderbook matches the specific orders placed by individual buyers and sellers, and this is usually facilitated by an intermediary. Unlike traditional exchanges, AMMs use smart contracts on the Solana blockchain to enable traders to trade against the tokens deposited in a liquidity pool.
The price of token assets in an AMM is determined algorithmically, based on a pricing formula. The most common formula is the “constant product” formula, `x * y = k`, where:
* `x` = amount of Token A in the pool
* `y` = amount of Token B in the pool
* `k` = a constant value that never changes
`k` = a constant value that never changes
When someone makes a trade, the AMM adjusts the token balances in the pool such that the product x \* y remains constant. In other words, the more users buy one token, the more expensive it becomes in the pool. Conversely, the more users sell one token, the cheaper it becomes in the pool.
* For **liquidity providers (LPs)**: In an AMM, LPs deposit different token asset pairs into liquidity pools so traders can trade against those tokens. In the most common constant product-based AMM, each token in the pair being deposited is usually of equivalent \$USD value (50:50). For example, LPs can deposit an equivalent value of SOL and USDC into a SOL-USDC liquidity pool.
* For **traders**: A trader or another smart contract can then interact directly with the AMM pool smart contract to swap one token for the other. For example, using SOL to swap for USDC in a SOL-USDC pool. This process can be done automatically on the blockchain with the exchange rate calculated based on a pre-defined mathematical formula and accounting for the available tokens in the pool. Hence the AMM can facilitate trades in a non-custodial, decentralized manner without an intermediary.
**LP Fees**: When trades are completed by utilizing the tokens in the liquidity pool, liquidity providers of that pool earn a portion of the fees based on their share of the total liquidity in the pool.
An example of such an AMM in operation is Meteora's DAMM v1 or DAMM v2.
## Differences between DLMM and DAMM v1/v2
### DLMM
Meteora’s DLMM (Dynamic Liquidity Market Maker) pools enable LPs to earn much more fees with their capital due to precise liquidity concentration with 0-slippage bins, flexible volatility strategies, and dynamic fees.
The liquidity of an asset pair is organized into discrete price bins. Tokens deposited in a liquidity bin can be swapped at the specific price for that particular bin, ensuring 0-slippage or price impact swaps for that bin. The asset pair market is established by aggregating all the different liquidity bins.
LPs have the flexibility to select their volatility strategy and adjust the price range (make it narrower or wider) to concentrate liquidity based on their preferences - helping them achieve higher capital efficiency. With the higher capital efficiency, DLMM LPs can support more volume (and earn more fees) with their liquidity position, compared to adding the same liquidity on a typical DEX.
In addition, DLMM allows for single-sided asset deposits, so LPs can deposit only one token in the pool to DCA (dollar cost average) to the other token in the pair. Single-sided asset deposits are also suited for token launches, where the project only deposits their base token in the pool first so users can purchase their token with USDC or SOL when the pool starts trading.
In addition, LPs earn dynamic fees that are designed to capture more value from market volatility.
Although DLMM LPs can potentially generate a lot more volume and fees, a DLMM pool can become "inactive" and stop earning fees whenever the active price goes out of the range set by the LP. As such, DLMM pools require more active management compared to Dynamic AMM pools.
DLMM pools also don't provide LP tokens upon adding liquidity, so once the pool is created, liquidity deposited cannot be locked permanently (unlike dynamic AMM pools).
Read an overview of DLMM [here](https://meteoraag.medium.com/dlmm-new-dynamic-liquidity-protocol-to-boost-lp-fees-on-solana-84867bad0907). Any user can create a new DLMM pool [here](https://app.meteora.ag/create).
### DAMM v1
DAMM v1 (Dynamic AMM v1) pools are pools with a constant product AMM (automated market maker) model that are relatively more straightforward to use for LPs.
Unlike DLMM, DAMM v1 pools have a fixed fee %, do not allow LPs to concentrate liquidity, and operate across the full price range so they won't become inactive. Therefore, dynamic pools do not require active management and rebalancing from LPs.
Assets in dynamic pools are also deposited directly into the vaults in the yield layer, so SOL/USDC/USDT assets will be dynamically allocated to external lending protocols to generate yield and rewards for LPs. LPs can receive yield from a few places — the AMM trading fees, the SOL/USDC/USDT lending interest, and any liquidity mining rewards collected from the platforms.
Creating a new dynamic pool is permissionless, meaning any user or developer can create a new pool without approval from the Meteora team.
In addition, with DAMM v1 pools, [memecoin creators have the option to "burn" their liquidity](https://x.com/MeteoraAG/status/1786045723953557507) by permanently locking the Meteora LP tokens (which represent the liquidity in a dynamic pool). Memecoin creators can compound and claim fees on permanently locked liquidity forever, even though they no longer have access to that liquidity. Memecoin creators can consider launching their memecoin with a Memecoin Pool, which is a subset of dynamic pools and has features specially catered to memecoin launches (e.g. a dynamic fee % schedule).
Read an overview of DAMM v1 [here](/legacy-products/damm-v1/what-is-damm-v1). Any user can create a new DAMM v1 pool [here](https://app.meteora.ag/create).
### DAMM v2
DAMM v2 (Dynamic AMM v2) is also a constant-product AMM pool that requires little upkeep from LPs and is relatively more straightforward to use.
However, it improves upon DAMM v1 by providing extensive configurability and features. This is to better support LPs, token launches, and launchpads, and help them win!
Key features include:
* SPL & Token 2022 support to enable a broad asset range
* Dynamic Fee to help maximize returns during high volatility
* Anti-Sniper mechanisms such as the Fee Scheduler (fees start higher at launch and drop over time) and Rate Limiter (fees increase depending on the trade size)
* Fee token selection (choose between Base + Quote token, or Quote token only)
* No auto-compounding of fees into the pool, for more versatile fee claims
* Transferrable liquidity position NFT to easily give ownership of your position to someone else
* Farming mechanism that is built directly into the program, not as a separate farm program
* Greater cost efficiency; creating a single DAMM v2 pool with a liquidity position costs \~0.022 SOL, compared to \~0.25 SOL for a DLMM Launch Pool
* Different options to lock liquidity; option to lock liquidity with vesting (non-permanent) or permanently, while still allowing fee claims.
* Single-sided liquidity pools using only one token for greater launch flexibility (e.g. launch your token without requiring USDC)
* Concentrated liquidity; at pool creation, developers can configure a preferred min-max price range for the pool to enable higher capital efficiency for the deposited liquidity.
Read an overview of DAMM v2 [here](https://meteoraag.medium.com/dynamic-amm-v2-helping-lps-and-launches-win-c56128c883ad). Any user can create a new DAMM v2 pool [here](https://app.meteora.ag/create).
# How to create a Liquidity Pool
Source: https://docs.meteora.ag/user-guides/creating-a-liquidity-pool
Learn how to create DLMM and DAMM v2 Standard or Launch pools on Meteora, including token selection, pool configuration, review, launch settings, and duplicate pool checks.
## DLMM
### Creating a DLMM Standard Pool
Anyone can create a DLMM Standard pool here: [https://meteora.ag/create/dlmm/standard](https://meteora.ag/create/dlmm/standard)
Select the trading pair for the DLMM Standard Pool.
* **Base Token**: The token whose price is being quoted. You can search by token ticker or paste the token contract address.
* **Quote Token**: The token used to price the Base token. SOL or stables such as USDC and USDT are usually used as the Quote token.
* Use the swap button if you need to switch the Base and Quote token order.
If you change or swap tokens after configuring the pool, the pool configuration and initial liquidity inputs will reset so you can review the new pair from the beginning.
Set the pool parameters and decide whether to add initial liquidity during pool creation.
* **Initial Price**: The pool's starting price, shown as Quote token per Base token. This sets the active bin at creation and is used to place your initial liquidity range. If a Jupiter market price is available, you can use it as a reference, but you should still verify the price before continuing.
* **Base Fee**: The swap fee tier for the pool. This is the minimum fee charged on swaps through the pool.
* **Bin Step**: The price spacing between DLMM bins. You must select the Base Fee first because available Bin Step options depend on the selected Base Fee.
After the pool is created, the Base Fee and Bin Step cannot be changed.
You can optionally add initial liquidity when creating the pool. If you do not add initial liquidity, Meteora shows the pool creation cost for initializing the pool only.
If you add initial liquidity:
* Choose a liquidity distribution strategy: **Spot**, **Curve**, or **Bid Ask**.
* Enter the Base token amount and/or Quote token amount. When available, **Auto-Fill** can calculate the other side based on your selected range and strategy.
* Adjust the liquidity range with the min and max price controls, percentage offsets, plus/minus buttons, or the bin distribution slider.
* Use the bin distribution chart to preview how your liquidity will be placed across price bins.
* Review the total number of bins and pool creation cost breakdown before continuing.
When creating a DLMM pool and setting the initial pool price, the eventual pool price may deviate slightly from your input. This is because if the bin price cannot be represented exactly by the program, the frontend will round up or down to the closest price. The deviation depends on the Bin Step you selected.
Review your DLMM Standard Pool settings before launching the pool.
The review step shows:
* Pair
* Pool Fee
* Bin Step
* Initial Price
* Whether initial liquidity will be added
* Base and Quote token amounts, if initial liquidity is added
* Min Price, Max Price, and Total Bins, if initial liquidity is added
* Pool creation cost, including rent and transaction fees, excluding seeded liquidity
If you added initial liquidity, you will also see the final bin distribution preview before creating the pool.
To prevent duplicate DLMM pools, for each token pair, there can only be one pool with a specific Bin Step and Base Fee % parameter combination on Meteora. If that pool already exists, you won’t be able to create a new pool with the same parameters. You should deposit liquidity into the existing pool instead.
### Creating a DLMM Launch Pool
Anyone can create a DLMM Launch pool here: [https://meteora.ag/create/dlmm/launch](https://meteora.ag/create/dlmm/launch)
Select the trading pair for the DLMM Launch Pool.
* **Base Token**: The token you are launching or seeding into the pool.
* **Quote Token**: The token used to price the Base token. SOL or stables such as USDC and USDT are usually used as the Quote token.
* Use the swap button if you need to switch the Base and Quote token order.
If you change or swap tokens after configuring the pool, the Initial Price, Curve Max Price, and Seed Amount will reset so you can review the new pair from the beginning.
Set the launch parameters, seed liquidity model, and trading start time.
* **Initial Price**: The pool's starting price, shown as Quote token per Base token. This sets the active bin at creation and anchors your seed liquidity range.
* **Bin Step**: The price spacing between DLMM bins. Smaller steps give finer price granularity.
* **Base Fee**: The swap fee charged on each trade. The allowed fee range depends on the selected Bin Step.
* **Seed Liquidity Mode**: Choose **Curve** to spread seeded liquidity across multiple bins, or **Single Bin** to concentrate liquidity at the Initial Price.
* **Seed Amount**: Enter the amount of Base token to seed as initial liquidity.
* **Lock Release Duration**: Choose how long the seeded liquidity stays locked before it can be withdrawn. You can use presets such as None, 1W, 1M, 3M, 6M, or 1Y, or enter a custom duration in seconds.
* **Curve Max Price** and **Liquidity Curvature**: For Curve mode, set the upper price bound and shape of the seed liquidity distribution. Higher curvature concentrates more liquidity near the Initial Price.
* **Position Owner**: The connected wallet owns the seeded liquidity position.
* **Fee Owner**: The wallet that receives swap fees from the seeded position. You can enter a custom address.
* **Trading Start Time**: Pick a future date and time when trading becomes active.
* **Supply Details**: Review Total Supply, Initial FDV, Final FDV, Max Quote Secured, and Percentage of Supply in Pool.
If you plan to have a token airdrop, make sure tokens are distributed only after the Trading Start Time. Any user who receives the token before trading starts can create their own pool and markets, which may affect your launch price range.
Meteora shows a curve or single-bin preview and a pool creation cost breakdown before you continue.
Review your DLMM Launch Pool settings before launching the pool.
The review step shows:
* Pair
* Bin Step
* Fee
* Dynamic Fee
* Initial Price
* Start Time
* Seed Mode
* Seed Amount
* Lock Duration
* Curve Max Price and Curve Curvature, if using Curve mode
* Single Bin Price and rounding, if using Single Bin mode
* Total Supply
* Percentage of Supply in Pool
* Initial FDV and Final FDV
* Max Quote Secured
* Position Owner and Fee Owner
* Pool creation cost, including rent and transaction fees, excluding seeded liquidity
You will also see the final curve or single-bin preview before creating the pool.
To prevent duplicate DLMM launch pools, Meteora checks whether a pool already exists for the selected token pair and pool settings. If that pool already exists, you should deposit liquidity into the existing pool instead.
## DAMM v2
### Creating a DAMM v2 Standard Pool
Anyone can create a DAMM v2 Standard pool here: [https://meteora.ag/create/dammv2/standard](https://meteora.ag/create/dammv2/standard)
Select the trading pair for the DAMM v2 Standard Pool.
* **Base Token**: The token whose price is being quoted. You can search by token ticker or paste the token contract address.
* **Quote Token**: The token used to price the Base token. SOL or stables such as USDC and USDT are usually used as the Quote token.
* Use the swap button if you need to switch the Base and Quote token order.
If you change or swap tokens after configuring the pool, the initial price, fee tier, and token amount inputs will reset so you can review the new pair from the beginning.
Some Token 2022 tokens or extensions may be unsupported for DAMM v2 pool creation. If a selected token is not eligible, Meteora will show a warning before you continue.
Set the pool parameters, deposit amounts, fee behavior, start time, and liquidity lock preference.
* **Initial Price**: The pool's starting price, shown as Quote token per Base token. If a Jupiter market price is available, you can use it as a reference, but you should still verify the price before continuing.
* **Base Token Amount** and **Quote Token Amount**: Enter the liquidity amounts to deposit. When you edit one side, Meteora can calculate the other side from the Initial Price.
* **Fee Collection Mode**: Choose whether fees are collected in **Base + Quote**, **Quote**, or **Quote + Compounding**. If you choose Quote + Compounding, select the percentage of trading fees to automatically reinvest into pool liquidity.
* **Price Range Chart**: After you enter a valid initial price and both token amounts, use the chart to preview the pool's price range.
* **Base Fee Mode**: Choose **Fixed**, **Time Scheduler**, or **Market Cap Scheduler**.
* **Scheduler Type**: For scheduled fee modes, choose **Linear** or **Exponential**.
* **Initial Fee**: For Time Scheduler, choose the starting fee used by the schedule.
* **Fee Tier**: Select a fee tier compatible with your fee mode, scheduler, fee collection mode, and Dynamic Fee setting.
* **Dynamic Fee**: Enable or disable the volatility-based fee component.
* **Start Time**: Choose **Now** to start trading immediately after creation, or **Custom** to schedule a future start time.
* **Permanently lock my liquidity**: Select this only if you want the deposited liquidity to be permanently locked.
If you select “Permanently lock my liquidity”, all tokens you deposit will be permanently locked and you will no longer be able to access or withdraw the underlying assets.
Review your DAMM v2 Standard Pool settings before launching the pool.
The review step shows:
* Pool pair
* Base amount
* Quote amount
* Initial price
* Base Fee Mode
* Initial fee, when applicable
* Fee tier
* Dynamic Fee
* Collect Fee Mode
* Start time
* Lock liquidity setting
* Pool creation cost, including rent and transaction fees, excluding deposited liquidity
You may also see the final price range chart and fee chart so you can verify how the pool and fee configuration will behave before creation.
To prevent duplicate DAMM v2 pools, Meteora checks whether a pool already exists for the selected token pair and fee configuration. If that pool already exists, you won’t be able to create a new pool with the same settings. You should deposit liquidity into the existing pool instead.
### Creating a DAMM v2 Launch Pool
Anyone can create a DAMM v2 Launch pool here: [https://meteora.ag/create/dammv2/launch](https://meteora.ag/create/dammv2/launch)
Select the trading pair for the DAMM v2 Launch Pool.
* **Base Token**: The token you are launching or depositing into the pool.
* **Quote Token**: The token used to price the Base token. SOL or stables such as USDC and USDT are usually used as the Quote token.
* Use the swap button if you need to switch the Base and Quote token order.
Some Token 2022 tokens or extensions may be unsupported for DAMM v2 pool creation. If a selected token is not eligible, Meteora will show a warning before you continue.
Meteora also checks whether a DAMM v2 pool with the selected settings already exists. If it does, you should deposit liquidity into the existing pool instead.
Set the pool setup, fee configuration, trading start time, and liquidity lock preference.
* **Initial Price**: The pool's starting price, shown as Quote token per Base token.
* **Liquidity Distribution**: Choose **Dual-sided** to deposit both Base and Quote tokens, or **Single-sided** to deposit only the Base token.
* **Base Token Amount** and **Quote Token Amount**: Enter the liquidity amounts to deposit. Single-sided pools do not require a Quote token deposit.
* **Fee Collection Mode**: Choose **Base + Quote**, **Quote**, or **Quote + Compounding**. Single-sided liquidity is not compatible with Quote + Compounding.
* **Compounding Fee %**: If Quote + Compounding is selected, set the percentage of trading fees automatically reinvested into pool liquidity.
* **Min Price** and **Max Price**: Configure the price range. For single-sided pools, the lower bound is fixed to the Initial Price and you only set the Max Price.
* **Base Fee Mode**: Choose **Fixed**, **Time Scheduler**, **Rate Limiter**, or **Market Cap Scheduler**.
* **Scheduler Type**: For Time Scheduler or Market Cap Scheduler, choose **Linear** or **Exponential**.
* **Fixed Base Fee**: For Fixed mode, set the constant swap fee charged on every trade.
* **Time Scheduler**: Set the Starting Fee, Ending Fee, Total Duration, and Number of Periods.
* **Rate Limiter**: Set the Base Fee, Fee Increment, Reference Amount, and Max Duration. Rate Limiter requires Quote-only fee collection.
* **Market Cap Scheduler**: Set the Starting Fee, Ending Fee, Price Multiple, Number of Periods, and Expiration Duration.
* **Dynamic Fee**: Enable or disable the volatility-based fee component.
* **Trading Start Time**: Choose **Now** to start trading immediately after creation, or **Custom** to schedule a future start time.
* **Permanently lock my liquidity**: Select this only if you want the deposited liquidity to be permanently locked.
If you select “Permanently lock my liquidity”, all tokens you deposit will be permanently locked and you will no longer be able to access or withdraw the underlying assets.
If you plan to have a token airdrop, make sure tokens are distributed only after the Trading Start Time. Any user who receives the token before trading starts can create their own pool and markets, which may affect your launch price range.
Meteora shows price range and fee previews, plus a pool creation cost breakdown, before you continue.
Review your DAMM v2 Launch Pool settings before launching the pool.
The review step shows:
* Pair
* Liquidity Distribution
* Base amount
* Quote amount, if dual-sided
* Initial price
* Total supply
* Initial FDV
* Max price, or Min / Max price for dual-sided pools
* Base Fee Mode
* Base fee, when using Fixed mode
* Dynamic Fee
* Collect Fee Mode
* Trading Start time
* Lock liquidity setting
* Pool creation cost, including rent and transaction fees, excluding deposited liquidity
You may also see the final price range chart and fee chart so you can verify how the pool and fee configuration will behave before creation.
To prevent duplicate DAMM v2 launch pools, Meteora checks whether a pool already exists for the selected token pair and fee configuration. If that pool already exists, you should deposit liquidity into the existing pool instead.
# Getting Started
Source: https://docs.meteora.ag/user-guides/getting-started-with-meteora
Learn the basics of using Meteora, including wallet connection, SOL requirements, transaction settings, RPC options, pool search, and pool filters.
## Connecting your wallet
### Supported Wallets on Meteora
A Solana-compatible wallet is a must-have digital tool for you to receive, send, store, and manage your cryptocurrencies or non-fungible tokens (NFTs) on the Solana blockchain. Just like using any other decentralized application (Dapp) on Solana, you will need to first connect your wallet on Meteora in order to add liquidity to a pool or execute other transactions.
Meteora supports wallets that abide by the Solana [Wallet Standard](https://github.com/wallet-standard/wallet-standard) - a chain-agnostic set of interfaces and conventions that aim to improve how applications interact with injected wallets.
Popular wallets supported on Meteora include:
#### Hot Wallets
* Jupiter Wallet
* Phantom
* Solflare
* Backpack
* Coinbase
* OKX Wallet
* Coin98
* Frontier
* MetaMask (via Snaps with Solflare)
WalletConnect
#### Hardware Wallets
* Ledger
* Trezor
## Prepare SOL for transactions and rent
### Transactions
#### What is SOL?
SOL is the Solana blockchain’s native cryptocurrency which is required for transaction fees and other use cases such as securing the network via staking.
#### What is Wrapped SOL (wSOL)?
Wrapped SOL (wSOL) is native SOL that is wrapped using the Solana Token Program, which allows it to be treated like any other SPL (Solana Program Library) token type.
Currently, Dapps have to wrap and unwrap SOL when trading in SOL or using SOL in DeFi due to the fact that native SOL itself is not an SPL token (e.g. JUP).
If there is unused wSOL from adding liquidity or if you're withdrawing wSOL from a pool, you can unwrap it to get it back to native SOL.
#### How do you unwrap wSOL?
If you use the Phantom wallet, you can follow the instructions [here](https://help.phantom.app/hc/en-us/articles/4406389768339-How-do-I-unwrap-Wrapped-SOL-).
#### Transaction Fees on Solana
Transaction fees on the Solana blockchain use SOL, which means as a user you must have SOL in your wallet whenever you want to initiate any type of on-chain action.
When you add or remove liquidity on Meteora, whether this involves the DLMM, DAMM v1, DAMM v2, Dynamic Vaults, or Multi-token pools, you'd need SOL for transaction fees.
0.000000001 SOL = 1 lamport (one-billionth of a SOL)
### Rent
One of the reasons why the Solana blockchain is able to efficiently store data is its novel “rent” mechanism. Solana creates different accounts to record the data related to the transfer and ownership of tokens between different user wallet addresses, as well as other programmatic transactions on the blockchain. Since transaction history or other data stored on the Solana blockchain use resources, a rent fee is imposed.
SOL is the crypto used as a rent fee to create or maintain each unique account on Solana, with the amount of SOL rent dependent on the necessary data resource used for the account.
For example, when you receive a new token in your wallet for the first time, a token associated account (ATA) owned by your wallet gets automatically created and a SOL rent is charged in the process.
In some scenarios, SOL used for rent is **refundable**. If an account is closed, the associated data resource being used on Solana gets freed up and the rent is refunded back to your address (account owner).
### SOL Required on Meteora
#### DAMM v1 or DAMM v2
When you create a DAMM v1 or v2 pool, you may need to pay some rent to open [ATAs (Associated Token Accounts)](https://spl.solana.com/associated-token-account) on Solana. This is roughly \~0.02-0.03+ SOL (may change over time).
#### DLMM
When you create a DLMM position, you also need to pay some rent.
Rent of \~0.059 SOL per position is required to open the program account and store data related to your liquidity position. This is refundable; you get it back when you withdraw your liquidity and close the position.
Additional rent is also required if your position range covers more than 69 bins. This is refundable.
If you happen to be the first to create the specific price bins in the pool, meaning no LPs have used those price bins before, you will also need to pay the rent to create the binArray program account that stores the bins and this rent is unfortunately non-refundable (\~0.075 SOL per binArray). But once they are created no one else has to pay that rent again. Meteora can't close that program account because other LPs may have liquidity in those bins.
When you close your own position, you still get back the standard rent for your position (\~0.059 SOL per position).
Before you add liquidity, you can view the total amount of SOL required to open your positions. SOL required for the position rent has the "Refundable" label, while the SOL required for creating new bin arrays has the "Non-Refundable" label.
![cost-details-png]()
## Transaction Fee Settings
For any on-chain transaction submitted on Solana (e.g. sending tokens, adding liquidity, buying an NFT, or interacting with a program), a transaction fee is required. This is required to:
* Incentivizes validators to process and prioritize your transaction.
* Prevents spam on the Solana network by making it expensive to flood it with useless transactions.
* Helps determine priority — when the Solana network is busy, users who pay more can get transactions processed and executed faster.
Even though Solana is known for low fees, during high traffic (like memecoin launches), paying more can expedite things significantly.
![transaction-settings-png]()
Meteora allows you to be in control, whether you want to save more SOL or prioritize speed by paying more.
### Transaction Broadcast Modes
This determines how your transaction is executed.
Your transaction is broadcast directly on-chain on Solana with an extra priority fee.
Validators are financially incentivized to pick it up faster.
Ideal if you want faster execution without going through additional channels.
Your transactions (whether a single transaction or multiple transactions) get included in a Jito “bundle”, which is sent directly to validators via the Jito relayer, and you pay a Jito “tip”.
Offers better transaction ordering protection.
Only works with validators that support Jito, so if these validators or Jito itself is experiencing a down time, transactions may not go through.
The best of both worlds: Your transaction is sent via both standard Solana and Jito relayer. Meteora intelligently minimizes and decides the best fee for you.
This increases success chances and balances speed, efficiency, and protection.
When you select your fee settings, they will apply throughout Meteora, except for DLMM pools (which currently always uses Jito only).
### Priority level
You can select how fast you prefer your transaction to go through. This affects how much priority fee gets added to your transaction.
| Level |
Description |
When to use |
| Fast |
Normal speed, lowest priority fee |
Everyday transfers and adding/withdrawing liquidity; no urgency. |
| Turbo |
Faster than normal, moderate priority fee |
Moderate urgency, like sniping tokens or adding/withdrawing liquidity quickly, while you’re on the go. |
| Ultra |
Highest speed on Meteora, highest priority fee |
Highest urgency, and for a more seamless LP experience during Solana network congestion; useful if the cost involved is manageable. |
### Fee Mode
This lets you select how you want to define your fee (SOL).
Specify a maximum amount of SOL you're willing to pay to execute your transaction.
Meteora will dynamically set the best fee within your cap based on current network conditions.
Great for users who want flexibility without overspending.
Define the exact amount of SOL to use as a transaction fee, nothing more, nothing less.
Gives full control over cost, but if you underpay, your transaction might fail altogether.
Best for advanced users who are very certain the amount of SOL is required for their transactions.
## Viewing Transactions
You can view your transaction history on the Solana blockchain by using one of the available Solana blockchain explorers. Transactions sometimes do not show up on your Solana wallet's transaction history, so it is better to verify by using the explorer.
Popular explorers include:
* [Solscan](https://solscan.io/)
* [Solana Beach](https://solanabeach.io/)
* [Solana Explorer](https://explorer.solana.com/)
* [XRAY](https://xray.helius.xyz/)
* [OKLink](https://www.oklink.com/)
For SOL transfers to your wallet account, sometimes these are reflected in the "SOL Balance Change” tab in the associated tx link.
For SPL token transfers to your wallet account, sometimes these are reflected in the “Token Balance Change” tab in the associated tx link.
## RPC Settings
RPC (Remote Procedure Call) is a communication protocol used in blockchain applications that allows your Dapp (decentralized app) to interact with the Solana blockchain — like sending transactions, fetching account data, or querying block info — without needing to run a full Solana node on your own.
When you click the Settings icon, users can choose their preferred RPC from multiple options to ensure
* **Reliability**: If one RPC provider goes down or is slow, users can switch to another.
* **Performance**: Different RPCs may respond faster depending on region, usage, or load.
* **Customization**: Advanced users or institutions might want to use their own (custom) RPC for privacy, rate limits, or analytics.
#### Custom RPC
* Users can input their own RPC endpoint.
* Ideal for developers or anyone with access to a private or paid Solana node, as this offers full control over data and performance needs.
Sometimes, if the site data happens to be lagging or stale, you can try to switch your RPC.
## Searching for Pools
### Universal Search Bar
On the [https://meteora.ag](https://meteora.ag) home page, you can use the "Universal Search Bar" to quickly look for your preferred pool, based on the token ticker or pool address.
### Pool Search Bar
If you are already on the [https://meteora.ag/pools](https://meteora.ag/pools) tab, you can also search for your preferred pool, based on token ticker, token name, token contract address, or pool address.
### Pool Filters
On the Pool List page, you can use our Pool Filter feature to identify good LP opportunities based on your preferred parameters.
Click the “Save” button to save your filters and allow Meteora to remember them on your next visit. You can click the reset icon button anytime to remove all filters and revert back to the default pool list view.
The Pool Filter parameters are split into 3 main categories:
* Token details
* Pool details
* Launchpad details
#### Token details
Under Token details, you can filter to show pools where:
* Both tokens are verified
* The Base token has no mint authority
* The Base token has no freeze authority
* The Base token is a New Listing according
* The Base token has no high supply concentration
* The Base token has no high single ownership
* The Base token’s market cap is within a specific min-max range
#### Pool details
Under Pool details, you can input parameters to filter and show pools which:
* Were created within a specified number of hours
* Had a minimum amount of trading volume within a specified period
* Had a minimum amount of fees within a specified period
* Had a minimum Fee / TVL % within a specified period
* Were within a specified TVL min-max range
* Had a Base Fee which was within a specified min-max range
* Had a Bin Step which was within a specified min-max range
#### Launchpad details
Under Launchpad filter details, you can filter pools based on the launchpads you select from the launchpad filter list.
When you select certain launchpad(s), Meteora will only show you pools that contain a Base token that graduated from those selected launchpads.
For instance, if you had only selected Jupiter Studio, you will only see a list of pools that contain a Base token that graduated from Jupiter Studio (e.g. pools with tokens like URANUS, VIBE). You will not see pools that contain a Base token that graduated from Pump.fun or Letsbonk.fun.
## Need more help?
Follow Meteora or our LP Army on our socials to get help from our community and team.
# DAMM v2 Pool Detail
Source: https://docs.meteora.ag/user-guides/how-to-use-damm-v2/damm-v2-pool-detail
Learn how to use DAMM v2 on Meteora, including navigating pool pages, understanding pool metrics and fees, adding or withdrawing liquidity, locking liquidity, and managing position NFTs.
## Navigating DAMM v2 pools
DAMM v2, or Dynamic Automated Market Maker v2, builds upon the original DAMM, to provide a powerful, yet hassle-free way to add liquidity and earn fees on Solana.
[DAMM v2](https://meteoraag.medium.com/dynamic-amm-v2-helping-lps-and-launches-win-c56128c883ad) allows you to deposit tokens into a pool, which are then used as liquidity for traders, bots, and aggregators to swap tokens, earning you fees with every trade. But it is much more configurable than your typical AMM, with features tailored for a wide variety of liquidity providers, token launches, and launchpads.
**Features for LPs include:**
Supports a wide range of SPL tokens and select Token 2022 extensions, letting you provide liquidity for more token types.
Dynamic fees boost the fees you earn during periods of high market volatility, helping LPs maximize returns when trading activity increases.
Advanced anti-sniper tools, such as Time Scheduler, Market Cap Scheduler, and Rate Limiter, can adjust fees around launch conditions to make opportunistic trading more expensive.
**LPs also have:**
Choose to receive your liquidity provider fees directly in a quote token like USDC or SOL, instead of receiving fees in both tokens from the pool pair.
Lock your memecoin liquidity with a customizable vesting period or even permanently lock it, while still being able to claim your earned fees.
Effortlessly transfer your liquidity position to another person by simply sending the NFT that represents your LP position.
**Token creators can even:**
Launch a new pool using just your token, without needing USDC or other stablecoins.
Set a specific future time when pool trading should be enabled, allowing for launches, announcements, or fair trading starts.
Open a pool with a fixed price range to provide higher capital efficiency, similar to Uniswap v3-style concentrated liquidity.
On the Pool List page, once you’ve selected the token pair and DAMM v2 pool you’d like to add liquidity into, click on it and you would enter the specific pool’s detail page.
To illustrate the various features of DAMM v2, we will be referring to a few pools in this guide, for example [SOL-USDC](https://app.meteora.ag/dammv2/8Pm2kZpnxD3hoMmt4bjStX2Pw2Z9abpbHzZxMPqxPmie), [URANUS-USDC](https://app.meteora.ag/dammv2/7ccKzmrXBpFHwyZGPqPuKL6bEyWAETSnHwnWe3jEneVc), [WLFI-USD1](https://app.meteora.ag/dammv2/F6L1RKAKwNuWwyCwweja6uxAkRv41XFTRWmg8tKGkn83), and [ICM-SOL](https://app.meteora.ag/dammv2/FLuXAxxqMbLkKHWHHCAiX2ub8qZuoC9bb35bSRDNDMo2).
### Total Value Locked
At the top left of the pool detail page, you can view the pool’s TVL (Total Value Locked). This is the total amount of token assets in the pool in terms of \$USD value (how much all the tokens currently in the pool are worth). DAMM v2 allows both permanent and non-permanent locking of liquidity, and the TVL section would show the following:
* Vested Liquidity: % of liquidity non-permanently locked for at least 3 months (at this point in time)
* Permanently Locked Liquidity: % of liquidity permanently locked in the pool
Here's a screenshot of this example pool: [URANUS-USDC](https://app.meteora.ag/dammv2/7ccKzmrXBpFHwyZGPqPuKL6bEyWAETSnHwnWe3jEneVc)
### Price Range
For most DAMM v2 pools created via the Meteora user interface (website), the price range supported is 0 to infinity.
But for certain DAMM v2 pools created programmatically using our documentation, they could be configured to have a more concentrated price range with a specific min price and max price for higher capital efficiency. Once a pool is created, the price range for that specific pool is fixed and can never be adjusted again.
Compounding fee pools use DAMM v2's compounding liquidity mode and do not use a custom min-max price range.
Here’s a screenshot of the example pool: [SOL-USDC](https://app.meteora.ag/dammv2/8Pm2kZpnxD3hoMmt4bjStX2Pw2Z9abpbHzZxMPqxPmie), where the price range is concentrated at 70 - 440 USDC/SOL.
### Liquidity Allocation
The TVL is further broken down into the amount of each token in the pool. In this screenshot of the example pool [ICM-SOL](https://app.meteora.ag/dammv2/FLuXAxxqMbLkKHWHHCAiX2ub8qZuoC9bb35bSRDNDMo2), \$820,815.85 in TVL is actually made up of 24,451,511 ICM and 2,064.47 SOL.
DAMM v2 supports common Token 2022 extensions permissionlessly, including transfer fees and metadata. Tokens with other extensions need a Meteora token badge before pool creation. See [DAMM v2 Token 2022 Support](/core-products/damm-v2/token-2022-support) for the full rules.
In the Liquidity Allocation section, you can view a snippet of the token’s contract address. Click the icon next to it to access important quicklinks; to copy the token’s contract address, view the contract address on Solscan, check for token risks on Rugcheck.xyz, or analyze the token behaviour on Bubblemaps.
You can also view the Jupiter Organic Score for the token and if the token has any risks.
### Pool Details
#### Current Pool Price
The Current Pool Price may not always be close to the general market price, especially when it was just created with a wrong initial price and has low liquidity. Check that the pool price is in sync with the market price prior to adding liquidity, to avoid incurring a loss due to arbitrage trades.
#### 24h Volume
Volume generated by the pool in 24h
#### 24h Fee
Total fees collected by the pool in 24h
#### Base Fee
Minimum fee charged when swaps occur through the pool, before any Dynamic Fee component is added and before fees are split by the program.
#### Dynamic Fee
Additional fee charged on each trade based on real-time price volatility.
#### Total Trading Fee
```math theme={"system"}
Base Fee + Dynamic Fee
```
The total trading fee is split by the program into protocol fee, referral fee when applicable, claimable LP fee, and, for compounding pools, compounding fee.
#### Protocol Fee
Amount of fees charged on each trade which goes to the protocol or integrations. DAMM v2 currently sets the protocol fee to 20% of the total trading fee amount.
#### Fee Collection Mode
* Pool creators can choose how LP fees are collected: **Base + Quote**, **Quote**, or **Quote + Compounding**.
* In **Base + Quote** mode, fees are collected from the output token of each swap.
* In **Quote** mode, fees are always collected in Token B, which is commonly the quote token. For example, in a URANUS-SOL pool, pool creators can set it so LP fees are collected only in SOL.
* In **Quote + Compounding** mode, fees are collected in Token B. A configured portion is compounded back into pool liquidity, while the remaining portion is claimable.
* Once the pool is created, the selected Fee Collection Mode cannot be changed.
* As an LP, you can choose the specific DAMM v2 pool that has the Fee Collection Mode that fits your requirements.
#### Base Fee Mode
* DAMM v2 supports multiple Base Fee modes: Fixed, Time Scheduler, Market Cap Scheduler, and Rate Limiter.
* **Fixed** mode keeps the base fee constant.
* **Time Scheduler** starts from a configurable fee and reduces it over a configured number of periods after the pool activation point. The schedule can be Linear or Exponential.
* **Market Cap Scheduler** reduces fees as the pool price moves upward from the initial price toward configured price steps. The schedule can be Linear or Exponential, and can also expire after a configured duration.
* **Rate Limiter** increases fees based on trade size during a configured launch window. It applies to quote-token fee collection and is designed to make larger quote-to-base buys more expensive during the protected period.
* As an LP, you can choose the specific DAMM v2 pool that has the Base Fee mode and parameters that fit your requirements.
**Exponential Fee Time Scheduler**
In this [ICM-SOL](https://app.meteora.ag/dammv2/FLuXAxxqMbLkKHWHHCAiX2ub8qZuoC9bb35bSRDNDMo2) pool example, Exponential mode is used. Fees started at 50% before dropping exponentially over time until it reached 1% after 60 seconds.
**Linear Fee Time Scheduler**
In this [WLFI-USD1](https://app.meteora.ag/dammv2/F6L1RKAKwNuWwyCwweja6uxAkRv41XFTRWmg8tKGkn83) pool example, Linear mode is used, and fees started at 10% before dropping linearly over time until it reached 0.25% after 3 minutes.
**Rate Limiter**
In this [ASTEROID-SOL](https://app.meteora.ag/dammv2/5xLdp92fwbcrqXKG24G9SM4C4ha5h1wouxm8RCPyhXxW) pool example, Rate Limiter mode is used, and fees started at 1% before increasing exponentially based on trade size until it reached 99% after 12 hours.
**Exponential Fee MarketCap Scheduler**
In this [MET-SOL](https://app.meteora.ag/dammv2/9XjqpG4FidkXrePLoXAAVi8916YV1hjd12MiysDhGQ8K) pool example, Exponential mode is used. Fees started at 1% before dropping exponentially as the marketcap grows until it reached 0.3%.
**Linear Fee MarketCap Scheduler**
In this [ASTEROID-USD1](https://app.meteora.ag/dammv2/6p3oRMqHtAnjsKBUsmu9Smcy5bZP3UYJcF9eB8tZYub) pool example, Linear mode is used, and fees started at 1% before dropping linearly as the marketcap grows until it reached 0.3%.
#### Pool Address
On each DAMM v2 pool detail page, you can also easily open up the pool address page on Solscan if required.
#### Community Built-in Tools
Meteora’s LP Army comprises many talented developers, who have over time built useful tools to improve LPing for everyone. The full list of tools can be found [here](https://www.lparmy.com/community-tools).
#### Pool Chart
Popular data analytics and charting tools with more granular data have integrated Meteora’s liquidity pools, including Birdeye, GeckoTerminal, DEXScreener, DEXTools, GMGN. We’ve provided buttons that link to the specific pool page for each of these tools.
#### Supported Trading Platforms
Popular trading platforms and bots have also integrated Meteora’s liquidity pools, including Axiom, Banana Gun, BONKbot, Fluxbot, Jupiter, MetaSolanaBot, Photon, and Trojan. We’ve provided buttons that link specifically to each of the trading platforms. Note: For pools without SOL as the quote token, BONKbot, Photon, and Axiom won’t be in the list.
#### Total Positions
When you create a new DAMM v2 pool or add liquidity to a pool, your liquidity is tracked in a position account represented by a unique liquidity position NFT in your wallet. Adding more liquidity to the same position increases that position's unlocked liquidity.
But DAMM v2 can support multiple individual liquidity positions, so if your friend has a separate position in the same pool, and sends his liquidity position NFT to your wallet address, you would then see that you now have 2 liquidity positions (your original position and the new position sent to you). The number of positions you see on the UI would correspond to the number of unique position NFTs you hold in your wallet.
On the UI, you can only select and view the details for one liquidity position at a time.
#### Total Deposits
This represents the total \$ value of all your deposits in all your liquidity positions.
#### Position Value
This represents the \$ value of your deposits in the specific liquidity position selected.
#### Fees from position
This represents the \$ value of the accumulated claimable fees for the specific liquidity position selected. In Base + Quote and Quote fee modes, LP fees accumulate separately and have to be manually claimed by the LP. In Quote + Compounding mode, only the non-compounded portion is claimable because the configured compounding portion is added back into pool liquidity.
## How to Add Liquidity
Firstly, navigate to the “Deposit” tab.
### Enter Deposit Amount
Under the “Deposit” tab, under “Enter deposit amount”, you can enter the amount of Base token or Quote token you’d like to deposit into the pool. The corresponding \$USD value will be shown at the bottom of your input.
When you enter an amount for either the Base or Quote Token, Meteora automatically fills in the approximate amount of the other token based on the current liquidity allocation ratio.
For example, if the SOL in the pool comprises 44.93% of liquidity, while USDC comprises 55.07%:
When you enter 2 USDC, the SOL input field will automatically state approximately \~0.109525293 SOL, which is equivalent to (2 / 55.07) x 44.93 = \~\$1.63). The amount used may differ slightly from the expected token ratio because the token ratio within the active price bin is constantly changing as swaps occur.
We’ve also provided a “Max” and a custom “%” button near the Base and Quote token fields. Clicking “Max” automatically enters your entire balance of the respective token, while clicking the custom % button automatically enters an amount based on the % indicated (e.g. 99%)
After the Base token and Quote token input fields are filled, under “Deposit info”, you can check your deposit details before you confirm your transaction:
* The estimated amount you will get
* The Minimum Received
* The Maximum Slippage %, which you can preset
Once you have verified that the details are acceptable, click the “Deposit” button.
### Setting Liquidity Slippage
You can adjust how much change to the pool price you're willing to accept and still add liquidity. If the pool price changes a lot while adding liquidity, your transaction may fail. Increase this slippage to improve your success rate.
## How to Withdraw Liquidity
On the pool detail page, navigate to the “Withdraw” tab.
Enter the amount of unlocked liquidity you want to withdraw from the selected position.
In the “Withdraw Info” section, you will see a summary of how many Base tokens and Quote tokens you’d be getting:
* The estimated amount you will get
* The Minimum Received
* The Maximum Slippage %, which you can preset
Once you have verified that the details are acceptable, click the orange “Withdraw” button.
## How to Lock Liquidity
If you have never added and locked liquidity on Meteora before, “My locks” would show “No locks found".
### Permanent Lock Liquidity
Token teams, especially memecoins, can decide if they wish to permanently lock their liquidity on Meteora. Permanent locking moves liquidity from the position's unlocked liquidity into its permanently locked liquidity state, while fees remain claimable.
To do this, navigate to the “Permanent Lock” tab and enter the amount of unlocked liquidity you’d like to lock permanently.
You’d be able to see the total value you’re locking, as well as the individual token amounts and their equivalent \$ value.
When you’re ready, click the “Lock Liquidity” button. A pop-up would appear requesting confirmation. You would have to type in the text “permanently lock my liquidity never to get it back” as a way to confirm the transaction.
If you had permanently-locked your assets, you would no longer be able to access or withdraw those underlying assets.
### Non-Permanent Lock Liquidity
LPs also have the option to lock their liquidity in a “Non-permanent” manner, also known as a lock with vesting. This means unlocked liquidity is moved into vested liquidity and released back to unlocked liquidity based on the configured vesting schedule.
To begin, select the “Non-permanent” tab and enter the amount of unlocked liquidity to lock.
There are a few parameters that you’d have to decide based on your preferences and requirements, such as:
* Vesting Start Date
* Vesting Duration (Minute)
* Cliff (Optional) (Minute)
* Unlock Schedule (Minutely)
Once these parameters are all filled up, you can proceed to click the “Lock Liquidity” button.
## FAQ
### Using DAMM v2 on the Meteora UI
#### 1. When you deposit tokens into the pool, how is the liquidity amount calculated?
When you deposit token amounts on the Meteora UI, it calculates the liquidity amount for the selected position before sending the transaction to the program.
Example:
* From token B: amount\_b = liquidity\_delta (pool.current\_sqrt\_price - pool.min\_sqrt\_price)
* So you can reverse: liquidity\_delta = amount\_b / (pool.current\_sqrt\_price - pool.min\_sqrt\_price)
#### 2. How is the fee collected when the pool creator selects fee collection mode as Quote only?
Regarding how DAMM v2 collects fee only using the Quote token ("Token B"):
* If a user swaps from A -> B, fee is charged on B; protocol takes some of the user's B
* If a user swaps from B -> A, fee is charged on B before the swap is calculated; protocol takes some of the user's B before it gets swapped to A
### Liquidity Position NFT
#### 1. What does the position state of the NFT manage?
The position state manages unlocked liquidity, permanently locked liquidity, vested liquidity, pending fees, and pending rewards.
User can interact with the following flows in the same, single position:
* Permanently lock part of the liquidity
* Create multiple vesting schedules
* Add more liquidity (unlocked liquidity)
#### 2. Can I transfer a position NFT (which represents a liquidity position)?
Yes. For example, you already have a position in a pool, which is represented by a position NFT. Someone also has a position in that same pool and he sends you his position NFT. Now you would have 2 position NFTs (positions) for the same pool.
### Farming
DAMM v2 has an in-built farming mechanism within the program. This is unlike DAMM v1, where there is a separate farming program.
For DAMM v2, each pool can initialize up to 2 reward tokens. Each initialized reward has its own reward vault, reward duration, reward rate, and funder.
When the `initialize_reward` program endpoint is used, a reward vault for the specific pool and reward index is created, and the initiator can specify the reward token and reward duration.
Rewards are shared with liquidity providers over the farming duration and can be claimed from each eligible position.
# DLMM Dynamic Terminal
Source: https://docs.meteora.ag/user-guides/how-to-use-dlmm/dynamic-terminal
Use Meteora's DLMM Dynamic Terminal to analyze pools, create positions, manage liquidity, claim fees, rebalance, and monitor LP performance.
Meteora's **Dynamic Terminal** is the revamped DLMM pool interface, purpose-built to give liquidity providers everything they need in one place. It combines advanced charting, deep pool and token data, position management, and quick actions into a single, high-performance workspace.
Dynamic Terminal for DLMM is live on [meteora.ag](https://meteora.ag). DAMM v2 support is coming soon.
***
## Layout Overview
The Dynamic Terminal is organized into four main areas:
| Area | What's There |
| ----------------- | ----------------------------------------- |
| **Left panel** | Pool stats, token info, and risk data |
| **Center top** | TradingView price chart |
| **Center bottom** | Your open positions with real-time P\&L |
| **Right panel** | Position creation and management controls |
Each panel is resizable and collapsible — customize the layout to match your workflow.
***
## 1. Pool and Token Insights Panel (Left)
The left panel consolidates everything you need to evaluate a pool before committing capital.
**Pool statistics:**
* Base Fee, Bin Step, Dynamic Fee
* TVL and token ratio
* Liquidity distribution chart
* 24h Volume, Fees, and Fees/TVL
**Token info and risk metrics:**
* Token contract address and [Jupiter Organic Score](https://www.jup.ag)
* Links to Solscan, RugCheck, and Bubblemaps
* Token Age, Market Cap, FDV, Holders
* % of supply held by Top 10 Holders and Top 10 Dev Wallets
* Freeze Authority and Mint Authority status
* Total Supply
* Price change % in 5m / 1h / 12h / 24h
**Pool performance:**
* Historical fee performance
* Links to popular LP community tools
You can resize or fully collapse the left panel with a single click to free up screen space.
#### Pool Stats Explained
* **Bin Step** — the price difference between consecutive bins. Smaller = more continuous price range; larger = higher fee options with wider price jumps. Use smaller steps for stable pairs, larger for volatile ones.
* **Base Fee** — minimum trading fees earned when swaps occur through your position
* **Dynamic Fee** — includes Base Fee, surges in response to real-time price volatility
* **Max Fee** — maximum trading fees earned on swaps
* **Protocol Fee** — portion of the total swap fee that goes to the protocol (10% for standard DLMM pools, 20% for Launch Pools)
* **24h Fee / TVL %** — ratio of fees collected in the past 24h divided by current TVL, expressed as a percentage
***
## 2. Professional-Grade TradingView Price Chart
The Dynamic Terminal features a fully integrated [TradingView](https://www.tradingview.com) price chart — the same charting platform used by professional traders worldwide.
**What's included:**
* **Technical indicators** — apply moving averages, RSI, Bollinger Bands, volume profiles, and more
* **Drawing tools** — mark support and resistance levels, trend lines, and price targets
* **Multiple timeframes** — from 1-minute candles to weekly for macro context
* **Persistent layout** — your chart settings and annotations are saved automatically
* **Collapsible** — hide the chart entirely when you don't need it, bring it back in one click
**Why this matters for LPs:**
Concentrated liquidity strategies depend heavily on price range decisions. Better analysis = better positioning = higher fee capture:
* **Set tighter, more strategic ranges** — anchor your min/max price to key technical levels
* **Time your entries** — enter when price is consolidating near your target range
* **Adjust with confidence** — use chart context to decide whether to rebalance, hold, or exit
* **Reduce impermanent loss** — understand volatility before committing capital to a range
*Charts powered by [TradingView](https://www.tradingview.com).*
***
## 3. Current Pool Price and Sync
You can view the Current Pool Price at the top of the position creation panel. The pool price may not always match the general market price — especially for newly created pools with low liquidity.
Meteora uses Jupiter's price API as a market price reference. Before adding liquidity, compare the pool price with other markets to confirm it's in sync.
### Sync with Jupiter's Price
If the pool price is out of sync, use the **"Sync with Jupiter's price"** button before depositing. This is available for pools where:
* There is 0 liquidity between the active bin and the Jupiter price bin, or
* The liquidity is in a bin close enough to the Jupiter price bin
If there's liquidity in the bins between the active and market price that isn't close enough to sync automatically, you can either wait for arbitrage trades to bring it in sync, or make a few tiny manual swaps through the pool in the appropriate direction.
***
## 4. How to Add Liquidity
### Create Position
Click the **Create Position** button on the right panel to open a concentrated liquidity position.
#### Enter Deposit Amount
Enter the amount of Base Token or Quote Token you'd like to deposit. With **Auto-Fill** enabled (default), entering an amount for either token automatically fills the approximate equivalent for the other based on the current exchange rate.
Use the **Max** button to enter your full balance, or the custom **%** button to enter a set proportion.
#### Set Liquidity Slippage
Adjust how much price movement you're willing to accept while adding liquidity. Increase slippage if transactions are failing due to price movement.
#### Choose a Volatility Strategy
* **Spot** — uniform distribution across the range. Versatile and risk-adjusted, suitable for any market condition. Good default if unsure.
* **Curve** — concentrated around the current active price, less toward the edges. Best for stable pairs or low-volatility tokens.
* **Bid-Ask** — inverse of Curve; more liquidity at the edges of your range. Useful for volatile pairs or as a DCA in/out strategy (single-sided).
#### Set the Price Range
By default, your position spans 69 bins with the active price centered in your range. Adjust three ways:
1. **Drag the slider** — narrow the range (up to 69 bins)
2. **Enter Min/Max price directly** — widen up to 1,400 bins
3. **Set Min % / Max %** — define how far each boundary is from the active bin as a percentage; use the **+/−** per-bin buttons for fine-tuning
**Reading the liquidity chart:**
* **Purple bins** = Base token (e.g. SOL)
* **Cyan blue bins** = Quote token (e.g. USDC)
* **Grey bins** = Existing liquidity already in the pool. Hover over a bin for its price and token breakdown.
**Narrower range** = more capital efficient, higher fee capture potential, but higher risk of going out of range.
**Wider range** = lower fee capture per dollar, but more resilient to price movement.
#### Single-Sided Liquidity
To deposit only one token, toggle off **Auto-Fill** and enter an amount in only one field.
**Example:** You bought SOL at 236.6 USDC and want to gradually sell it at 240–280 USDC. Turn off Auto-Fill, enter only your SOL amount, set a range of 240–280, and use Bid-Ask strategy. Your SOL gets allocated across that range and progressively swaps to USDC as price moves through it.
#### Cost Details
Before confirming, review the SOL rent required:
* **Refundable** — position creation rent and extension rent, returned when you close the position
* **Non-Refundable** — SOL for creating new bin arrays
Click **"Show cost details"** for the full breakdown.
#### Confirm
When everything looks right, click **Add Liquidity** to execute.
***
### Ape In
The **Ape In** button lets you deploy liquidity fast — swap and create a position with a single token in one transaction, based on your preferred settings. Best for moving quickly on an opportunity.
***
## 5. Your Positions (Bottom Panel)
All your open positions are listed at the bottom of the Dynamic Terminal with real-time performance data.
| Metric | Description |
| ------------------- | ---------------------------------------- |
| **Date & Time** | When the position was opened |
| **Your Liquidity** | Current value of deposited tokens |
| **Claimable Fees** | Accumulated fees ready to claim |
| **P\&L** | Profit & Loss in \$ and % |
| **24h Fee / TVL %** | Estimated short-term fee generation rate |
For the account model behind positions, see [DLMM Dynamic Positions](/core-products/dlmm/dynamic-positions).
#### Earning Fees
LPs earn fees whenever swaps occur within their active price range. Fees do not auto-compound — they accumulate and must be claimed manually.
#### Out of Range
If the active price moves outside your range, your position goes inactive and stops earning fees. You can either:
* Wait for price to return to your range
* Rebalance — withdraw and re-center your position around the current price
***
## 6. Quick Actions
Batch controls to manage all positions at once:
* **Claim All Fees** — collect fees from every position in one transaction
* **Close All Positions** — exit all positions simultaneously
Individual controls are also available per position.
![quick-action-gif]()
***
## 7. Position Management Panel (Right)
Select any position to open the dedicated management panel on the right side. Resizable and collapsible.
* **Add Liquidity** — add more capital within the same price range
* **Rebalance** — one click to re-center your range around the current price
* **Remove Liquidity** — withdraw partial or full liquidity
* **Withdraw and Close** — exit the position entirely and reclaim rent
* **Zap Out** — withdraw and convert everything to your preferred token in one step (available for positions with ≤ 250 bins)
You cannot withdraw single-sided from the active bin — you must withdraw both tokens from the active bin.
***
## 8. Customizable Layout
Every LP has a different workflow. The Dynamic Terminal adapts:
* **Left panel** — resize or hide the pool/token insights panel
* **Right panel** — resize or hide the position management panel
* **Chart** — resize or hide the TradingView price chart
***
## Video Walkthrough
Watch Dann's full walkthrough of the DLMM Dynamic Terminal—see live features, key workflows, and expert tips for LPs.
***
## Community Tools and Integrations
**Analytics:** Birdeye, GeckoTerminal, DEXScreener, DEXTools, and GMGN all have dedicated pool pages — links available directly from the pool page.
**Trading platforms:** Axiom, Banana Gun, BONKbot, Fluxbot, Jupiter, MetaSolanaBot, Photon, and Trojan are all integrated. Note: for pools without SOL as the quote token, BONKbot, Photon, and Axiom may not appear.
**Community-built LP tools:** [lparmy.com/community-tools](https://www.lparmy.com/community-tools)
***
## Learn More
* [LP Army Bootcamp](https://lparmy.notion.site/lp-army-bootcamp) — beginner-to-advanced strategies for DLMM LPing
* [LP Army](https://lparmy.com) — join the community
# TradingView Charts
Source: https://docs.meteora.ag/user-guides/how-to-use-dlmm/tradingview-charts
Use TradingView charts inside Meteora's DLMM Dynamic Terminal to choose price ranges, time entries, monitor positions, and manage LP risk.
Meteora's Dynamic Terminal features a fully integrated chart by TradingView — the same charting platform trusted by millions of professional traders worldwide to track [Bitcoin price](https://www.tradingview.com/symbols/BTCUSD/) and broader crypto trends. No need to switch tabs or use a separate tool. Everything you need to analyze price and manage your liquidity position is in one place.
***
## Why TradingView for Liquidity Providers?
Concentrated liquidity is inherently a range game. The quality of your price range decision determines:
* How much trading volume passes through your position
* How often you earn fees vs. sitting out of range
* Your exposure to impermanent loss
Making that range decision without proper charting is guesswork. With TradingView built into the Dynamic Terminal, LPs have direct access to professional-grade analysis tools on the same page where they create and manage positions.
***
## What's Included
### Advanced Charting
A full-featured price chart with access to the same tools professional traders use:
* **100+ technical indicators** — moving averages, RSI, MACD, Bollinger Bands, volume profiles, and more
* **Multiple chart types** — candlestick, bar, line, area, Heikin Ashi, and more
* **Multiple timeframes** — analyze from 1-minute candles all the way to weekly charts
* **Zoom controls** — focus in on a specific breakout or zoom out for the full macro picture
![trading-view-indicators-png]()
### Smart Drawing Tools
Annotate your chart with precision:
* **Trend lines and channels** — identify directional momentum
* **Support and resistance levels** — mark the key price zones that inform your min and max range
* **Fibonacci retracements** — spot potential reversion levels for range placement
* **Text notes and labels** — annotate directly on the chart for context
### Persistent Layout
Your chart setup is automatically saved. Indicators, drawn levels, and timeframe preferences persist across sessions — so your analysis is always there when you come back.
### Collapsible Panel
Hide the chart entirely with a single click when you don't need it, and bring it back instantly. The Dynamic Terminal adapts to your workflow.
***
## How to Access TradingView Charts
The TradingView chart is built directly into the Dynamic Terminal — no setup required.
1. Go to [meteora.ag](https://meteora.ag)
2. Select a DLMM pool from the pool list
3. The Dynamic Terminal opens with the TradingView chart in the center panel
4. Use the toolbar at the top of the chart to switch timeframes, add indicators, or use drawing tools
Resize the chart panel by dragging its edge up or down. Give yourself more chart space when running technical analysis, then shrink it when managing positions.
***
## How LPs Use TradingView to LP Better
### Setting Tighter, More Strategic Ranges
Instead of guessing your min and max price, anchor them to levels that matter on the chart:
* Use support levels as your min price — price is likely to find buyers here
* Use resistance levels as your max price — price may struggle to push past here
* Use Fibonacci retracements to identify likely reversion zones for range-bound strategies
### Timing Your Entries
Entering a position when price is trending strongly against your range means going out of range immediately. Use the chart to:
* Look for consolidation zones near your target range — tighter price action = more time in range
* Check momentum indicators before committing capital to a concentrated range
* Wait for volatility to settle before opening positions in high-activity periods
### Monitoring While Active
While your position is open, use the chart to stay aware of market conditions:
* Watch for breakouts that may push price out of your range
* Use the chart to decide whether to rebalance, hold, or exit
* Apply volume analysis to gauge whether trading activity through your range is likely to continue
### Reducing Impermanent Loss
Impermanent loss increases when price moves significantly outside your range. Better chart analysis helps:
* Avoid entering ranges that are already extended and likely to revert
* Set wider ranges in high-volatility conditions to stay in range longer
* Exit before a clear trend pushes price far outside your position
***
## Available on All Devices
The TradingView chart in the Dynamic Terminal is accessible on desktop and tablet. Whether you're actively managing positions or doing pre-entry analysis, the charting tools are always within reach.
***
## Get Started
The Dynamic Terminal with TradingView charts is live now at [meteora.ag](https://meteora.ag).
* [How to use DLMM Dynamic Terminal](/user-guides/how-to-use-dlmm/dynamic-terminal) — full guide to the Dynamic Terminal interface
* [LP Army Bootcamp](https://lparmy.notion.site/lp-army-bootcamp) — strategies for using chart analysis in your LP workflow
* [Join the LP Army](https://lparmy.com) — connect with the community
***
## Top 5 Indicators for LPs
Read @kappatin's detailed breakdown of the top 5 indicators every LP should watch when providing concentrated liquidity.
***
*Charts powered by [TradingView](https://www.tradingview.com) — the world's leading financial charting platform.*
# Staying Safe
Source: https://docs.meteora.ag/user-guides/staying-safe-on-meteora
Learn how to evaluate token safety on Meteora using token risk warnings, Rugcheck, JupShield, Jupiter Organic Score, and wallet security best practices.
## How to check if a token is safe to LP in?
### Potential Token Risk Warning
Pools with suspicious or riskier tokens would display a “Potential token risk” warning message at the top of the pool detail page.
### Rugcheck
Prior to purchasing the token, you can try pasting the token address on [https://rugcheck.xyz/](https://rugcheck.xyz/) to check if it has any risks.
Sometimes, the token being traded might have a “Freeze Authority” function attached, which means the token minter or creator has the ability to freeze the buying/selling/transfer of the token by users.
Please clarify this with the token project and exercise caution when trading this token. In addition, you should always be wary of scams and phishing attempts.
### JupShield
On the pool list page, as well as each pool detail page, we have integrated JupShield by Jupiter, which combines its own scam-mitigation tech with other third-party services like RugCheck and Blockaid to provide real‑time protection by flagging potentially risky tokens and liquidity pools. Examples include tokens involved in rugpulls, suspicious mint activity, with Freeze Authority enabled, or with low liquidity. Users can easily see the warnings for the token on the page prior to purchasing the token or adding liquidity into the pool.
### Jupiter Organic Score
Meteora has also integrated Jupiter’s Organic Score, a metric used to measure the authentic engagement and on-chain activity of a token. Unlike raw volume or liquidity figures—which are easily faked or inflated by bots—this score focuses on real user activity, making it a stronger indicator of genuine interest. It considers factors such as:
* Holder count
* Trading volume (from real wallets, not bots)
* Liquidity trends
* Other heuristics that ensure reliable detection of organic token growth
Before you trade or add liquidity for a specific token, please conduct your own due diligence and assess the token’s risks on Rugcheck, JupShield, and Jupiter Organic Score.
### Compromised Wallets
What should you do if your wallet is compromised?
Unfortunately, if your wallet has been compromised, the best approach would be to transfer your assets to a new wallet immediately and LP with the new wallet.
Please always be wary of scams, phishing links, and downloading any programs. Team members would never DM you directly or ask you to join another discord. NEVER give or show your wallet’s private key to anyone.
For any points, airdrop, or rewards system, it would be extremely challenging to verify the original owner of the compromised wallet once multiple malicious parties have access to it.
# How to Swap Tokens on Meteora
Source: https://docs.meteora.ag/user-guides/swapping-tokens-on-meteora
Learn how to swap tokens on Meteora using Jupiter Terminal or a pool's Swap tab, and how to review liquidity, slippage, fees, and price impact before swapping.
If you find yourself in a position where you lack one or both of the tokens required to add liquidity to a pool, you can swap tokens on Meteora using one of these methods:
## Jupiter Terminal
Meteora has integrated [Jupiter](https://jup.ag/) - the most popular DEX aggregator - to help you swap at the best rates. This is done through Jupiter Terminal, which is an open-sourced, lite version of Jupiter that provides end-to-end swap flow by linking it in a site's HTML.
When you are navigating through Meteora, you can access Jupiter Terminal by selecting the Jupiter Terminal icon at the bottom left of the screen. You will see a pop-up where you can connect your wallet (this connects automatically if you're connected on Meteora), select your input and output tokens, and execute your swap.
## Swapping within the pool
When you already possess one of the tokens in an asset pair for a pool, you can also swap some amounts of that token to the other directly using the existing pool liquidity. DLMM, DAMM v2, and DAMM v1, all have a “Swap” tab to swap tokens directly within the pool.
For example, if you want to add liquidity to a SOL/USDC pool, but you only have SOL, you can simply select the "Swap" tab on the pool page to swap a portion your total SOL to an equivalent value of USDC (based on the current pool price of the token). Before you swap through that specific pool, please check that the pool has sufficient liquidity and the current pool price of the token is in sync with the market price.
In addition, check that you are comfortable with the settings (e.g. transaction fees, your preferred slippage) of that pool, and check that the “Swap info” section is acceptable before you execute your transaction.
### How is "Price Impact" on the UI calculated for a swap that occurs through a pool?
Price Impact is the % difference between the value of your input amount and the value of your output amount.
On the Meteora user interface, Price Impact %:
* Does not take slippage into account for the swap output amount, so you'll have to set slippage rate to 0 before calculating if you want a more precise %.
* Does not take into account that the dollar value in the swap input box is sourced from Jupiter's price API, so it may not always be 100% accurate. For example: sometimes USDC will be worth \$0.9999
* Does not take into account the Swap fee that's charged on the swap.