XCP DEX is the modern trading interface and market-data service for the Counterparty DEX, a protocol-native spot venue on Bitcoin. XCP.io provides the underlying explorer and indexing infrastructure; both properties are operated by the same team and read the same indexed Counterparty and Bitcoin settlement data. This page defines exactly what the numbers at api.xcpdex.com mean.
The feed reports completed spot executions from three protocol-native mechanisms:
completed status. Order matches involving BTC remain pending until the required BTCPay confirms; pending matches are never counted, and a match that expires unpaid never enters the feed.PSBT/UTXO swaps are excluded. Exchange PSBT trading is retired; DigiRare Marketplace handles PSBT trading. The unused trade-ID namespace code 3 remains reserved. Markets are an explicit allowlist (/catalog/pairs), not everything the protocol has ever traded; each entry declares which execution sources actually feed it. CoinGecko and CoinMarketCap use separate profiles. The initial CoinGecko profile contains only XCP_BTC; additional Counterparty assets require exact CoinGecko identity approval.
A Bitcoin payment can release several assets at once. We allocate that payment across all assets in the bundle, in proportion to their protocol prices and quantities, with total volume capped at the actual payment. If total protocol notional is below the payment, the excess is excluded as overpayment. Execution prices use each asset's allocated BTC share; these are bundle allocations, not independently negotiated prices. Allocation happens before any asset or visibility filter. Separate Bitcoin outputs remain separate payments. Advertised dispenser rates remain the prices used for open offers.
On BTC-quoted pairs, open DEX orders are excluded from aggregator bid/ask fields. Counterparty does not commit the BTC leg when the order is placed, so an open intent is not reliable executable depth. Only a match whose separate BTCPay completed enters trades, prices, and volume. A dispenser is different: its offered asset is escrowed by the protocol, so open dispensers with inventory remain executable asks. Protocol-asset pairs such as PEPECASH_XCP retain their normal open book.
CoinGecko AMM liquidity values both reserves at the pool's own reserve ratio and converts that quote value through the current XCP/USD or BTC/USD anchor from XCP.io. Counterparty pools use the constant-product x * y = k curve, with a 50 bps input fee when either leg is XCP and 100 bps otherwise.
0.00000000001), so prices are not truncated to eight decimals.last_price always comes from a completed settlement. An open bid or ask is never promoted into last_price. Where a market's last completed settlement is old, the price remains visible and is labeled: is_stale is true when no settlement occurred within the last 90 days, and last_trade_timestamp carries the settlement's Bitcoin block time.The DefiLlama endpoint is venue-wide and does not use the fixed CoinGecko/CoinMarketCap market allowlist. It includes every non-hidden Counterparty market whose executed quote asset is BTC or XCP, so long-tail base assets are included without assigning them speculative prices. The endpoint returns native BTC and XCP quote balances; DefiLlama applies its historical BTC and XCP prices for each requested period.
Direct order-book self-matches, where the indexed maker and taker Bitcoin addresses are equal, are excluded as wash trading. Different-address executions are not removed without evidence that the addresses share an owner.
/defillama/volume accepts an exact half-open historical window in Unix seconds:start_timestamp is inclusive and end_timestamp is exclusive. A window that the indexer has not completed returns 503 instead of partial data or a placeholder zero. Finalized historical responses are cached at the edge and the endpoint performs no database writes.
All 24-hour figures use a rolling window — request time minus 24 hours through request time — not a UTC calendar day. Inclusion is governed by the Bitcoin block time of the confirming block for every source (order match completion, pool fill, dispense). When no settlement occurred in the window, volumes are 0.00000000 and high/low fall back to last_price.
Every published fill carries a permanent unique integer:
trade_id = source_id × 8 + source_code 0 = order-book settlement 1 = AMM pool fill 2 = dispenser execution 3 = reserved for PSBT/UTXO swaps
Fills are only ever appended under protocol-derived unique keys (order-match identity; transaction hash plus dispense index), so an ID never changes or repeats. Each fill also carries source and settlement_txid, so any number in the feed can be verified against the Bitcoin blockchain directly.
A reconciliation gate runs against the live API before any aggregator submission and after any accounting change. It requires each profile to reconcile field-for-field with canonical settlement data and shared markets to agree across adapters; ticker bid/ask equal to the order book's top levels; ticker volumes, high, low, and last price equal to the full rolling-24h historical window (paged exhaustively); no duplicate trade IDs; no nonpositive prices; sorted books; and stale flags consistent with the 90-day rule.
The accounting rules above are additionally locked by regression tests, including a fixture reproducing a real observed pathology: one Bitcoin output triggering twenty dispensers, where the venue must cap combined allocations at the one payment. The 151-asset Pokémon bundle on September 16, 2026 is also covered: 0.02 BTC total, not 3.02 BTC.
dan@droplister.com