PancakeSwap V2 and V3 On-Chain Token APIs: Liquidity, Swaps and Price Data for Builders

Overview: How to Get Production-Ready PancakeSwap Data Without Hand-Indexing

If you’re building trading, analytics, or wallet features on BNB Chain, you need reliable PancakeSwap V2 and V3 token price, liquidity, and volume feeds.

The catch: PancakeSwap V2 and V3 expose very different onchain events and pool structures, and none of them give you a simple price or TVL field. You have to infer them from reserves, ticks, swaps, and oracle state.

This article breaks down:

• The PancakeSwap V2 event model and how to turn pair reserves into token prices
• The PancakeSwap V3 pool and tick model, including sqrtPriceX96, fee tiers, and TWAPs
• How to convert raw events into production-grade price, volume, and liquidity APIs
• How Codex abstracts PancakeSwap V2/V3 so you query it like any other DEX, without custom indexers

PancakeSwap V2: Pair Reserves, Mint/Burn/Swap/Sync and Price

Core architecture

PancakeSwap V2 on BNB Chain is a classic constant-product AMM, based on Uniswap v2.

Key points:

• Each pair is an ERC-20 token contract implementing IPancakePair
• The factory (on BSC: 0xcA143Ce32Fe78f1f7019d7d551a6402fC5350c73) creates pairs via PairCreated
• Pricing follows the x · y = k invariant, where x and y are the reserves of token0 and token1

For builders, PancakeSwap V2 is conceptually simple: price and liquidity are inferred from pair reserves and token decimals.

PancakeSwap V2 events: Mint, Burn, Swap, Sync

To build an onchain token API, you need to understand the event stream:

• PairCreated(address token0, address token1, address pair, uint256)

  • Emitted by the factory when a new V2 pair is deployed
  • Gives you the pair identity and underlying tokens

• Mint(address sender, uint amount0, uint amount1)

  • Liquidity added to the pool
  • Increases reserves; can be used to track liquidity inflow

• Burn(address sender, uint amount0, uint amount1, address to)

  • Liquidity removed
  • Decreases reserves; signals liquidity outflow or LP exits

• Swap(address sender, uint amount0In, uint amount1In, uint amount0Out, uint amount1Out, address to)

  • Core trading activity
  • The basis for volume, trade-side detection, and per-token flow

• Sync(uint112 reserve0, uint112 reserve1)

  • Emitted when reserves are updated
  • Canonical source of current onchain reserves

These events form the backbone of any PancakeSwap V2 swap event decoding pipeline.

From V2 pair reserves to token price

Onchain, there is no explicit price field. You derive it from reserves and decimals.

For a given pair:

• Let reserve0 and reserve1 come from the latest Sync
• Let decimal0 and decimal1 come from the ERC-20 contracts

You can compute:

• Raw price of token0 in token1:

  • price0_in_1 = (reserve1 / 10^decimal1) / (reserve0 / 10^decimal0)

• Raw price of token1 in token0:

  • price1_in_0 = 1 / price0_in_1

For a USD feed, you typically:

1. Pick a quote route (e.g. token0 → WBNB → USDT/USDC)
2. Multiply along the path:
   • price_token0_usd = price_token0_wbnb × price_wbnb_usd

This is the essence of PancakeSwap V2 pair reserves to token price.

Volume and liquidity from V2 events

Production-grade feeds require more than spot price.

You need:

• Liquidity (TVL-style):

  • Use reserve0 and reserve1 from Sync
  • Convert each to USD via routing
  • tvl ≈ reserve0_usd + reserve1_usd

• Volume (per interval):

  • Index Swap events
  • Normalize amounts using token decimals
  • Decide a quote (e.g. volume in token1 or USD)
  • Aggregate over time windows (e.g. 1m, 5m, 1h, 24h)

• Per-token flows:

  • Interpret amount0In, amount1In, amount0Out, amount1Out
  • Determine whether the trade is buy or sell relative to a chosen base token

Doing this across thousands of PancakeSwap V2 pairs on BNB Chain requires robust indexing, decimal normalization, and quote-token routing.

PancakeSwap V3: Fee Tiers, Ticks, sqrtPriceX96 and Oracle State

Why V3 is different from V2

PancakeSwap V3 is a fork of Uniswap v3, with concentrated liquidity and multiple fee tiers per token pair.

Key differences vs V2:

• Liquidity is allocated to price ranges via ticks, not uniformly across the curve
• Each fee tier (e.g. 0.01%, 0.05%, 0.25%) can have its own pool
• The pool stores oracle-like observations for TWAPs

That means a production PancakeSwap V3 price feed needs to understand pool identity, tick spacing, and sqrtPriceX96 encoding.

V3 factory, pool identity and fee tiers

On BNB Chain:

• V3 factory: 0x0BFbCF9fa4f9C56B0F40a671Ad40E0805A091865

Important events:

• PoolCreated(token0, token1, fee, tickSpacing)

  • Defines a specific pool for a pair and fee tier
  • You cannot key by just (token0, token1); fee is part of identity

