How to Build a Reliable Cross-DEX Price Scanner in 4 Steps

The same token rarely trades at the same price on every pool. A meme coin might sit on three or four pools across different DEXs (decentralized exchanges) at once, each with its own depth and its own buyers, and the price on a thin pool can drift well away from where the token actually trades in size. A cross-DEX price scanner exists to catch that drift before you act on it, whether you are routing an order to the best pool or just confirming a price is real before you trust it.

This guide builds that price scanner on Solana with Birdeye Data. It works as a price intelligence layer rather than an automated arbitrage bot, one that tells you where a token is priced correctly across its pools and where it has drifted. What you do with that information, whether that is choosing where to route an order or just refusing to trust a stale quote, stays your call.

Cross-DEX Price Scanner in 4 Steps

Here is the whole pipeline in plain terms, so you can follow it even without reading the rest of the guide.

1. List every pool a token trades on. Pull the token’s markets ranked by liquidity, so you start from the venues that can actually fill a trade rather than every dust pool.
2. Price each pool in the same currency. Each pool reports its own price in its own quote token, so normalize every pool to a USD figure before you compare them.
3. Anchor against a consolidated price. Compare each pool’s USD price against Birdeye Data’s consolidated mark, so you can tell a genuinely mispriced pool from one that is simply stale.
4. Confirm the gap holds. Check that a flagged spread persists across several candles, so you act on a real dislocation instead of one thin, low-volume tick.

Every endpoint below runs on a Premium plan over standard REST (representational state transfer) calls, and pair-level pricing is Solana only, so this price scanner targets Solana.

List Up to 20 Pools by Liquidity

A token can sit on a single deep pool or be scattered across a dozen thin ones, and you need to know which before you price anything. The first call resolves the token into the pools actually worth watching.

Endpoint: GET /defi/v2/markets

Chains: All chains

Plan availability: Starter plan and higher, so it runs on Premium

Docs: Token Market List

This endpoint lists every pool a token trades on, ranked by the field you choose.

Parameter	In	Required	Notes
address	query	yes	the token address, not the pool
sort_by	query	yes	liquidity or volume24h
sort_type	query	no	desc (default) or asc
offset	query	no	pagination start, default 0
limit	query	no	up to 20 (default 10)
x-chain	header	no	defaults to solana, accepts any supported chain

Sort by liquidity to find the pools deep enough to actually fill a trade. Each item’s own address is the pool, not the token, which is the value you carry into the next stage; the venue name sits in source, and base/quote tell you which token is priced against which.

curl -s "<https://public-api.birdeye.so/defi/v2/markets?address=TOKEN_ADDRESS&sort_by=liquidity&sort_type=desc&limit=20>" \
  -H "X-API-KEY: YOUR_API_KEY" \
  -H "x-chain: solana"

Each item also carries a price field, but it commonly comes back null, so do not treat it as the price source. Cap your watchlist to the top few pools by liquidity, both to bound the per-pool calls in the next stage and because a pool with negligible depth is not worth pricing in the first place.

A practical starting rule: price the top two or three pools by liquidity and stop there. A fourth or fifth pool rarely changes the spread you care about, since by that point liquidity has usually dropped enough that the pool could not absorb a meaningful trade anyway, and every extra pool the price scanner watches is another call and another credit spent on a venue unlikely to move the result.

You now have a ranked list of real venues for the token. The next stage prices each one in a currency you can actually compare.

Normalize Every Pool to a USD Price

A pool quoted in SOL and a pool quoted in USDC can show wildly different numbers for the exact same token, and comparing them directly produces nonsense. This stage prices every pool in dollars before any comparison happens.

Endpoint: GET /defi/v3/pair/overview/single

Chains: Solana

Plan availability: Starter plan and higher, so it runs on Premium

Docs: Pair Overview Single

This endpoint returns one pool’s own price and depth, called once per pool from the list in stage one.

Parameter	In	Required	Notes
address	query	yes	the pool address from stage one, not the token
x-chain	header	no	defaults to solana, only chain this endpoint supports

There is no multi-pool version of this call on a Premium plan, since the batched variant is reserved for the Business package and higher, so plan on one call per pool you are watching.

curl -s "<https://public-api.birdeye.so/defi/v3/pair/overview/single?address=POOL_ADDRESS>" \
  -H "X-API-KEY: YOUR_API_KEY" \
  -H "x-chain: solana"

