> ## Documentation Index
> Fetch the complete documentation index at: https://docs.meteora.ag/llms.txt
> Use this file to discover all available pages before exploring further.

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

<Info>
  Launch Pools.Alpha Vault runs on the mainnet program `vaU6kP7iNEGkbmPkLmZfGwiGxd4Mob24QQCie5R9kd2`. The program Alpha Vault supports **DLMM**, **DAMM v1** (`DynamicPool`), and **DAMM v2**
</Info>

<Note>
  Alpha Vault is not a separate AMM. It is an account-based allocation layer that uses the connected Launch Pool for the actual buy.
</Note>

## 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

<CardGroup cols={2}>
  <Card title="Connected Launch Pool" icon="rocket" iconType="solid">
    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.
  </Card>

  <Card title="Two Allocation Modes" icon="sliders" iconType="solid">
    Pro Rata supports oversubscription with proportional allocation. FCFS accepts deposits until the configured cap is reached.
  </Card>

  <Card title="Permissioned or Open Access" icon="user-shield" iconType="solid">
    Escrows can be permissionless, Merkle-proof based, or created by the vault authority.
  </Card>

  <Card title="Linear Claims" icon="calendar-clock" iconType="solid">
    Bought tokens unlock linearly from `start_vesting_point` through `end_vesting_point`, using either slots or timestamps.
  </Card>

  <Card title="Quote Refunds" icon="rotate-left" iconType="solid">
    Users can withdraw Pro Rata overflow and any final quote left after the vault's buying window.
  </Card>

  <Card title="Token Program Awareness" icon="certificate" iconType="solid">
    Vault transfers use checked token transfers and account for Token 2022 transfer fees and required transfer memos where applicable.
  </Card>
</CardGroup>

## 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

<CardGroup cols={2}>
  <Card title="Alpha Vault Modes" href="/helper-products/alpha-vault/vault-modes" icon="sliders" iconType="solid">
    Compare Pro Rata and FCFS behavior, including caps, withdrawals, overflow, and user experience.
  </Card>

  <Card title="Alpha Vault Launch Design Guide" href="/helper-products/alpha-vault/launch-design-guide" icon="chess" iconType="solid">
    Choose mode, caps, access model, deposit timing, and vesting settings for a launch.
  </Card>

  <Card title="Alpha Vault Whitelist and Access" href="/helper-products/alpha-vault/whitelist-and-access" icon="user-shield" iconType="solid">
    Understand permissionless escrows, Merkle roots, authority-created escrows, and wallet caps.
  </Card>

  <Card title="Alpha Vault Formulas" href="/helper-products/alpha-vault/formulas" icon="calculator" iconType="solid">
    Review the allocation, refund, vesting, and rounding math used by the vault.
  </Card>
</CardGroup>

<Warning>
  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.
</Warning>