Solana Liquidity Monitoring: 4 Proven Build Steps

Solana liquidity monitoring is the difference between watching a pool drain as it happens and finding out after your exit is already gone. Liquidity is what lets a holder actually sell, so when it leaves a pool, everyone behind it is trapped, and the first warning is the liquidity curve, not the price. This guide shows you how to build a Solana liquidity monitoring tool using Birdeye Data, which resolves a token to its deepest pool, streams that pool’s liquidity as OHLC (open, high, low, close) candles, aligns the series against price, and ties any collapse to security and supply data.

Birdeye Data covers four checks here: resolving a token to its deepest pool, pulling that pool’s liquidity history minute by minute, aligning the liquidity series against price, and explaining a drop with on chain security and supply data. One detail runs through all four and trips up most first integrations. The address parameter means the token on some endpoints and the pool on others, so passing the wrong one returns the wrong data with no obvious error.

Direct Answer: Build a Solana Liquidity Monitoring Tool in 4 Steps

A Solana liquidity monitoring tool is four REST calls, each watching a different angle of the same pool.

1. Resolve the token to its deepest pool with GET /defi/v2/markets, where address is the token and each result’s address is a pool.
2. Pull the pool’s liquidity history with GET /defi/v3/liquidity/ohlc/pair, where address is now the pool, returning liquidity as OHLC candles.
3. Align price against liquidity with GET /defi/v3/ohlcv, where address is the token again.
4. Explain a collapse with GET /defi/token_security and GET /defi/v3/token/mint-burn-txs, both keyed by the token.

Every call uses the base URL https://public-api.birdeye.so with an X-API-KEY header and x-chain: solana. Watch the address parameter as you move between calls, because it flips between token and pool, which is the single most common mistake in this pipeline. The rest of this guide expands each step with parameters, a working request, and the exact response fields to read.

Step 1: Resolve the Token to Its Deepest Pool

A token rarely lives in one pool. It trades across many, and most of them are too shallow to matter, so the first job is to find the one pool that actually holds the liquidity and monitor that. Monitoring a shallow pool wastes calls and misses the real action, since the liquidity that can be pulled sits in the deepest one. The markets call lists a token’s pools and lets you sort them, so the deepest one rises to the top.

Endpoint: GET /defi/v2/markets

Chains: All chains (use Solana here)

Plan availability: All paid plans (Lite, Starter, Premium, Business, Enterprise)

Docs: Birdeye Data reference

Parameter	Required	Description
x-chain	yes (header)	Chain, set to solana
address	yes	The TOKEN mint to find pools for
sort_by	yes	liquidity or volume24h
sort_type	yes	desc or asc
limit	no	Pools per page, max 20
offset	no	Pagination offset

Sort by liquidity with sort_type=desc and the deepest pool is the first item. The response is data.items[] plus a total count, and each item describes one pool: its own address, a base and a quote object holding the two token mints, the pool liquidity in USD, volume24h, and a source naming the venue. Read the first item’s liquidity to confirm the pool is worth watching before you commit to it.

A token can list more than a thousand pools, which the total count makes plain, so sorting is not optional. The source field names the venue behind each pool, such as a stake pool or an automated market maker, which helps you decide whether the deepest pool is the one to track or an edge case to skip.

curl --request GET \
  --url '<https://public-api.birdeye.so/defi/v2/markets?address=TOKEN_MINT&sort_by=liquidity&sort_type=desc&limit=20>' \
  --header 'X-API-KEY: YOUR_API_KEY' \
  --header 'x-chain: solana'

The trap is the address you carry forward. The item’s address is the pool, not the token, so that pool address is what the next call needs. Keep using the token mint in Step 2 and the liquidity history comes back empty, because the history endpoint is keyed by pool. Grab the pool address from the top item and hold onto it.

Step 2: Pull the Liquidity Time Series for the Pool

With the pool address in hand, you can watch its liquidity move. This call returns liquidity as OHLC candles, minute by minute, so a slow bleed and a one block rug both show up as a shape on a chart rather than a single number. Each candle also carries the raw pool balances, which is what turns a falling line into a clear withdrawal.

Endpoint: GET /defi/v3/liquidity/ohlc/pair

Chains: Solana

Plan availability: All paid plans (Lite, Starter, Premium, Business, Enterprise)

Docs: Birdeye Data reference

Parameter	Required	Description
x-chain	yes (header)	Chain, set to solana
address	yes	The PAIR (pool) address from Step 1
time	no	Unix anchor for the page
direction	no	back or forward from time
count	no	Candles per call, max 100

The address here is the pool, not the token, which is the flip side of the Step 1 trap. The liquidity values you plot are open_liquidity_usd, high_liquidity_usd, low_liquidity_usd, and close_liquidity_usd. There is no single liquidity_usd field, so guessing that name returns undefined and a flat chart. Plot the four OHLC fields as your liquidity series.