The response carries price, liquidity, source, base, quote, and volume and trade stats from 30 minutes out to 24 hours. The detail that decides whether your spread math is correct: price is the base token priced in the quote token, not a dollar figure. A live pull on a BULLCAT-SOL pool returned a price of 7.35 × 10⁻⁶, and dividing that pool’s volume_24h_quote by its volume_24h_base, 47,646 SOL over roughly 9.41 billion BULLCAT, lands on the same order of magnitude, confirming the unit is SOL per BULLCAT rather than dollars. To get a comparable figure, multiply price by the quote token’s own USD price, inverting first if the token you are tracking sits in quote rather than base. volume_24h on this endpoint is already in USD, so use it directly for liquidity weighting.

With every pool now priced in the same currency, the spread between the cheapest and richest pool is a real number, computed as the difference divided by the lowest price, weighted by each pool’s liquidity so a thin pool’s outlier quote does not dominate the result. As a concrete shape for that weighting: if a $400,000 pool prices a token at $0.00050 and a $20,000 pool prices it at $0.00046, the raw spread is about 8.7 percent, but the deep pool should carry roughly 20 times the weight of the thin one when you decide which price to trust, since it represents 20 times the liquidity backing that quote.

Anchor Against One Consolidated Price

A wide spread between two pools tells you they disagree, but not which one is wrong. This stage adds a third reference point so you can tell a genuinely mispriced pool from one that is simply behind.

Endpoint: GET /defi/price

Chains: All chains

Plan availability: Standard plan and higher, so it runs on Premium

Docs: Price

This endpoint returns Birdeye Data’s consolidated USD price for a token, built from trading activity across every pool rather than any single venue. It is the reference figure your price scanner needs in order to judge a pool against something other than another pool’s possibly wrong quote.

Parameter	In	Required	Notes
address	query	yes	the token address
check_liquidity	query	no	minimum liquidity a pool must clear to count toward the price
include_liquidity	query	no	true or false, adds liquidity to the response
ui_amount_mode	query	no	raw (default), scaled, or both, Solana only
x-chain	header	no	defaults to solana, accepts any supported chain

Set include_liquidity=true so you get a depth figure alongside the price in the same call. Use check_liquidity to exclude pools too thin to be trusted from the consolidated figure if your token has a long tail of dust pools.

curl -s "<https://public-api.birdeye.so/defi/price?address=TOKEN_ADDRESS&include_liquidity=true>" \
  -H "X-API-KEY: YOUR_API_KEY" \
  -H "x-chain: solana"

Measure each pool’s percent deviation from this consolidated price rather than from whichever pool happens to look cheapest. A pool sitting close to the consolidated mark is reading correctly even if it disagrees with one outlier; a pool sitting far from it, especially a thin one, is the pool actually worth flagging. The response can come back null or missing data for a token Birdeye Data does not yet track, so guard for that before treating a missing price as zero.

You now have a fair value mark and a deviation reading for every pool. The final stage checks whether that deviation is real.

Confirm a Spread Across Up to 5,000 Candles

A pool can look mispriced for one ugly tick and then snap back a minute later. Before you act on a flagged spread, confirm it survives more than a single candle.

Endpoint: GET /defi/v3/ohlcv/pair

Chains: Solana, Base, BSC, and Ethereum

Plan availability: Starter plan and higher, so it runs on Premium

Docs: OHLCV V3 Pair

This endpoint returns OHLCV (open, high, low, close, volume) candles for a single pool over a time range you choose.

Parameter	In	Required	Notes
address	query	yes	the pool address, not the token
type	query	yes	the candle interval, such as 15m
time_from	query	yes	unix timestamp in seconds, range start
time_to	query	yes	unix timestamp in seconds, range end
count_limit	query	no	up to 5,000 candles per call
padding	query	no	false (default), fills gaps with empty candles when true
inversion	query	no	true flips base and quote, default false
x-chain	header	no	defaults to solana, also accepts base, bsc, ethereum

Pull the most recent candles for the flagged pool at a short interval, such as 15m, and check whether the price gap from stage three persists across several of them rather than showing up in just one. Use inversion if you need the candle priced the opposite way around from how the pool naturally quotes it, which can make it easier to line up against the other pools you are comparing.

A shorter interval such as 5m confirms the gap faster but needs more candles to cover the same window, while 1h covers more ground per candle at the cost of reaction speed. To confirm a flagged spread within the hour, 15m is usually the right middle ground, since it gives four readings inside an hour without drowning the check in noise from very short term ticks.

curl -s "<https://public-api.birdeye.so/defi/v3/ohlcv/pair?address=POOL_ADDRESS&type=15m&time_from=1755000000&time_to=1755058900>" \
  -H "X-API-KEY: YOUR_API_KEY" \
  -H "x-chain: solana"

