Products Overview

The PirateCrew Blockchain API ships eight product surfaces. Each one is a /v2/<resource> namespace with its own CRUD shape, lifecycle, and webhook events. Rather than browsing alphabetically, pick by goal.

By goal

By role in a typical launch

A token launch on PirateCrew touches multiple products in sequence. Here's the canonical order:

1. Tokens — mint SPL + Metaplex metadata in one transaction.
2. Pools — create a Meteora DBC pool quoted in GOLD; the pool migrates to DAMM v2 once it hits its market-cap target.
3. Fees — once volume flows, claim DBC partner fees (or DAMM v2 fees post-migration) and atomically split across creators, KOLs, and treasury.
4. Airdrops — distribute a chunk of supply to a snapshot of holders via a keccak-256 merkle tree.
5. Staking + NFTs + GOLD — engagement loops (mint a crew NFT, stake it, lock GOLD for veGOLD).

If this is your first read, the Create and launch a token recipe walks the first three end-to-end with copy-pasteable curl.

What every product shares

All write endpoints follow the same patterns. Read these once and they apply everywhere:

• Transaction Modes — unsigned (client signs) vs signed (server signs via Privy). Per-endpoint mode support is documented on each product page.
• Idempotency — every write takes an Idempotency-Key header; retries return the original response.
• Resource lifecycles — every long-lived resource exposes an explicit status field, and every transition fires a webhook.
• Scopes & Permissions — mode: "signed" requires a scope on the API key. User-signed-only endpoints (stake, claim, mint NFT, lock gold) reject mode: "signed" regardless of scope.

Where the schemas live

Every product page describes the shape of its requests at a conceptual level. For the exhaustive field list and validation rules, the source of truth is the OpenAPI document:

• Human-readable: /v2/docs
• Machine-readable: /v2/openapi.json