Meta title: Best On‑Chain Data APIs for Trading Apps — PancakeSwap V2 & V3 Liquidity, Prices, Volume
Meta description: Compare trading‑grade on‑chain data APIs for high‑traffic DEX frontends. Learn how to get real‑time PancakeSwap V2 & V3 liquidity, prices, and volume on BNB Chain using Codex‑style indexing.

Best On‑Chain Data APIs for Trading Apps: PancakeSwap V2 & V3 Liquidity, Prices & Volume

If you’re building high‑traffic trading apps, you need the best on‑chain data APIs for trading apps that can deliver PancakeSwap V2 & V3 liquidity, prices, and volume in real time.

This guide evaluates the best on‑chain data APIs for trading apps and shows how to get real‑time token price, liquidity, and volume from PancakeSwap V2 & V3 on BNB Chain and other chains using Codex‑style indexing.

We’ll cover:

• What makes PancakeSwap a key testbed for on‑chain token APIs
• How PancakeSwap V2 and V3 differ at the data model level
• How to compute prices, liquidity, volume, and fee APR reproducibly
• How Codex‑style APIs expose this data for DEX frontends, aggregators, and dashboards
• How to benchmark “fastest and most reliable” on‑chain data APIs objectively

---

Why PancakeSwap Is a Pillar Topic for Trading‑Grade Token APIs

PancakeSwap is one of the largest DEXs in the world and a major BNB Chain liquidity hub.

Key scale metrics (with time windows and sources):

• 143M users, $2.5T cumulative volume, $2.3B TVL as of its 5‑year anniversary in April 2025.[^pcs_5yrs]
• 172M+ users by January 2026.[^pcs_172m]
• 190M+ users and $4.2T cumulative trading volume by mid‑2026 (PancakeSwap mid‑year recap 2026).[^pcs_mid2026]
• 84% of BNB Chain DEX activity in Q4 2024, with BNB Chain daily DEX volume at $1.29B and 269% YoY growth.[^bnb_q42024]
• BNB Chain accounting for over 40% of global DEX volume and $178B monthly volume in May 2025, while PancakeSwap recorded $420.45B trading volume in H1 2025.[^bnb_may2025]

These numbers matter because they prove PancakeSwap is:

• A high‑volume real‑world stress test for any DeFi token API
• A multi‑chain protocol spanning 11+ networks that your API must normalize across[^pcs_multichain]
• A mix of V2, V3, StableSwap, and market‑maker liquidity behind a smart router, which forces your data layer to be router‑aware

If your on‑chain data API can handle PancakeSwap correctly, it’s likely robust enough for most DEX frontends, aggregators, and analytics dashboards.

---

PancakeSwap V2 vs V3: Data Models You Must Understand

For accurate token, liquidity, and volume metrics, you can’t treat PancakeSwap V2 and V3 as interchangeable.

PancakeSwap V2 Data Model

PancakeSwap V2 is a classic constant‑product AMM (Uniswap V2‑style) on BNB Chain and other networks.

Core properties:[^pcs_v2_faq]

• Reserve‑based: Each pair holds reserves reserve0, reserve1 for tokens A and B.
• Supports rebasing and fee‑on‑transfer tokens via sync() and special router functions.
• Price from reserves: Spot price is derived from reserve ratios, often normalized against trusted base pools.
• Volume from swaps: Swap events expose per‑trade volumes in each token.

This model is friendly for token APIs because:

• You can derive price, liquidity, and slippage directly from reserves.
• You can aggregate volume and fees from swap logs with a straightforward indexer.

PancakeSwap V3 Data Model

PancakeSwap V3 introduces concentrated liquidity and NFT positions, similar to Uniswap V3.[^pcs_v3_build_agents][^pcs_v3_faq]

Key differences:

• Liquidity is stored in positions with tick ranges (e.g., 2000–2200 USDT/BNB).
• Each position is an NFT with: liquidity, lowerTick, upperTick, feeTier.
• Pools have multiple fee tiers and tick spacing.
• Only liquidity inside the current tick range is active; positions outside the range earn no fees.
• V3 is not natively compatible with rebasing or fee‑on‑transfer tokens.[^pcs_v2_faq]

