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

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

<Warning>
  FCFS without a practical per-wallet cap can concentrate the vault in the earliest depositors.
</Warning>

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

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

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