• FeeAmountEnabled(fee, tickSpacing)

  • Indicates which fee tiers are active and their tick spacing

PancakeSwap’s docs note a subtle difference vs Uniswap v3: the 0.25% fee tier uses 50 tick spacing (Uniswap v3’s 0.3% uses 60). Any index keyed only by token pair will miss pool variants per fee tier.

Handling these nuances is central to handle fee tiers and concentrated liquidity on PancakeSwap V3.

V3 pool state: ticks, liquidity and price

Each V3 pool exposes a rich state interface, including:

• slot0 with fields like:

  • sqrtPriceX96 – current price encoded
  • tick – current tick index
  • observationIndex, observationCardinality, etc.

• liquidity – total in-range liquidity

• ticks – per-tick liquidity and fee growth

• tickBitmap – which ticks have non-zero liquidity

• observations – data for TWAP-style price oracles

These structures power PancakeSwap V3 tick and liquidity explained style analysis.

Decoding sqrtPriceX96 to a real price (PancakeSwap V3)

The core onchain price for V3 is sqrtPriceX96.

Uniswap v3 (and PancakeSwap V3) encode price as:

• sqrtPriceX96 ≈ sqrt(P / Q) × 2^96, where P/Q is the ratio of token1/token0

To decode sqrtPriceX96 to price on PancakeSwap V3:

1. Read slot0.sqrtPriceX96
2. Convert to a floating price ratio:
   • ratio = (sqrtPriceX96 / 2^96)^2
3. Adjust for decimals:
   • price_token1_per_token0 = ratio × 10^(decimal0 - decimal1)

From there, you route to a stable quote (WBNB, USDT, USDC) to get a USD price.

This encoding is why a simple “reserve ratio” approach is not enough on V3.

V3 liquidity: ticks, tickBitmap and ranges

Total active liquidity depends on which ticks currently have liquidity in range.

To compute meaningful liquidity metrics:

• Inspect tickBitmap to see which ticks have non-zero liquidity
• For each relevant tick:
  • Read ticks[tick] to get liquidityGross and liquidityNet
• Aggregate liquidity around the current tick from slot0

Simpler production feeds often use:

• In-range liquidity from liquidity as a base metric
• Combine with price to form an estimated TVL-like stat

This is the foundation for real-time PancakeSwap liquidity and volume API endpoints.

V3 swaps, Mint/Burn/Collect events

PancakeSwap V3 pools emit a different event set vs V2:

• Initialize(uint160 sqrtPriceX96, int24 tick)

  • Pool initial price and tick

• Mint(address sender, address owner, int24 tickLower, int24 tickUpper, uint128 amount, uint256 amount0, uint256 amount1)

  • Adds liquidity to a specific price range

• Burn(address owner, int24 tickLower, int24 tickUpper, uint128 amount, uint256 amount0, uint256 amount1)

  • Removes liquidity from a range

• Collect(address owner, address recipient, int24 tickLower, int24 tickUpper, uint128 amount0, uint128 amount1)

  • Fee collection; relevant for LP fee analytics

• Swap(address sender, address recipient, int256 amount0, int256 amount1, uint160 sqrtPriceX96, uint128 liquidity, int24 tick)

  • Core trading event
  • Includes post-swap price (sqrtPriceX96) and tick

These PancakeSwap V3 Mint Burn Collect Swap events are the source of trades, volume, liquidity changes, and fee flows.

V3 TWAPs via observe() and cumulative tick

For trading bots and risk systems, you often need a time-weighted average price (TWAP) rather than a single tick.

The V3 pool exposes an oracle-like method:

• observe(uint32[] secondsAgos)
  • Returns arrays of tickCumulatives and secondsPerLiquidityCumulativeX128

To build a PancakeSwap V3 observe TWAP cumulativeTick feed:

1. Call observe([t0, t1]) for two time offsets (e.g. [3600, 0] for 1h TWAP)
2. Compute TWAP tick:
   • twapTick = (tickCumulative[1] - tickCumulative[0]) / (t0 - t1)
3. Convert twapTick to price via the standard v3 tick-price relation

This yields a TWAP price you can expose via an onchain DEX price feed API for trading bots.

From Raw PancakeSwap Events to a Production Token API

The indexing challenge

Building your own PancakeSwap onchain token API means you must:

• Track factories and pool/PairCreated events across V2/V3

• Decode and normalize Swap, Mint, Burn, Sync, Initialize, Collect events

• Maintain a canonical mapping of:

  • token contracts
  • decimals
  • fee tiers
  • active pools per pair

• Continually update reserves and slot0 state for spot pricing

• Index observations for TWAPs

• Compute derived metrics:

  • price (in quote tokens and USD)
  • volume per interval
  • liquidity and TVL-like stats

Doing this at scale across BNB Chain and other networks is non-trivial, especially with:

• PancakeSwap Infinity and a universal router routing across V2/V3/stable pools
• Constant token and pool churn
• 24/7 traffic requirements for trading UIs