Each candle carries o, h, l, c, v (base volume), v_usd, and unix_time. Treat a candle with v and v_usd near zero as untradable rather than confirming evidence, since a flat, low-volume print is the most common source of a spread that looks real but is not.

That closes the loop. A pool that disagreed with the rest of the market on one tick has either confirmed itself as genuinely mispriced or quietly corrected, and you know which before you act.

Trace One Token Through All 4 Stages

The field names above stay abstract until you attach numbers to them. Here is an illustrative run through the price scanner’s four stages.

Suppose stage one returns three pools for a token, with liquidity of $180,000, $42,000, and $9,000. The first two are worth pricing; the third is thin enough to skip.

Stage two prices both pools in their native quote terms and normalizes each to USD. The deep pool comes back at $0.00041 per token, while the thinner pool comes back at $0.00038, a spread of roughly 8 percent weighted toward the deep pool’s price, since it carries far more liquidity.

Stage three pulls the consolidated price and finds it sitting at $0.000408, close to the deep pool and meaningfully above the thinner one. That points to the thin pool as the one that has actually drifted, not the deep pool.

Stage four pulls recent 15 minute candles on the thin pool and finds three in a row near that same $0.00038 level, each with real volume rather than a single dust trade. The gap is confirmed, not a stale tick, so the thin pool is genuinely trading away from fair value rather than just slow to update.

Track Your Credit Usage

Pricing several pools per token across a watchlist adds up in API credits faster than a single token check does. Confirm your consumption with a single call so a wide watchlist does not surprise you.

curl -s "<https://public-api.birdeye.so/utils/v1/credits>" \
  -H "X-API-KEY: YOUR_API_KEY"

Use the result to tune how many pools per token you price and how often you refresh, so coverage and cost stay in balance. A watchlist of ten tokens at two pools each and a fifteen minute refresh costs meaningfully less than the same list refreshed every few seconds, so size the refresh interval to how fast the tokens you track actually move rather than defaulting to the tightest loop you can afford.

Putting It Together: Reference Architecture

The four stages chain into a funnel that turns a token address into a confirmed, comparable spread.

Use this checklist before you ship:

• Sort the market list by liquidity and drop pools too thin to fill a real trade.
• Treat price on the pair overview endpoint as base-in-quote, never as USD, until you convert it.
• Measure deviation against the consolidated price from /defi/price, not against whichever pool looks cheapest.
• Confirm a flagged spread across several candles before treating it as real.
• Discard a candle with v and v_usd near zero as noise, not confirmation.
• Watch your credit usage as you widen the watchlist or shorten the refresh interval.

Frequently Asked Questions

Is this an arbitrage bot?

No. The price scanner is a price intelligence layer that tells you where a token is priced correctly and where it has drifted, which is the input an arbitrage system would need, not the system itself. Real arbitrage on Solana is contested by fast automated traders, so treat this as a way to find the best price to trade at and to catch genuinely stale quotes, not as a guaranteed profit source.

What if a token only trades on one pool?

The price scanner still runs, it just has nothing to compare against. With a single pool there is no spread to compute in stage two, so lean more heavily on stage three: compare that pool’s price against the consolidated mark from /defi/price to catch a pool that has drifted from fair value even without a second venue to triangulate against.

Why is the price field on the pair overview endpoint not in USD?

A pool only knows the ratio between its two tokens, so price reports the base token in terms of the quote token, whatever that quote happens to be. Multiply by the quote token’s own USD price to get a comparable figure, and invert first if the token you care about sits in quote rather than base.

Which chain does this price scanner run on?

The pair-level pricing and pool listing endpoints are Solana only, so this price scanner targets Solana. The consolidated price endpoint in stage three supports other chains as well, if you need that reference elsewhere.

How many pools should one price scanner watch per token?

Two or three of the deepest pools usually capture the spread that matters, since a pool too thin to move meaningful size is not worth comparing against in the first place. Watching every pool a token has ever traded on mostly adds noise and credit cost without adding a signal worth acting on.

What counts as confirmation that a spread is real?

A gap that holds across several recent candles, each with real trading volume rather than a single thin print. A spread that shows up on one candle and vanishes on the next is usually a stale or low-liquidity tick, not a genuine mispricing.

How often should the price scanner refresh?

Match the refresh interval to how fast the token trades and to your credit budget. A slow, low-volume token needs refreshing far less often than an active one, and the credits endpoint lets you confirm the cost of a given interval before committing to it.

---

Ready to build your cross-DEX price scanner? Start with the Birdeye Data API and the full endpoint reference at docs.birdeye.so. For background on the network these pools trade on, see the Solana documentation.