curl --request GET \
  --url '<https://public-api.birdeye.so/defi/v3/liquidity/ohlc/pair?address=PAIR_ADDRESS&count=100>' \
  --header 'X-API-KEY: YOUR_API_KEY' \
  --header 'x-chain: solana'

To see the withdrawal itself, read the balance fields on each candle. open_base_balance through close_base_balance and the matching quote fields hold the raw token amounts in the pool, with normalized versions under open_base_amount_ui and the rest. When close_liquidity_usd falls and the base or quote balance drops with it, liquidity is being pulled, not just repriced. One call returns at most 100 candles, so for a longer window page with next_cursor and prev_cursor, which are unix timestamps, and stop when has_more is false.

Reading balances also separates a real drain from a price effect. Liquidity in USD can fall just because the token’s price fell, even though no tokens left the pool. When the base and quote balances hold steady while close_liquidity_usd drops, that is a reprice, not a withdrawal. When the balances fall with it, tokens actually left the pool.

A falling liquidity line on its own is ambiguous, though. It could be a withdrawal, or it could be the whole market moving. To read it, you put price beside it.

Step 3: Align Liquidity Against Token Price

The signal that matters is divergence. Liquidity falling while price falls with it can be ordinary selling, but liquidity vanishing while price holds, or dropping far faster than price, is the shape of a pull. To see that, overlay the token’s price candles on the liquidity series from Step 2.

Endpoint: GET /defi/v3/ohlcv

Chains: Solana, Base, BSC, Ethereum

Plan availability: All paid plans (Lite, Starter, Premium, Business, Enterprise)

Docs: Birdeye Data reference

Parameter	Required	Description
x-chain	yes (header)	Chain, set to solana
address	yes	The TOKEN mint, not the pool
type	yes	Candle interval, such as 15m or 1m
time_from	yes	Unix start of the range
time_to	yes	Unix end of the range
count_limit	no	Maximum candles, up to 5000

The address flips back to the token here, since price belongs to the token while liquidity belonged to the pool. The price candles use short field names, o, h, l, c, and v, plus v_usd for volume in USD and unix_time for the timestamp. That naming is the catch when you overlay the two series. The liquidity candles from Step 2 use long names like close_liquidity_usd, while the price candles use c, so join the two on unix_time rather than assuming a shared field shape.

curl --request GET \
  --url '<https://public-api.birdeye.so/defi/v3/ohlcv?address=TOKEN_MINT&type=15m&time_from=1726670000&time_to=1726675000>' \
  --header 'X-API-KEY: YOUR_API_KEY' \
  --header 'x-chain: solana'

Line the price c up against the liquidity close_liquidity_usd on the same timeline and the abnormal events stand out. A candle where liquidity craters but price barely moves is the one to alert on. In practice you set a threshold on the ratio: flag any candle where close_liquidity_usd drops past a percent you choose while price moves less than a smaller percent over the same unix_time. Tune the two numbers to your tolerance for false alarms. When that fires, the next question is why, and the last step answers it.

Step 4: Explain a Collapse with Security and Supply Data

An alert tells you liquidity left. It does not tell you whether the token was a trap from the start or whether someone inflated supply on the way out. Two calls cover that. The security call reads the token’s authorities and concentration, and the mint and burn call reads the supply events behind a stealth mint or a fake burn.

Endpoint: GET /defi/token_security and GET /defi/v3/token/mint-burn-txs

Chains: token_security on all chains except Sui, mint-burn-txs on Solana only

Plan availability: All paid plans (Lite, Starter, Premium, Business, Enterprise)

Docs: token_security, mint-burn-txs

Start with token_security. On Solana it returns the authorities and concentration that define a token’s risk: ownerAddress for the mint authority, freezeAuthority with freezeable, mutableMetadata for whether metadata can still change, isToken2022 with transferFeeData for transfer fee risk, top10HolderPercent for concentration, and creatorPercentage for the creator’s stake.

Parameter	Required	Description
x-chain	yes (header)	Chain, set to solana (this decides the schema)
address	yes	The TOKEN mint

There is no mintable boolean on Solana, so you read mintability from ownerAddress. A null ownerAddress means the mint authority has been renounced, so no new supply can be minted, while a present address means it can. Two things will catch you. Most fields in this response are nullable, so null check every one before you display it, and the Solana schema is not the same as the EVM schema, where you would instead look at honeypot and tax fields. Read the wrong field for the chain and you score a token on data that is not there.

Each field maps to a question you can score. A live ownerAddress means supply can still be minted, a present freezeAuthority means accounts can be frozen, mutableMetadata of true means the name and image can still change, and a high top10HolderPercent means a handful of wallets can move the market. None of these is a verdict on its own, but together they turn a raw security object into a risk score you attach to the alert.

curl --request GET \
  --url '<https://public-api.birdeye.so/defi/token_security?address=TOKEN_MINT>' \
  --header 'X-API-KEY: YOUR_API_KEY' \
  --header 'x-chain: solana'

