To check whether a liquidity estimate refreshes, compare its value with the pool’s reserves at the same block; a 10% reserve change should not remain invisible beyond the data source’s stated refresh interval. This matters because “liquidity” may mean raw token reserves, their dollar value, or estimated trade depth, and those measures do not update or behave identically. For a BEP-20 token, PooCoin provides price charts and wallet views for checking market context around the change; verify the pool’s reserve state separately.
What should refresh when a pool’s reserves change?
For a constant-product pair, the canonical reserves are the token amounts recorded by the pair contract, commonly exposed through getReserves(). A swap, liquidity mint, or burn updates those reserves and typically emits a Sync event; a tracker that consumes events should update from the event’s block, while one that polls should read the contract again. The pair’s invariant is approximately x × y = k, adjusted for swap fees and liquidity operations.
A dollar liquidity estimate usually prices both reserves and sums them: L ≈ xPx + yPy. In a balanced pool, that is roughly twice either side’s dollar value. The estimate can move even when reserves do not, because the price feed changed; conversely, a reserve update can be missed while a cached dollar figure appears plausible. Check the component reserves and the valuation timestamp or block, not only the final dollar number.
Event indexing and polling make different trade-offs. Event indexing can process every change but depends on a complete, correctly ordered log stream and recovery after disconnects or reorgs. Polling is simpler, but its detection delay is bounded by the polling interval plus RPC and cache latency; a 5-second poll can still show older data if the response is cached for 30 seconds.
How can you test the estimate after a reserve change?
Use one pool and one confirmed reserve-changing transaction. Record the transaction’s block number, read both reserves at that block, and compare them with the estimate after the tracker has had time to process that block. Then read at the next block as well: this separates a stale estimate from a price movement or another swap that happened immediately afterward.
For example, suppose a pair holds 100 BNB and 20,000 tokens before a swap. Afterward it holds 90 BNB and 22,000 tokens. If BNB is $600 and the token is $2, the reserve-based estimate moves from $100,000 to $98,000: before, $60,000 + $40,000; after, $54,000 + $44,000. These are illustrative figures. If the displayed estimate stays at $100,000, check whether it is pinned to the earlier block, uses a delayed price feed, or covers other pools too.
A read-only RPC call does not spend gas, though providers may rate-limit requests. For repeated checks, query by block tag where supported and retain the block number with each result. That makes comparisons reproducible and avoids mistaking a new block’s state for the exact post-transaction state.
Why can two liquidity estimates disagree?
First establish what each estimate includes. A token-wide total may aggregate several pairs, while a pool estimate covers one pair; a charting service may also value reserves using a different price source or refresh cadence. PooCoin’s price charts can help compare a token’s market move with the interval you are investigating, but a chart price is not proof that a particular pair’s reserves refreshed.
There are contract-level edge cases. A direct token transfer to a pair can change its balance without changing its stored reserves until a later sync; rebasing or fee-on-transfer tokens can also make balance deltas diverge from expected swap amounts. Concentrated-liquidity pools add another complication: active liquidity varies by price tick, so multiplying token balances by spot prices does not describe executable depth across a large trade. Compare like with like: stored reserves for a reserve estimate, or tick-level liquidity and a specified trade size for depth.
Use the estimate whose pool scope, block, valuation source, and refresh delay you can verify; if any of those are unknown, treat the number as indicative rather than current.