GOLD

GOLD (GoLDDqDRHcGZBiGPeXAYi5ougndqBNQSNXdNeT3re6gr) is the PirateCrew governance token. To vote, you don't hold GOLD — you lock it, and the program mints you veGOLD, a non-transferable receipt whose balance represents your voting weight.

The lock duration is denominated in days, between 1 and 1460 (≈4 years). Voting weight scales with duration — longer locks mint proportionally more veGOLD — following standard ve-token mechanics. The exact curve is enforced on-chain; refer to the Pirates program for the precise formula.

Lifecycle

Both endpoints are user-signed only. mode=signed is rejected — only the wallet holding the locked balance can authorize the unlock, and the Privy platform wallet doesn't custody user GOLD.

veGOLD is non-transferable by design. There is no transfer instruction; the only way to remove veGOLD from your wallet is to unlock once the lock period has elapsed.

Endpoints

Lock state is fully on-chain. Derive the user_lock_config and user_ve_gold PDAs via POST /v2/pdas/user_lock_config / POST /v2/pdas/user_ve_gold, then read each with GET /v2/accounts/{address}. There is no direct GET /v2/gold-locks/{user} route — the on-chain account is the source of truth.

Lock

curl -X POST https://api.piratecrew.fun/v2/gold-locks \
  -H "Authorization: Bearer $PIRATE_API_KEY" \
  -H "Idempotency-Key: 2b3c4d5e-..." \
  -H "Content-Type: application/json" \
  -d '{
    "user": "USER_WALLET_PUBKEY",
    "platform_id": "pirate-crew",
    "amount": "1000000000",
    "lock_duration_days": 365,
    "platform_fee": 0,
    "mode": "unsigned"
  }'

Response:

{
  "data": { "mode": "unsigned", "transaction": "AQABAo..." },
  "meta": { "request_id": "req_…" }
}

• amount — decimal string of raw base units of GOLD. GOLD has 6 decimals, so "1000000000" is 1,000 GOLD.
• lock_duration_days — integer, 1 to 1460. A 4-year lock (1460) produces maximum voting weight; a 1-day lock produces minimum.
• platform_fee — optional flat lamport fee routed to the platform wallet in the same transaction.

Sign with the user wallet and submit via POST /v2/transactions. Once it lands, the user's GOLD ATA balance has decreased by amount and a fresh veGOLD account has been credited with the corresponding voting weight.

Unlock

curl -X DELETE https://api.piratecrew.fun/v2/gold-locks/USER_WALLET_PUBKEY \
  -H "Authorization: Bearer $PIRATE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "platform_id": "pirate-crew",
    "platform_fee": 0,
    "mode": "unsigned"
  }'

Unlock takes no amount — there's exactly one active lock per (user, platform_id) and it unlocks in full. The program checks the lock's unlock timestamp on-chain; if the duration hasn't elapsed, the transaction fails. If it has, veGOLD is burned and the locked GOLD is returned to the user's GOLD ATA in the same tx.

Reading lock state

curl https://api.piratecrew.fun/v2/gold-locks/USER_WALLET_PUBKEY \
  -H "Authorization: Bearer $PIRATE_API_KEY"

{
  "data": {
    "user": "USER_WALLET_PUBKEY",
    "amount": "1000000000",
    "lock_start_slot": "287342110",
    "unlock_timestamp": "2027-05-18T18:42:11.000Z",
    "status": "locked"
  },
  "meta": { "request_id": "req_…" }
}

If you need the raw on-chain accounts, derive the user_lock_config / user_ve_gold PDAs via POST /v2/pdas/{kind} and fetch with GET /v2/accounts/{address}.

Why veGOLD is non-transferable

Vote-escrow design exists to align voters with long-term outcomes. If veGOLD were transferable, holders could rent voting power to short-term actors right before a contentious proposal, defeating the alignment goal. The non-transferable receipt enforces "you vote with what you've committed yourself" — and the early-unlock path simply doesn't exist on-chain.

Reference

• NFTs — burning Pirates NFTs accrues GOLD points to your ATA; those points lock the same way.
• Transaction Modes — why signed is rejected.
• OpenAPI — full schemas at /v2/openapi.json.