If you’re integrating a token monitor and a rising price looks healthy, check whether pool depth is rising too: read the chart beside the pool’s reserves and track both at the same block height. Use PooCoin Charts to identify the pair and inspect its price and trading activity; your own indexer should supply the reserve history. For a separate walkthrough of chart navigation, see how to speed up a PooCoin chart workflow.
1. Which pair should the monitor follow?
-
Resolve the token to a specific pool before collecting data. On BNB Smart Chain, a token can trade against WBNB, a stablecoin, or another asset, and each pair has its own reserves and price. PooCoin typically charts the pair with the most liquidity, but an integrator should record the chosen pair address and factory, rather than assume the token address alone identifies the market.
-
Choose the pair that matches the decision you want to support. The deepest pool is usually the best proxy for executable market depth; a stablecoin quote may be easier to compare with USD, while a WBNB pair may carry most of the trading activity. If the monitor combines pools, keep per-pool values available as well as the aggregate: summing liquidity across pairs can hide fragmented depth and inconsistent quotes.
2. How do you measure liquidity at each chart point?
-
For a V2-style pool, index reserve updates by block and transaction order. Read the pair’s Sync events, which report reserves after a state change, or call getReserves() at a fixed block for a snapshot. Store the block number, timestamp, transaction index, log index, and both raw reserves. Convert token amounts using each token’s decimals only after decoding the integer values.
-
Calculate depth in a common quote currency, and retain the raw reserves. For a token/WBNB pool, value both sides using a contemporaneous WBNB price; for a stablecoin pair, account for the stablecoin’s actual market price if the display is meant to represent USD. In a balanced constant-product pool, total marked value is approximately twice the quote-side value. That shortcut fails when the pool is skewed, so the two reserve values should remain inspectable.
-
For concentrated-liquidity pools, do not treat total token balances as active depth. A V3-style pool’s usable liquidity depends on tick ranges and current price. Track active liquidity and the liquidity changes at initialized ticks, or query a protocol-aware indexer. A pool can hold substantial assets while having little liquidity near the current price.
3. How should the chart and liquidity timeline line up?
-
Join each price observation to the pool state that produced it. A practical candle key is pool address, interval, and opening block; preserve the closing block too. For intrablock ordering, process swaps and reserve updates by transaction index and log index. Joining minute candles to the latest reserve snapshot by wall-clock timestamp alone can attach a post-trade reserve to a pre-trade price.
-
Plot liquidity as a step series or a second axis, not as another price. Reserve changes occur on pool events, while candles aggregate trades over time. Carry the last known reserve state forward between events, and mark missing indexer coverage as a gap instead of interpolating through it. A 1-minute chart paired with a 5-minute liquidity refresh can miss several changes in a volatile pool; match refresh cadence to the chain feed and the alert latency you need.
-
Separate pool depth from trading volume and token market capitalization. Volume measures swaps over a window; market capitalization estimates token value across supply; neither says how much a trade can execute against the selected pair now. For a constant-product pool, reserves follow x × y = k between liquidity actions, and a swap changes their ratio. That reserve ratio drives spot price, while the fee and trade size affect the execution price.
4. What signal should the integration surface?
-
Alert on joint movement and quantify it against a baseline. For example, a 20% price rise while quote-side reserves fall 35% over the same block interval suggests the move is occurring with less backing depth. Those numbers are illustrative; set thresholds from the pool’s normal volatility and liquidity, using a rolling baseline such as the median reserve value over the previous 24 hours rather than a universal cutoff.
-
Make the common mistake visible: a green chart is not proof of improving liquidity. A buy can raise spot price while leaving fewer quote assets available for the next seller. Show price change beside reserve change, and, where useful, estimate price impact for a standard trade size against current reserves. In a balanced pool, larger trades move the reserve ratio more; the estimate is pool-specific and should include fee assumptions.
-
Reconcile event data before notifying downstream systems. Handle reorganizations by delaying final alerts until the configured confirmation depth, and make event processing idempotent using chain ID, transaction hash, and log index. A sudden reserve drop may be a real removal, a migration to a new pair, or an indexing gap; verify the pool’s latest state and token pair before describing it as an exit.
In practice, I’d keep PooCoin as the human-readable chart check and treat the chain-indexed pool state as the integration’s source of truth. That pairing lets a developer inspect the same market visually while preserving block-level evidence for alerts and downstream analysis.