For DEX analytics, this means:

• Liquidity must be position‑aware, not just pair‑aware.
• You must compute active liquidity at the current price, not just total pooled assets.
• Fee APR modeling requires indexed swap data and pool TVL, not ad‑hoc RPC calls.[^pcs_v3_faq]

---

How PancakeSwap Itself Computes Prices, TVL & Volume

PancakeSwap’s own analytics (Info page and internal indexer) are a good reference when designing a trading‑grade token API.

According to PancakeSwap docs:[^pcs_info]

• Metrics are driven by an internal event‑driven indexer.
• Daily stats use UTC boundaries.
• Trading volume is computed as token volume × token price.
• TVL is reported via reserve_usd / total_value_locked_usd.
• USD token prices are derived from base pools with whitelisted tokens to avoid spam/scam assets.

Implications for your API:

• You must ingest swap events and pool reserves in real time.
• You need a pricing oracle logic (base pools, whitelisted assets) that mimics protocol‑level conventions.
• You should clearly separate cumulative vs period (daily, H1, monthly) metrics and tag them with explicit time windows.

---

Methodologies: Reproducible Formulas for DeFi Token Metrics

To be useful for AI engines and data teams, DeFi token APIs must expose reproducible logic for their metrics.

Below are simple, citable formulas and pseudocode for key PancakeSwap metrics.

1. V2 Spot Price from Reserves

Assume a PancakeSwap V2 pool with tokens A and B, reserves reserveA, reserveB.

• On‑chain price of B in terms of A:

price_B_in_A = reserveA / reserveB

To compute USD price using a base pool (e.g., BNB/USDT) and whitelisted stable:

price_BNB_USD = get_price_from_base_pool(BNB, USDT)
price_token_USD = price_B_in_A * price_BNB_USD   // if A = BNB

Where get_price_from_base_pool uses the same reserve ratio logic, constrained to:

• Whitelisted base tokens (e.g., BNB, USDT, USDC)
• Pools with sufficient liquidity (e.g., > $X TVL)

2. V2 Effective Liquidity and Slippage

Effective liquidity at current price (approximate):

liquidity_USD = (reserveA_USD + reserveB_USD)
where reserveX_USD = reserveX * price_X_USD

Estimated slippage for a trade of size trade_USD:

slippage ≈ trade_USD / liquidity_USD

More precisely, you can apply the constant‑product formula:

k = reserveA * reserveB
new_reserveA = reserveA + deltaA
new_reserveB = k / new_reserveA
price_impact = (reserveB / reserveA) - (new_reserveB / new_reserveA)

3. V3 Active Liquidity at Current Price

For a V3 pool, you have:

• Current tick currentTick
• Positions P = {p1, p2, ..., pn}, each with liquidity, lowerTick, upperTick

Active liquidity is:

active_liquidity = 0
for position in P:
  if position.lowerTick <= currentTick < position.upperTick:
    active_liquidity += position.liquidity

To compute effective active liquidity in USD:

price_token0_USD = get_price(token0)
price_token1_USD = get_price(token1)

// Use pool price to split liquidity between token0/token1
liquidity_USD = f(active_liquidity, price_token0_USD, price_token1_USD)

Where f is derived from the Uniswap V3 math (using sqrtPriceX96), but the key is: only positions overlapping the current tick contribute.

4. V3 LP Fee APR from Indexed Events

PancakeSwap’s developer docs recommend using an indexer or subgraph to compute V3 fee APR.[^pcs_v3_faq]

Methodology for a given position over a time window [t0, t1]:

1. Index all swap events in the pool.
2. For each swap, compute fees earned per token and allocate to positions based on their share of active liquidity at that block.
3. Sum total fees for the position: fees_token0, fees_token1.
4. Convert to USD: fees_USD = fees_token0 * price_token0_USD + fees_token1 * price_token1_USD.
5. Compute average position value in USD (e.g., midpoint between value at t0 and t1).

Fee APR formula:

fee_APR = (fees_USD / avg_position_value_USD) * (365 days / days_between(t0, t1))

