Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.parquet.exchange/llms.txt

Use this file to discover all available pages before exploring further.

When you close a winning position, Parquet pays you from the pool’s free liquidity. Most of the time that’s instant and you never think about it. When the pool is briefly short, your unpaid amount becomes a deterministic place in line — not a haircut. This page explains how that works and what you can do with a pending claim.

​
The core mechanic

Every winning close is paid from: 
free_liquidity = total_usdc − reserved_usdc − queue_total_owed
If free_liquidity covers your payout, you’re paid in full and walk away. If it falls short, the unpaid portion is recorded as a PayoutQueueEntry PDA, indexed FIFO by idx. You pay roughly $0.30 of SOL rent to open the entry. That rent isn’t burned — it refunds to whoever later calls harvest and drains your entry. See Glossary: payout queue.
The queue is per-pool, not per-market. Free liquidity is a property of the whole USDC vault — so a queue entry opened during a quiet AAPL session can be drained by losing closes on TSLA or NVDA.

​
How the queue pays out

The pool replenishes itself from losing trades. When a losing position closes, the LPs’ gain doesn’t immediately re-enter the LP balance — it parks in a side_bucket. As long as side_bucket > 0, anyone can permissionlessly call: 
harvest(max_entries)
This drains queue entries head-first, pays out the claimants, closes the PDA, and refunds rent to the caller. Once the queue is fully drained, side_bucket unlocks back into the LP balance.
ActorActionEarns
Winning close (short pool)Enqueues a PayoutQueueEntryPays ~$0.30 SOL rent
Losing closeSends LP gain to side_bucket—
AnyoneCalls harvest(max_entries)Per-entry PDA rent refund
Keepers run this loop automatically during US Regular Trading Hours, but the call is open — you can run it yourself. The keeper’s shouldAttemptHarvest pre-flight gate skips submission when side_bucket < first_entry.amount, mirroring the on-chain harvest_payout_queue early-break so the chain doesn’t no-op and the keeper doesn’t burn lamports per stuck entry.
harvest reads the oracle to settle the trader’s payout, so it cannot run while the market is halted (overnight, weekends, US holidays). If your queue entry is still pending at the close, it stays pending until the next session opens and side_bucket accumulates enough from losing closes to drain it.

​
Your unpaid claim isn’t stuck

You don’t have to wait for harvest. A Pending queue entry can be spent in two ways while it’s still in line.

​
Open a new position drawing from the queue

In v4, open_position accepts a split: 
wallet_collateral + from_queue_amount
The instruction debits part of your new collateral from a pending entry. The draw order is phantom-first — it pulls from any phantom_unpaid_owed you hold before touching regular unpaid_owed. This lets you immediately redeploy a pending claim into a new market without idle time. See Glossary: phantom credit.

​
Drain phantom credit back to your wallet

If you’d rather exit, drain_phantom_credit sweeps your phantom balance to your USDC account.
drain_phantom_credit only works when queue_total_owed == 0 — i.e. the queue is fully empty. This is intentional: phantom credit is a courtesy ahead of the regular FIFO line, and the protocol won’t let it jump live claimants.

​
Check your status

The indexer exposes a per-wallet view: 
GET /queue/user/:wallet
Response includes every entry you hold and an aggregate per-market claims summary. Full schema in the Network API reference. If you’re building against the queue directly, the Developer SDK decodes PayoutQueueEntry PDAs and exposes harvest helpers. For the LP-side mechanics — how the queue affects yield, the side_bucket, and queue-aware deposits/withdrawals — see LP payout queue.

​
Why a queue, not socialized losses

Some earlier perpetual designs socialize losses by clawing back gains from winning positions when the pool runs short. Parquet’s v4 design replaces that approach with a deterministic FIFO queue, so a winning trader either gets paid in full or gets a specific place in line.