The Meteora DLMM API: real-time bin-level liquidity data for Solana's top DEX

DLMM stands for Dynamic Liquidity Market Maker. Instead of pricing liquidity along a smooth curve (Raydium AMM v4) or as continuous ranges (CLMM), DLMM splits the price axis into discrete bins. Each bin is a small price band that holds its own X / Y reserves. A swap walks bins from the active one outward until the input is filled, at deterministic prices. It feels like an order book and settles like an AMM. That hybrid is the whole reason it took off in 2025.

On chain, four account types do all the work. LbPair holds the pair config: base mint, quote mint, bin step, active bin id, fees. BinArray accounts each store 70 contiguous bins of liquidity; a busy pool spans many of them. Position and PositionV2 represent individual LP entries with a tick range and per-bin liquidity. Oracle stores the price-history ring buffer for TWAPs.

Subscribing to “Meteora data” means watching three things. Instruction calls into the DLMM program (swaps, deposits, withdrawals, claims). Account writes to LbPair (active bin shifts). And account writes to specific BinArrays you care about (granular liquidity distribution). All three drop into one feed if you set it up right.

The official Meteora API at dlmm-api.meteora.ag is REST. Seven main endpoints: pool list, pool detail, OHLCV history, swap volume, fee accruals, group listings, and protocol-wide metrics. The hard limits: 30 requests per second, polling-only, aggregates updated on a 5 to 30 second cadence behind the chain.

That's genuinely fine for an analytics dashboard refreshing every 30 seconds, or a backfill job pulling pool history into a notebook. We'd use it ourselves for either.

What it doesn't do: catch new pool launches as they happen. Tell an LP rebalancer that the active bin just moved out of its range. Power a sniper that needs to sit in the slot after a token migrates into DLMM. Anything where freshness matters in seconds, not in the next polling cycle, has to subscribe to the program directly.

The single most important field for monitoring a DLMM pool live is the LbPair's active_id: the integer id of the bin currently inside the spread. Every swap that crosses a bin boundary increments or decrements it. Subscribing to LbPair account writes (rather than only transactions) gives you a tight signal that price moved with no decoder overhead. The active_id sits at a fixed byte offset.

For deeper analytics, per-bin liquidity, slippage estimates, execution-price prediction, you also need the surrounding BinArray accounts. A typical SOL/USDC DLMM pool spans dozens of them. Our parsed stream flags which BinArrays were touched by each swap, so your decoder refreshes its cached liquidity map only for the ones that changed instead of polling the whole program every block.

Bin step is the other key parameter. It defines the geometric ratio between adjacent bin prices. A 100-bps bin step means each bin is 1% wider than the previous one. Bin step is set at pool creation and emitted in the initialize_lb_pair instruction, which is useful for sniper bots that filter for tighter (low-slippage) or looser (memecoin-volatile) pools at launch.

The Meteora DLMM data market splits cleanly. Official REST is free but rate-limited. Bitquery sells GraphQL access; if you want JOINed historical analytics across DEXes they're genuinely better at that than we are. Direct on-chain subscription via Yellowstone gRPC is the only real-time option. Bitquery shines for post-hoc work; we shine for real-time decisioning and predictable pricing.

We charge flat. Pro ($49/month) gives you two parsed streams. DLMM is one option among ten-plus DEXes and program families. Ultra ($199/month) bumps that to twenty plus 30 hours of custom dev time per month. No per-event surcharges, no DLMM-specific add-ons. Full breakdown is on the pricing page.