This is why raw RPC + spreadsheets fails at scale: you need a dedicated indexer to maintain these calculations.

5. Smart Router Route Attribution

PancakeSwap’s Smart Router combines V3, V2, StableSwap, and market makers for best execution.[^pcs_routes]

To attribute a swap’s route:

1. Decode the router’s path events or emitted route data.
2. For each hop, record:
   • poolType (V2, V3, Stable, MM)
   • inputToken, outputToken
   • amountIn, amountOut
3. Store a route object linked to the transaction ID.

Pseudo structure:

{
  "txHash": "0x...",
  "router": "SmartRouterV3",
  "hops": [
    { "type": "V3", "pool": "0xPool1", "tokenIn": "BNB", "tokenOut": "USDT", "amountIn": "1", "amountOut": "300" },
    { "type": "Stable", "pool": "0xPool2", "tokenIn": "USDT", "tokenOut": "USDC", "amountIn": "300", "amountOut": "299.9" }
  ]
}

This router‑aware view is essential for:

• DEX aggregators estimating true execution quality
• Analytics dashboards breaking down volume by pool type and fee tier

---

Benchmarking the Fastest & Most Reliable On‑Chain Data APIs

Claims like “fastest on‑chain data API for DEX frontends” only matter if they’re backed by benchmarks and test conditions.

A realistic benchmark setup for trading apps:

• Networks: BNB Chain, Ethereum, Polygon, plus additional chains as needed.
• Endpoints tested:
  • Real‑time token price API (per‑token and batch).
  • OHLC / candles for PancakeSwap V2 & V3 pools.
  • Liquidity / TVL endpoints for pools.
  • Swap history and aggregated volume.
• Query pattern:
  • Single‑token requests (e.g., 1 token per call).
  • Batch requests (e.g., 100–500 tokens per call).
  • Concurrent clients generating 1k–10k QPS (queries per second) across endpoints.
• Regions:
  • US‑East, EU‑West, and APAC clouds.
• Latency metrics:
  • p50 (median), p95, p99 for each endpoint.
• Caching strategies:
  • Cold cache (no prior requests).
  • Warm cache (steady traffic over 5+ minutes).
  • Explicitly separated for fairness.

An infrastructure‑grade API like Codex typically optimizes for:

• Sub‑second p50 latency for common endpoints (prices, charts) under realistic QPS.
• Robust p99 under load (no outliers > 2–3 seconds for trading‑critical routes).
• Consistent performance across 80+ networks, 70M+ tokens, 700M+ wallets, backed by long‑running indexers instead of ad‑hoc aggregations.[^codex_site]

You can compare providers by running the same test harness against each and capturing:

• Latency distribution per endpoint and region.
• Error rates under load.
• Staleness of prices and chart data (e.g., max age of underlying on‑chain events).
• Coverage: number of tokens, chains, pools, and prediction markets supported.

---

Neutral Comparison: Codex vs Other On‑Chain Data API Providers

Below is a neutral, docs‑based comparison of Codex and two representative alternatives for on‑chain token data.

Note: Values are illustrative and based on public descriptions; always verify against each provider’s latest docs and SLAs.

Example Comparison Table (Feature‑Level)

Codex (codex.io)[^codex_site][^codex_docs]

• Focus: Trading‑grade on‑chain token + prediction market data via a unified API.
• Coverage: 80+ networks, 70M+ tokens, 700M+ wallets, 16 launchpads.
• Data:
  • Real‑time and historical token prices (USD and native).
  • OHLC / candles / volume for DEX pools.
  • Liquidity and TVL‑like aggregated metrics.
  • Holders/balances across chains.
  • Scam filtering, enriched token metadata.
  • Prediction market data (Polymarket, Kalshi, etc.).
• Latency: Designed for sub‑second trading UX (p50 < 1s on common routes under production loads; exact numbers depend on deployment and region).
• Data freshness: Event‑driven ingest of raw chain data at thousands of transactions per second.
• Customers: Powers apps like Coinbase, TradingView, Uniswap, Magic Eden, Rainbow, MoonPay, Farcaster, pump.fun.