Now add mint-burn-txs for the supply events. It lists mint and burn transactions so you can catch a stealth mint that diluted holders or a fake burn that was announced but never moved real supply.

Parameter	Required	Description
x-chain	yes (header)	Chain, set to solana
address	yes	The TOKEN mint
type	yes	all, mint, or burn
sort_by	yes	block_time
sort_type	yes	desc or asc
limit	no	Rows per call, max 100

Each row reports its direction in common_type, which reads mint or burn, with ui_amount for the normalized size and block_time for the unix timestamp. The raw amount is a string, so display ui_amount instead and you avoid a value off by the token’s decimals. Cross the timing of a large mint against the liquidity drop from Step 2, and a stealth dilution lines up with the moment liquidity left. A fake burn shows the opposite tell, where a burn that was announced has no matching burn row in the window, or a ui_amount far smaller than the claim, which means the supply never actually moved.

curl --request GET \
  --url '<https://public-api.birdeye.so/defi/v3/token/mint-burn-txs?address=TOKEN_MINT&sort_by=block_time&sort_type=desc&type=all&limit=100>' \
  --header 'X-API-KEY: YOUR_API_KEY' \
  --header 'x-chain: solana'

With security and supply context attached to an alert, the tool does more than flag a drop. It explains one.

Track API Credit Usage as You Scale

Liquidity monitoring polls, and a tool that watches many pools at once can run up calls fast. Birdeye Data exposes a credits endpoint so you can read your own consumption directly and set your polling cadence against the real number rather than guessing.

Endpoint: GET /utils/v1/credits

curl --request GET \
  --url '<https://public-api.birdeye.so/utils/v1/credits>' \
  --header 'X-API-KEY: YOUR_API_KEY'

A practical pattern is to poll the liquidity history for your watched pools on a tight loop, refresh price on the same cadence so the two series stay aligned, and call the security and supply endpoints only when an alert fires rather than on every cycle. Watch the credits endpoint as you add pools, and let that number set how many you can watch at once. Because the security and supply calls run only on alerts, the steady cost is just the two watch loops per pool, which keeps a wide watchlist affordable.

Putting It Together: Reference Architecture

The pipeline is a funnel that narrows from a token to a single pool, then watches that pool on two synced loops, and pulls context only on an alert. Resolve runs once when you add a token. The two watch loops run continuously and feed a single aligned series. The context calls sit behind the alert gate, so they cost nothing until something actually breaks.

Use this checklist before you ship:

• Every call sends x-chain: solana and an X-API-KEY.
• address is the token for markets, ohlcv, token_security, and mint-burn-txs, and the pool for liquidity/ohlc/pair.
• The liquidity series is plotted from open_liquidity_usd through close_liquidity_usd, not a liquidity_usd field.
• Liquidity and price candles are joined on unix_time, since their field names differ.
• token_security fields are null checked, and mintability is read from ownerAddress.
• Security and supply calls fire only on an alert, with credits monitored as pools are added.

Frequently Asked Questions

What is Solana liquidity monitoring?

It is watching the liquidity in a token’s pool over time to catch a drain before it traps holders. A Solana liquidity monitoring tool resolves a token to its deepest pool, charts that pool’s liquidity as OHLC candles, aligns it against price, and ties any collapse to security and supply data so a drop can be explained, not just spotted.

Why does the address parameter mean different things on different endpoints?

Liquidity belongs to a pool, while price, security, and supply belong to a token. So liquidity/ohlc/pair takes the pool address, while markets, ohlcv, token_security, and mint-burn-txs take the token mint. Carrying the wrong one between calls is the most common mistake in this pipeline.

Which field holds the pool’s liquidity value?

The liquidity OHLC candles expose open_liquidity_usd, high_liquidity_usd, low_liquidity_usd, and close_liquidity_usd. There is no single liquidity_usd field, so plot the four OHLC fields as the liquidity series.

How do I tell a rug from normal selling?

By the divergence between liquidity and price. Liquidity falling alongside price is ordinary selling, while liquidity vanishing as price holds, or dropping far faster than price, is the shape of a pull. The balance fields on each liquidity candle confirm whether tokens actually left the pool.

Does token_security return the same fields on Solana and EVM?

No. The x-chain header decides the schema. Solana returns authority and concentration fields like ownerAddress and top10HolderPercent and has no mintable boolean, so you derive mintability from ownerAddress. EVM chains return a different set, including honeypot and tax fields.

Which plans can call these endpoints?

All paid plans, from Lite through Enterprise, per the accessibility listing on each endpoint reference page.

How far back does the liquidity history go?

Each liquidity/ohlc/pair call returns up to 100 candles. For a longer history, page with next_cursor and prev_cursor, which are unix timestamps, and keep going while has_more is true, stitching the pages into one continuous series.

---

You now have every layer of a Solana liquidity monitoring tool, the pool resolver, the liquidity time series, the price overlay, and the security and supply context, all over REST. Grab an API key from Birdeye Data, resolve a token to its deepest pool, and add each step until the full surveillance view is live.