Pools

Pools

A pool in the PirateCrew API is a Meteora Dynamic Bonding Curve (DBC) — a linear price curve denominated in GOLD (GoLDDqDRHcGZBiGPeXAYi5ougndqBNQSNXdNeT3re6gr) that lets anyone mint a fresh SPL token and trade it from day zero. When the pool hits its market-cap target it migrates to a Meteora DAMM v2 constant-product pool and trading continues there. This page covers the create / monitor / migrate lifecycle and the endpoints behind it.

Lifecycle

Pool lifecycle — DBC create → migrate to DAMM v2
  • Initial market cap: ~$1,000 USD equivalent, denominated in GOLD.
  • Migration target: ~$100,000 USD equivalent. The on-chain price target is GOLD-denominated; the API derives it from the current SOL→GOLD conversion at config time.
  • Quote token: every DBC pool created by this API is quoted in GOLD, not SOL. Trades go through GOLD → token (and back).
  • Migration is automatic: once the curve threshold is crossed, anyone can call the Meteora migration instruction; the resulting DAMM v2 pool address is deterministic from the DBC config.

Endpoints

MethodPathPurpose
POST/v2/poolsBuild the create-pool transactions (and optionally bundle-submit if you send back signed ones)
POST/v2/pools/{address}/verificationsMark the Supabase launched_crews row confirmed once the bundle lands
GET/v2/pools/{address}Read pool state: config, base/quote reserves, partner fee balances (polymorphic — DBC or DAMM v2)
GET/v2/pools/{address}/curve-progressSingle float 0..1 for migration-progress UI

All write endpoints accept the standard transaction modes, but pool creation is unsigned-only in practice because the ephemeral mint and config keypairs must be co-signed by the client.

Create-pool request shape

{
  "creator": "<Solana address>",
  "pool_params": {
    "name": "Black Pearl",                  // /^[a-zA-Z0-9 ]{1,20}$/
    "symbol": "PEARL",                      // /^[A-Za-z0-9]{1,10}$/
    "image": "data:image/png;base64,…",     // required; NSFW-checked
    "description": "Captain Jack approved", // optional, ≤500 chars
    "buy_amount": 0.5,                      // optional dev-buy in SOL, default 0
    "website": "https://blackpearl.xyz",
    "twitter_url": "https://x.com/blackpearl",
    "telegram": "https://t.me/blackpearl",
    "loot_from": "<optional KOL handle>"
  }
}

image is run through the NSFW moderator before any transaction is built — a 400 with image rejected: <category> is returned on violation.

The unsigned flow

curl -X POST https://api.piratecrew.fun/v2/pools \
  -H "Authorization: Bearer $PIRATE_API_KEY" \
  -H "Idempotency-Key: 9d3e2c8a-…" \
  -H "Content-Type: application/json" \
  -d '{
    "creator": "YOUR_WALLET_PUBKEY",
    "pool_params": {
      "name": "Black Pearl",
      "symbol": "PEARL",
      "image": "data:image/png;base64,iVBORw0KGgo…",
      "buy_amount": 0.1
    }
  }'
{
  "data": {
    "transactions": ["AQABAo...", "AQEDB..."],
    "base_mint": "MINT…",
    "config_address": "CFG…",
    "pool_address": "POOL…",
    "jito_tip_account": "TIP…",
    "rpc_endpoint": "https://mainnet.helius-rpc.com/…",
    "required_signers": {
      "base_mint_secret_key": [/* 64 bytes */],
      "config_secret_key":    [/* 64 bytes */]
    }
  },
  "meta": { "request_id": "req_…" }
}

required_signers.base_mint_secret_key and config_secret_key are ephemeral keypairs generated server-side. They have no value after the pool is created — they exist only to sign their own account-creation instructions in the bundle. Co-sign both, along with your wallet, before bundling.

Submitting the bundle

The two transactions returned must land atomically. Submit them as a Jito bundle through the unified transactions resource:

curl -X POST https://api.piratecrew.fun/v2/transactions \
  -H "Authorization: Bearer $PIRATE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "bundle": true, "signed_transactions": ["<tx1>", "<tx2>"] }'
{
  "data": {
    "bundle_id": "BUNDLE…",
    "signatures": ["sig1", "sig2"]
  },
  "meta": { "request_id": "req_…" }
}

Verify in Supabase

After confirmation, persist the pool row:

curl -X POST https://api.piratecrew.fun/v2/pools/POOL…/verifications \
  -H "Authorization: Bearer $PIRATE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "signature": "sig1" }'

This unlocks the pool in directory listings and fee dashboards.

Reading state

curl https://api.piratecrew.fun/v2/pools/$POOL_ADDRESS \
  -H "Authorization: Bearer $PIRATE_API_KEY"

Returns the polymorphic pool resource — type: "dbc" or "damm_v2", the explicit status lifecycle, base/quote reserves, live partner-fee balances (in GOLD and base token), the config, and migration_progress_bps.

Migration-progress UI

Poll this endpoint for a clean 0..1 value to drive a progress bar:

curl https://api.piratecrew.fun/v2/pools/$POOL_ADDRESS/curve-progress \
  -H "Authorization: Bearer $PIRATE_API_KEY"
{
  "data": { "progress": 0.347 },
  "meta": { "request_id": "req_…" }
}

1.0 means the curve has crossed the migration threshold and anyone can call the Meteora migration instruction. Once migrated, switch fee-claim traffic from kind: "dbc" to kind: "damm_v2" on POST /v2/pools/{address}/fee-claims — see Fees.

Reference

  • Fees — claiming DBC + DAMM v2 partner fees once your pool is generating volume.
  • Tokens — for standalone SPL mints that don't need a bonding curve.
  • Transaction Modesunsigned vs signed.
  • Live schema: /v2/docs.