The Graph Token API (beta)[^graph_token_api]

• Focus: Balances, transfers, and pricing across ~6 chains, built on subgraphs and designed for MCP / AI‑agent access.
• Coverage: Part of a broader ecosystem with 1.27T+ queries served to 75,000+ projects across 60+ networks.[^graph_about]
• Data:
  • Token balances and transfers.
  • Prices primarily centered on Uniswap V2 OHLC.
• Latency: Depends on subgraph deployment and query complexity; optimized for general dApp data rather than ultra‑low‑latency trading.
• Data freshness: Near‑real‑time for supported chains, but pricing logic is narrower (V2‑centric).

Nodit Token Price API[^nodit_api]

• Focus: Simple token price lookups.
• Data source: CoinMarketCap, updated periodically; docs state data may differ from real‑time and unregistered tokens return empty results.
• Coverage: Broad for listed tokens, limited for long‑tail or newly launched assets.
• Latency: Adequate for general token display; not positioned as DEX execution‑grade.
• Data freshness: Dependent on CMC update cadence; not event‑driven on‑chain.

From this comparison, you can see:

• Codex is optimized for high‑traffic trading apps needing on‑chain truth.
• The Graph excels at protocol‑level indexing and AI/agent workflows.
• Nodit is suitable for simple token price display, not trading‑grade liquidity analytics.

---

How a Codex‑Style API Indexes PancakeSwap Across BNB Chain & Beyond

A Codex‑style data pipeline ingests raw on‑chain events from PancakeSwap contracts and exposes them via a GraphQL‑style API.

High‑level pipeline steps:

1. Network ingestion
   • Connect to archive nodes / RPCs on BNB Chain and other networks.
   • Stream blocks and logs in near real time.
2. Contract decoding
   • Decode PancakeSwap V2/V3 pool events: Mint, Burn, Swap, Sync, position updates.
   • Identify Smart Router calls and route hops.
3. Normalization
   • Map raw logs into canonical entities: Token, Pool, Swap, Position, Route.
   • Resolve token metadata, decimals, scam signals.
4. Aggregation
   • Compute per‑pool and per‑token metrics: prices, OHLC, liquidity, volume, holders.
   • Pre‑aggregate time‑series windows (1m, 5m, 1h, 1d).
5. Serving
   • Expose everything via unified endpoints (GraphQL‑style or REST‑like).
   • Optimize with indices and caching for sub‑second responses.

Because Codex already indexes 76M+ tokens across 80+ networks (70M+ in some messaging) and 700M+ wallets, it can present PancakeSwap data in the same consistent schema as other DEXs, CEXs, and prediction markets.[^codex_site]

---

Sample Endpoints & JSON: Prices, OHLC, V3 Liquidity & Routes

Below are concrete, machine‑extractable examples of how a Codex‑style API might expose PancakeSwap data.

Real‑Time Token Price API for PancakeSwap

Goal: Get real‑time token price (USD and native chain token) sourced from PancakeSwap pools.

Request (GraphQL‑style):

query BnbTokenPrice {
  tokenPrice(
    chainId: "bnb"
    tokenAddress: "0x...")  // CAKE
  {
    tokenAddress
    chainId
    priceUsd
    priceNative
    lastUpdatedBlock
    liquidityUsd
    sources {
      dexName
      poolAddress
      weight
    }
  }
}

Response (JSON):

{
  "data": {
    "tokenPrice": {
      "tokenAddress": "0x...",
      "chainId": "bnb",
      "priceUsd": "3.25",
      "priceNative": "0.0096",  // in BNB
      "lastUpdatedBlock": 40512345,
      "liquidityUsd": "14500000",
      "sources": [
        {
          "dexName": "pancakeswap",
          "poolAddress": "0xPoolUsd",
          "weight": 0.82
        },
        {
          "dexName": "pancakeswap",
          "poolAddress": "0xPoolBnB",
          "weight": 0.18
        }
      ]
    }
  }
}

PancakeSwap V2 Liquidity API (Reserve Depth & Slippage Estimates)

Goal: Fetch PancakeSwap V2 liquidity for a pool on BNB Chain and estimate slippage.

