TypeScript CLI for automating a Meteora DAMM v2 pool with FCFS Alpha Vault support: mint the base token, create the pool (hasAlphaVault: true), then create the customizable FCFS vault tied to that pool.

• Node.js 18+ recommended
• npm (or any compatible package manager)
• RPC endpoint with sufficient rate limits for mainnet launches
• Pinata API key + secret (token mint step uploads image + metadata JSON to IPFS)

1. Install

   npm install

2. Configure

   cp .env.example .env

   Edit .env. The full variable list and comments live in .env.example.

3. Run in order

   Step	Command	Sends transactions?	Output (default paths)
   1. Mint + metadata	npm run mint:token	Yes — always executes on-chain (fund the wallet on mainnet; devnet may auto-airdrop if balance is low)	data/latest-token-mint.json
   2. DAMM v2 pool	npm run launch:dammv2	Only if DRY_RUN=false	data/latest-pool.json
   3. FCFS Alpha Vault	npm run create:alpha-vault:fcfs	Only if DRY_RUN=false	data/latest-alpha-vault.json

4. Dry run (pool + vault)
   Leave DRY_RUN=true (default). Scripts still write JSON outputs so you can verify addresses and parameters before broadcasting.

5. Go live
   Set DRY_RUN=false for launch:dammv2 and create:alpha-vault:fcfs, then run those steps again.

6. Validate pipeline (in-memory Redis, no live txs for vault step):

   npm run validate

• WALLET_SECRET_KEY — JSON byte array ([1,2,…]), comma-separated bytes, or base58 secret key.
• RPC_URL — Your cluster RPC; cluster is inferred from the URL unless you set CLUSTER (devnet | mainnet-beta).
• CONFIG_ADDRESS — Existing DAMM v2 config account pubkey (required for pool creation).
• DRY_RUN — true (default): pool and Alpha Vault scripts do not send transactions; they still persist JSON artifacts.
• TOKEN_MINT_OUTPUT_PATH / POOL_OUTPUT_PATH / ALPHA_VAULT_OUTPUT_PATH — Wire steps together without copy-pasting addresses. Each step also mirrors artifacts to Redis (REDIS_URL, optional LAUNCH_SESSION_ID).
• REDIS_URL — Redis for launch artifact handoff (default redis://127.0.0.1:6379). Set REDIS_MEMORY=true for in-memory mode during npm run validate.
• POOL_ADDRESS (optional, Alpha Vault step) — Override pool address instead of reading POOL_OUTPUT_PATH.
• SILENT_LOGS=1 — Reduce console noise from logger output.

Pinata, token metadata, pool pricing, caps, whitelist mode, and vesting timestamps are documented inline in .env.example.

1. Token — mint:token writes tokenMint (and metadata URIs) to the mint output file.
2. Pool — launch:dammv2 reads that mint, uses CONNECT_ALPHA_VAULT_POOL (default true), and writes poolAddress (+ timing fields the vault script may use).
3. Alpha Vault — create:alpha-vault:fcfs uses @meteora-ag/alpha-vault with PoolType.DAMMV2, derives depositing/vesting windows from pool activation when present, and writes vault details + optional txSignature.

Dependencies (from package.json): @meteora-ag/cp-amm-sdk, @meteora-ag/alpha-vault, @solana/web3.js, @solana/spl-token, @metaplex-foundation/mpl-token-metadata, and others.

Launching with an Alpha Vault lets multiple prepared wallets participate in a controlled early window at a single effective price (per vault rules), instead of racing public liquidity with ad-hoc bundled swaps. Exact on-chain footprint depends on how you fund and operate wallets; this kit focuses on Meteora-native pool + FCFS vault setup rather than Jito-style bundles.

For a live example and holder visualization, see the links and illustration in the Example (Bubblemaps) section below.

Alpha Vault is Meteora’s mechanism to tie a vault to a pool (DAMM or DAMM v2) so early participants deposit quote during a window and receive base tokens under vesting and cap rules. This repository targets DAMM v2 and FCFS (createCustomizableFcfsVault) with configurable:

• Depositing window and vesting schedule (timestamps; defaults derived from pool activation when available)
• Global and per-wallet caps (raw quote units: lamports for WSOL, 6 decimals for USDC)
• Whitelist mode: permissionless, permission_with_merkle_proof, or permission_with_authority

graph TD
  C[Creator Wallet] --> M[Mixing Wallet]
  M --> L2A[Layer 2 Wallet A]
  M --> L2B[Layer 2 Wallet B]

  L2A -.-> D1[Dormant 7 days]
  L2B -.-> D2[Dormant 14 days]

  D1 --> W1[User Wallet 1]
  D1 --> W2[User Wallet 2]
  D1 --> W3[User Wallet 3]

  D2 --> W4[User Wallet 4]
  D2 --> W5[User Wallet 5]
  D2 --> W6[User Wallet 6]

  style C fill:#ff6b6b
  style M fill:#feca57
  style W1 fill:#48dbfb
  style W2 fill:#48dbfb
  style W3 fill:#48dbfb
  style W4 fill:#48dbfb
  style W5 fill:#48dbfb
  style W6 fill:#48dbfb

  linkStyle 0,1,2 stroke:#ff9ff3,stroke-width:2px
  linkStyle 3,4,5,6,7,8 stroke:#1dd1a1,stroke-width:1px,stroke-dasharray: 5 5

This tooling interacts with mainnet contracts and irreversible transactions. You are responsible for key safety, regulatory compliance, and the economic design of your launch. Test on devnet first when possible.

https://t.me/solzen77