How to measure buy/sell pressure on a DEX pool

Buy/sell pressure on a DEX pool is the split of recent trading flow between buys and sells, and you can read it straight from DexPaprika's pool endpoint. GET /networks/{chain}/pools/{address} returns buys, sells, buy_usd, and sell_usd for six timeframes (5m, 15m, 30m, 1h, 6h, 24h) in a single call. Two ratios do the measuring: buy share of USD volume (buy_usd / (buy_usd + sell_usd)) and buy share of trade count. When those two disagree, that disagreement is usually the most interesting number on the screen.

What pressure tells you that price doesn't

Price is the outcome; pressure is the composition of the flow that produced it. A token grinding sideways on 70% buy-side USD volume is being absorbed by someone selling into every bid, which is a very different situation from sideways-on-balanced-flow, and the chart alone won't tell you which one you're looking at. Pressure is also the context you want around any single price reading (we covered what a "live price" actually is in what real-time crypto prices actually mean).

One expectation to calibrate before you measure anything: on big, liquid pools, USD flow is almost perfectly balanced almost all the time, because arbitrage bots close any gap between the pool and the wider market within blocks. The skew you're hunting for lives on smaller pools, newer tokens, and shorter windows.

One call gets all the raw material

curl "https://api.dexpaprika.com/networks/ethereum/pools/0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640"

That's the largest USDC/WETH pool on Ethereum. Trimmed to the flow fields (this is the live response from when I wrote this, values rounded):

{
  "dex_name": "Uniswap V3",
  "liquidity_usd": 86150528.57,
  "24h": {
    "volume_usd": 54721834.06,
    "buy_usd": 27367718.52,
    "sell_usd": 27354115.54,
    "buys": 2295,
    "sells": 2394,
    "txns": 4690
  },
  "1h": {
    "volume_usd": 1539961.50,
    "buy_usd": 770033.54,
    "sell_usd": 769927.96,
    "buys": 100,
    "sells": 106
  }
}

Look at what this pool just demonstrated. Over 24 hours, buy and sell USD volume match to within 0.05% ($27.368M vs $27.354M): that's the arbitrage balance from the previous section, live. But the counts lean the other way, 2,295 buys against 2,394 sells. More sells, smaller sells; fewer buys, bigger buys. Even on the most boring pool in DeFi, the two ratios carry different information.

The two ratios, computed

import requests

pool = "0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640"
d = requests.get(f"https://api.dexpaprika.com/networks/ethereum/pools/{pool}").json()

for tf in ("5m", "30m", "1h", "6h", "24h"):
    w = d[tf]
    total_usd = (w.get("buy_usd") or 0) + (w.get("sell_usd") or 0)
    total_cnt = (w.get("buys") or 0) + (w.get("sells") or 0)
    if not total_usd or not total_cnt:
        print(f"{tf:>4}: no flow in this window")
        continue
    usd = w["buy_usd"] / total_usd * 100
    cnt = w["buys"] / total_cnt * 100
    print(f"{tf:>4}: buys = {usd:5.1f}% of USD volume, {cnt:5.1f}% of trades")

Reading the two together:

• USD share high, count share low: few wallets buying big while many sell small. On a fresh token this pattern is worth respect; it's what accumulation looks like.
• Count share high, USD share low: lots of small buys against large sells. This is the classic distribution-into-hype shape, and it's also what a token looks like while a large holder exits into retail flow.
• Both near 50% on a liquid pool: normal. Don't invent a signal where arbitrage is just doing its job.

The timeframes ladder into a momentum read for free: if the 5m and 30m buy share sit well above the 24h baseline, pressure is building now; if the short windows collapse below a strong 24h number, the move is already exhausting. One response carries the whole ladder, so this costs you a single request per pool.

Counts are not wallets (the honest caveat)

buys and sells are transaction counts. Five hundred buys can be five hundred people or one bot on a loop, and the pressure math can't tell the difference. If you need to know how many distinct wallets are behind the flow, the pool transactions endpoint returns individual swaps with sender and recipient addresses you can dedupe. Treat even that as an approximation: on Ethereum the sender is frequently a router or aggregator contract acting for many users, so a naive dedupe undercounts real traders. Distinct-wallet counting done properly is its own topic; for a pressure signal, the count/USD divergence above usually carries you far enough.

For screeners and agents: where the split lives

One practical gotcha if you're building a scanner or wiring this into an AI agent: the buy/sell split lives on the *detail* endpoints (pool details, token details), not on the pool *list* endpoints. So the efficient workflow is filter first, then drill: use search or the list endpoints to shortlist pools by volume or liquidity, then make one detail call per candidate for the pressure fields. An agent that expects the split in list responses will conclude the data doesn't exist, and an agent that detail-calls everything will burn its budget; shortlist-then-drill avoids both. If you're connecting this through MCP, the agents hub has the setup, and we've written about how agents use market data tools in general.

FAQ

Key takeaways

• One call returns the full buy/sell split across six timeframes; the two ratios (USD share, count share) come from four fields.
• The divergence between USD share and count share is the signal: accumulation and distribution have opposite signatures that a single ratio misses.
• Expect ~50/50 USD flow on liquid pools; arbitrage makes balance the default, which is precisely why sustained skew means something.
• Counts measure transactions, not people. Dedupe senders from the transactions endpoint if you need wallets, and mind the router-contract undercount.
• Screeners should shortlist from list endpoints, then fetch details per candidate; the split only exists on detail responses.

Where to go next

• Pool details reference and pool transactions reference
• Token details reference for token-level flow across all pools
• DexPaprika agents hub to run these reads from an AI agent
• CoinPaprika API docs for the exchange-side view of the same assets