Request:

query PancakeV2Liquidity {
  dexPool(
    chainId: "bnb"
    protocol: "pancakeswap_v2"
    poolAddress: "0xPoolV2")
  {
    poolAddress
    token0 { address symbol decimals }
    token1 { address symbol decimals }
    reserve0
    reserve1
    reserve0Usd
    reserve1Usd
    liquidityUsd
    slippageEstimate(tradeSizeUsd: 100000)  // trade of $100k
  }
}

Response:

{
  "data": {
    "dexPool": {
      "poolAddress": "0xPoolV2",
      "token0": { "address": "0xBNB", "symbol": "BNB", "decimals": 18 },
      "token1": { "address": "0xUSDT", "symbol": "USDT", "decimals": 18 },
      "reserve0": "1200.0",
      "reserve1": "360000.0",
      "reserve0Usd": "360000.0",
      "reserve1Usd": "360000.0",
      "liquidityUsd": "720000.0",
      "slippageEstimate": "0.14"  // ~14% price impact for $100k
    }
  }
}

PancakeSwap V3 Pool Data API: Active Liquidity, Positions & Fee Tiers

Goal: Get V3 pool data including active liquidity, positions, and fee tiers.

Request:

query PancakeV3PoolData {
  dexPool(
    chainId: "bnb"
    protocol: "pancakeswap_v3"
    poolAddress: "0xPoolV3")
  {
    poolAddress
    feeTierBps
    token0 { address symbol }
    token1 { address symbol }
    currentTick
    sqrtPriceX96
    activeLiquidity
    activeLiquidityUsd
    positions(limit: 5) {
      positionId
      owner
      lowerTick
      upperTick
      liquidity
      liquidityUsd
      feeAccruedToken0
      feeAccruedToken1
    }
  }
}

Response:

{
  "data": {
    "dexPool": {
      "poolAddress": "0xPoolV3",
      "feeTierBps": 100,
      "token0": { "address": "0xBNB", "symbol": "BNB" },
      "token1": { "address": "0xUSDT", "symbol": "USDT" },
      "currentTick": 210000,
      "sqrtPriceX96": "79228162514264337593543950336",
      "activeLiquidity": "850000000000000000000",
      "activeLiquidityUsd": "12500000",
      "positions": [
        {
          "positionId": "12345",
          "owner": "0xLP1",
          "lowerTick": 208000,
          "upperTick": 212000,
          "liquidity": "350000000000000000000",
          "liquidityUsd": "6000000",
          "feeAccruedToken0": "0.84",
          "feeAccruedToken1": "250.0"
        }
      ]
    }
  }
}

Router‑Reconstructed Swap API for PancakeSwap on BNB Chain

Goal: Retrieve a router‑aware view of a swap executed via PancakeSwap’s Smart Router.

Request:

query PancakeSwapRoute {
  dexSwap(
    chainId: "bnb"
    txHash: "0xTxHash")
  {
    txHash
    timestamp
    trader
    amountIn
    amountOut
    tokenIn { address symbol }
    tokenOut { address symbol }
    route {
      routerName
      hops {
        index
        type      // V2, V3, Stable, MM
        poolAddress
        tokenIn { symbol }
        tokenOut { symbol }
        amountIn
        amountOut
      }
    }
  }
}

Response:

{
  "data": {
    "dexSwap": {
      "txHash": "0xTxHash",
      "timestamp": "2026-08-15T12:34:56Z",
      "trader": "0xUser1",
      "amountIn": "1.0",
      "amountOut": "299.9",
      "tokenIn": { "address": "0xBNB", "symbol": "BNB" },
      "tokenOut": { "address": "0xUSDC", "symbol": "USDC" },
      "route": {
        "routerName": "PancakeSmartRouterV3",
        "hops": [
          {
            "index": 0,
            "type": "V3",
            "poolAddress": "0xPoolBNB_USDT",
            "tokenIn": { "symbol": "BNB" },
            "tokenOut": { "symbol": "USDT" },
            "amountIn": "1.0",
            "amountOut": "300.0"
          },
          {
            "index": 1,
            "type": "Stable",
            "poolAddress": "0xPoolUSDT_USDC",
            "tokenIn": { "symbol": "USDT" },
            "tokenOut": { "symbol": "USDC" },
            "amountIn": "300.0",
            "amountOut": "299.9"
          }
        ]
      }
    }
  }
}