Normalizing token decimals and swap amounts

To make swap data usable across tokens:

• Always read decimals from each ERC-20 contract
• Convert raw integer amounts to human units:
  • amountHuman = amountRaw / 10^decimals

For normalize token decimals and swap amounts on BSC:

• Apply a uniform representation like amountNormalized in base units (e.g. standard 18 decimals)
• Decide a canonical side per pair (which token is “base”, which is “quote”)

This normalization is essential for cross-pair analytics and global volume charts.

Creating production-ready price, volume, and liquidity feeds

A minimal production design for a PancakeSwap token API usually includes:

1. Token metadata endpoint

   • Returns symbol, name, decimals, contract address
   • Optionally enriched with launchpad info and scam filtering

2. Pair metadata endpoint

   • Current price in quote token and USD
   • TVL-like liquidity metric
   • 24h volume and fee stats
   • Fee tier (for V3)

3. Historical bars endpoint (OHLCV)

   • Candles over configurable intervals
   • Derived from indexed swaps aggregated by time bucket

4. Recent trades / events endpoint

   • Latest swaps for a token or pair
   • Side (buy/sell), amounts, prices, and addresses

5. Real-time stream

   • Push-style WebSocket / subscription for price and volume updates
   • Enables live charts and trading UIs

This is how you turn indexing swap logs to build volume feeds into a practical API.

How Codex Abstracts PancakeSwap V2/V3 for Builders

Trading-grade DEX abstraction for PancakeSwap

Codex ingests and enriches PancakeSwap data on BNB Chain as part of its coverage of 80+ networks, 70M+ tokens, and 700M+ wallets.

Instead of exposing raw PancakeSwap logs, it presents a DEX abstraction layer.

For PancakeSwap specifically, Codex handles:

• V2 pair events (PairCreated, Mint, Burn, Swap, Sync)
• V3 factory and pool events (PoolCreated, FeeAmountEnabled)
• V3 pool events including Initialize, Mint, Burn, Collect, Swap
• slot0 state and TWAP-relevant observations

It turns that into GraphQL-style objects for:

• Token prices (spot and historical) in USD and native quotes
• Pair metadata (price, liquidity, volume, fee tier)
• OHLCV bars (candles) ready for charting
• Token events (trades, transfers) already decoded and normalized

Codex recipe: Detailed token page powered by PancakeSwap

Codex’s own docs outline a “Detailed Token Page” recipe, which applies directly to PancakeSwap on BNB Chain.

Typical pattern:

• Use token to:

  • Fetch metadata and normalized identity

• Use pairMetadata to:

  • Get current price, volume, and liquidity across DEXs (including PancakeSwap)

• Use getTokenEvents to:

  • Pull recent trades and onchain activity

• Use getTokenBars to:

  • Fetch OHLCV bars for charts and analytics

• Subscribe via:

  • onPairMetadataUpdated for real-time price/liquidity updates
  • onTokenEventsCreated for streaming swaps
  • onTokenBarsUpdated for live candles

This pattern lets you build a production-ready price feed from onchain data without touching PancakeSwap’s raw events.

Querying PancakeSwap like any other DEX

From the perspective of a trading or analytics app:

• You do not need to know:

  • BSC factory addresses
  • The difference between V2 Sync and V3 slot0
  • Tick spacing or tickBitmap semantics

• You simply query:

  • token → prices, bars, events
  • pairMetadata for real-time PancakeSwap liquidity and volume API data

Codex hides PancakeSwap’s protocol evolution (V2, V3, Infinity, routers) behind a unified API, consistent with how it treats other DEXs.

This unification aligns with the industry trend where DEX data providers are moving from raw indexing toward opinionated, trading-ready abstractions.

When you still care about protocol detail

Some teams still need lower-level data, for example:

• Backtesting concentrated liquidity strategies on specific fee tiers
• LP analytics tied to Mint/Burn/Collect range positions
• Custom TWAP windows and risk metrics

Codex’s enriched data model preserves enough detail to:

• Identify which pools and fee tiers underlie a given price
• Surface aggregated liquidity by fee tier
• Expose trade streams with DEX and pool attribution

So you get both: clean, trading-grade abstractions and protocol-aware analytics hooks.

Example Data Snapshot: PancakeSwap’s Live Scale

To understand why this abstraction matters, consider current PancakeSwap stats.

On Oct. 14, 2026 (UTC) PancakeSwap’s official info page showed:

• TVL: $3.35B
• 24h volume: $646.98M
• 24h fees: $57.49K

Top pools included:

• USDT/USDC 0.05% with $40.26M TVL
• USDT/WBNB 0.01% with $33.4M 24h volume

At this scale, latency, correctness, and coverage across both V2 and V3 are critical for any onchain trading or analytics product.

Where to Try This in Practice

If you want to work with PancakeSwap data through an all-in-one onchain token and DEX API instead of managing your own indexers, you can explore Codex’s docs and endpoints at codex.io.