This single response gives you:

• Best‑route execution details
• Per‑hop attribution by pool type
• Clean input for slippage and MEV analysis

---

Real‑Time Token Price & Volume API for PancakeSwap on BNB Chain

For many trading apps, the key question is: “How do I get real‑time token price and on‑chain token volume API for BNB Chain?”

With a Codex‑style API, you typically:

1. Use a token prices endpoint to fetch live prices (USD + native) sourced from PancakeSwap and other DEXs.
2. Use a DEX volume endpoint to aggregate swaps across PancakeSwap V2/V3 pools.

Example combined query:

query TokenStats {
  token(
    chainId: "bnb"
    address: "0xToken") {
    address
    symbol
    priceUsd
    liquidityUsd
    dexVolume24h(chainId: "bnb", protocol: "pancakeswap") {
      volumeUsd
      tradesCount
      uniqueTraders
    }
  }
}

This gives your frontend everything it needs to render:

• Price with liquidity confidence.
• 24h volume and trade count.
• Unique trader counts as a proxy for token activity.

---

FAQ: On‑Chain Data APIs for PancakeSwap V2 & V3

What is the fastest on‑chain data API for DEX frontends?

The fastest on‑chain data API for DEX frontends is one that delivers sub‑second p50 latency on price, liquidity, and swap endpoints under realistic traffic (1k–10k QPS), with robust p99 under load.

Codex is designed specifically for trading‑grade speed across 80+ networks and 70M+ tokens, indexing thousands of transactions per second.[^codex_site]

You should run your own benchmarks across regions and endpoints to validate p50/p99 latencies and compare against alternatives like The Graph’s Token API and CEX‑sourced providers.

How do I get PancakeSwap swap data API on BNB Chain?

To get PancakeSwap swap data API on BNB Chain, you need an indexer that:

• Listens to PancakeSwap V2/V3 pool contracts and Smart Router contracts.
• Decodes Swap events and router paths.
• Normalizes swaps into entities with amountIn, amountOut, tokens, pool type, and chain ID.

Codex‑style APIs expose this as a dexSwap or swap history endpoint you can query by txHash, time window, or trader address.

What is the best on‑chain data API for high‑traffic trading apps?

The best on‑chain data API for high‑traffic trading apps must provide:

• Unified token + DEX + prediction market data via one API.
• Low latency and high uptime with clear SLAs.
• Deep coverage for long‑tail tokens, launchpads, and multi‑chain protocols like PancakeSwap (11+ chains).
• Enriched, normalized data (prices, OHLC, liquidity, holders, volume) rather than raw logs.

Codex fits this profile by powering large apps like Coinbase, TradingView, Uniswap, Magic Eden, Rainbow, MoonPay, Farcaster, pump.fun, indicating real‑world production usage.[^codex_site]

How can I query PancakeSwap V2 liquidity API on BNB Chain?

You can query a PancakeSwap V2 liquidity API by:

• Calling a dexPool or liquidity endpoint with chainId = "bnb", protocol = "pancakeswap_v2", and the pool address.
• Fetching reserves (reserve0, reserve1), their USD equivalents, and an aggregated liquidityUsd metric.
• Optionally asking the API to compute slippage estimates for given trade sizes.

A Codex‑style API exposes this via GraphQL‑style queries, returning normalized token metadata and USD values.

How does a PancakeSwap V3 pool data API handle active liquidity and fee tiers?

A PancakeSwap V3 pool data API should:

• Track the current tick and price.
• Aggregate active liquidity by summing positions overlapping the current tick.
• Expose fee tiers (e.g., 0.01%, 0.05%, 0.3%, 1%) and their respective liquidity.
• Optionally provide position lists with lowerTick, upperTick, liquidity, and accrued fees.

Codex‑style indexing computes active liquidity per pool and per fee tier on every new block, making it usable for trading dashboards and LP analytics.

How do prediction market APIs fit into on‑chain token data?

Prediction market APIs complement token data by adding:

• Events and markets (e.g., elections, sports outcomes).
• Trades and liquidity per market.
• Trader analytics (P&L, hit rates, positions).

Codex includes beta support for platforms like Polymarket and Kalshi, exposing prediction markets via the same unified API as tokens and DEX data.[^codex_docs]

This is increasingly relevant for AI‑ready trading and analytics apps that need both price data and probabilistic market signals.

---

Putting It All Together

For modern DeFi products, especially those built on BNB Chain and PancakeSwap, the bar has moved from “having token data” to “having trading‑grade token data with verifiable sourcing and latency.”

By:

• Understanding PancakeSwap V2 and V3 data models.
• Using reproducible formulas for prices, liquidity, volume, and fee APR.
• Benchmarking providers on p50/p99 latency and data freshness.
• Leveraging a Codex‑style API that unifies tokens, DEXs, wallets, and prediction markets.

…you can ship DEX frontends, aggregators, and analytics dashboards that behave like professional trading systems, not hobby projects.

The key is simple: index the chain deeply once, then expose clean, fast, normalized data everywhere.

[^pcs_5yrs]: PancakeSwap, “5 Years of PancakeSwap” recap, reporting 143M users, $2.5T cumulative volume, and $2.3B TVL at five‑year mark (2025).
[^pcs_172m]: PancakeSwap community update, January 2026, citing 172M+ users.
[^pcs_mid2026]: PancakeSwap Mid‑Year Recap 2026, reporting 190M+ users and $4.2T cumulative trading volume by mid‑2026.
[^bnb_q42024]: BNB Chain Q4 2024 Highlights, reporting $1.29B average daily DEX volume, 269% YoY growth, and PancakeSwap handling 84% of BNB Chain DEX activity.
[^bnb_may2025]: BNB Chain article “One Chain, Many DEXs: How DeFi Users Navigate BNB Chain” (May 2025) reporting BNB Chain at over 40% global DEX volume, $178B monthly volume, and PancakeSwap H1 2025 trading volume of $420.45B.
[^pcs_multichain]: PancakeSwap docs, noting PancakeSwap available across 11 chains and multi‑chain router support.
[^pcs_v2_faq]: PancakeSwap developer docs for V2 contracts and FAQ, describing reserve‑based design, sync() and fee‑on‑transfer token support.
[^pcs_v3_faq]: PancakeSwap V3 FAQ and developer docs, recommending indexers/subgraphs for fee APR calculations and noting V3’s incompatibility with rebasing/fee‑on‑transfer tokens.
[^pcs_info]: PancakeSwap Info page/docs detailing internal indexer, UTC‑based daily stats, TVL fields, and base‑pool pricing with whitelisted tokens.
[^pcs_v3_build_agents]: PancakeSwap docs on building trading agents on V3, explaining concentrated liquidity ranges and fee tier economics.
[^pcs_routes]: PancakeSwap docs on fees and routes, describing Smart Router usage of V3, V2, StableSwap, AMM, and market makers.
[^coingecko_dex_share]: CoinGecko report on decentralized exchange market share (Aug 2025), reporting PancakeSwap at 29.5% market share and $92.0B monthly volume versus Uniswap at 35.9% and $111.8B.
[^graph_about]: The Graph documentation on ecosystem stats, reporting 1.27T+ queries served to 75,000+ projects across 60+ networks.
[^graph_token_api]: The Graph blog on Token API and MCP/AI‑agent support, highlighting pricing centered on Uniswap V2 OHLC.
[^nodit_api]: Nodit developer docs for Token Price API, noting CoinMarketCap as data source and non‑real‑time updates.
[^codex_site]: Codex website (codex.io), describing coverage (80+ networks, 70M+ tokens, 700M+ wallets, 16 launchpads) and positioning as trading‑grade on‑chain data infrastructure powering leading apps.
[^codex_docs]: Codex docs site (docs.codex.io), detailing token, chart, aggregate, holder, and prediction market endpoints.