Meteora volume bot: bins, dynamic fees and what they cost

Meteora DLMM does not hold liquidity in a smooth curve. It holds it in discrete bins, each at a fixed price, and a trade walks through as many bins as it needs. That single design choice changes how a volume campaign behaves: slippage arrives in steps rather than gradually, and the pool fee is not a constant. If you size trades on constant-product intuition, Meteora will quietly charge you for the mismatch.

Volion Research Updated Jul 30, 2026 5 sections

Liquidity bins, not a curve

A DLMM pool splits the price range into discrete bins. Each bin holds liquidity at one price, and trades execute against the active bin until it is exhausted, then move to the next. Inside a bin there is zero slippage. Crossing bins is where price moves, so slippage on Meteora is a step function rather than a smooth curve.

For a campaign, this has a specific consequence. A trade that fits inside the active bin executes at a single price with no impact at all, which is ideal. A trade slightly larger crosses into the next bin and moves price by the bin step. The difference between those two outcomes is not proportional to trade size, so the usual habit of picking a size and assuming slippage scales with it does not hold.

Practically, this rewards smaller and more numerous trades on Meteora more than it does on a constant-product pool. It also means the price action a campaign produces is discontinuous by design, and a chart that steps rather than drifts is a property of the venue rather than a sign of anything unusual.

The pool fee is not a constant

Meteora DLMM applies a base fee plus a variable component that rises when price is moving across bins quickly. Sustained one-directional pressure therefore raises the fee your own subsequent trades pay. A campaign that pushes hard in one direction is increasing its own cost as it runs.

This is the most important practical difference between Meteora and a fixed-fee pool, and it is invisible in a quote that lists a single percentage. Two campaigns with identical settings can pay different pool fees on Meteora depending on how they paced themselves, because pacing determines volatility and volatility feeds the fee.

The tuning that follows is straightforward. Balance the buy and sell ratio closer to even than you might on a bonding curve, spread activity over a longer window, and avoid clustering trades in bursts. All three reduce the volatility component. They also make the trade history look less like a script, which is a second reason to do it. How campaigns get identified.

Note that the pool fee is separate from the Solana network fee. The network fee is what we measure from blocks. The pool fee is charged by the venue against trade value and is set by the pool configuration, so it must be added on top of everything on this page.

Measured failure rate and cost per landed swap

In the sample behind this page, Meteora DLMM transactions failed at 38.9% against a network-wide 27.9%, with a median fee of 6,642 lamports and a cost per landed swap of 10,871 lamports. A failed swap pays its fee and produces no volume, so the honest unit price on any venue is the median fee divided by the success rate rather than the median fee itself.

Meteora programs in our latest block sample. Rows with fewer than fifty sampled transactions are labelled and should be read as directional rather than precise.
Program	Sampled tx	Failure rate	Median fee	Cost per landed swap
Meteora DLMM	863	38.9%	6,642	10,871
Meteora dynamic AMM low sample	6	16.7%	23,090	27,719

Meteora sits between the two extremes we measure. It is materially cheaper per landed swap than a contested Pump.fun bonding curve, and materially more expensive than a quiet post-graduation pool. That position is stable across samples and is what you would expect from a venue that carries real volume without being the primary target of launch snipers.

Sample sizes matter when reading these rows. DLMM appears in most blocks we sample, so its figure is solid. The dynamic AMM program appears far less often, so when it is shown it is labelled as low sample and should be treated as an order of magnitude rather than a precise rate. Full method on the measurement page.

Configuring a campaign for Meteora

Use smaller trades than you would on a constant-product pool so more of them settle inside a single bin, keep the buy and sell ratio near even to suppress the dynamic fee, spread the campaign over a longer window, and check where the active bin sits before choosing a size.

Smaller trades, more of them. Trades that fit inside the active bin pay no price impact at all. This is the one venue where reducing trade size can increase efficiency rather than just reducing volume.
Balance the ratio. A heavy buy skew moves price across bins, which raises the variable fee for every trade that follows, including your own.
Stretch the duration. Compressed campaigns raise volatility, raise the fee and raise self-contention between your own wallets at the same time.
Watch the bin step. A pool configured with wide bins moves price in larger jumps, so the same trade produces a bigger visible step on the chart.

Volion resolves the routing target from the mint, so a token whose deepest liquidity is on Meteora is priced against the Meteora failure rate rather than a generic network figure. The estimate shown in the console before funding uses the measured number for the program your token actually trades on. That is the difference between a quote and a projection you can check.

Meteora against the other routing targets

Against a bonding curve, Meteora is cheaper per landed swap and offers real depth to trade into. Against a plain constant-product pool, it is more complex to size for but can be cheaper in slippage when trades fit inside bins. Against aggregator routing, it is a single-hop path with fewer accounts and lower failure risk.

The one comparison worth doing carefully is against routing through an aggregator. An aggregator can split a trade across several pools, which produces a larger transaction touching more accounts, and larger transactions fail more often under contention. Our measurements put aggregator routing at the highest failure rate of anything we sample. If your token has adequate depth in one Meteora pool, direct routing is usually the cheaper path. Measured aggregator routing.

For the broader picture of how a Solana volume bot chooses between these venues, and what each choice costs at current measured rates, start with the cost breakdown. Tokens that arrived from a launchpad usually pass through a Pump.fun curve and land on PumpSwap or a Raydium pool before liquidity ever reaches Meteora, so the route can change more than once in a token first week.

Questions

Does a volume bot work on Meteora?

Yes. Meteora DLMM pools are ordinary swap venues from a routing perspective, and a campaign can trade against them directly. What differs is how slippage and fees behave, which changes the trade sizing rather than the mechanics.

What is a liquidity bin?

A discrete price step in a DLMM pool. Liquidity sits in bins rather than spread along a curve, so a trade that fits inside the active bin executes at one price with no slippage, and a larger trade crosses into the next bin and moves price by the bin step.

Why does the Meteora fee change during a campaign?

DLMM applies a base fee plus a variable component that responds to how fast price is moving across bins. A campaign pushing hard in one direction increases volatility and therefore raises the fee its own later trades pay.

Is Meteora cheaper than Pump.fun for a campaign?

Per landed swap, in our measurements, yes by a wide margin, because bonding curve traffic carries far higher failure rates from sniper contention. Whether it is cheaper overall also depends on the pool fee, which is charged by the venue and is separate from the network fee we measure.

Should I route through Jupiter or straight to Meteora?

If your token has adequate depth in one Meteora pool, direct routing is usually cheaper. Aggregator routing can split across pools, producing larger transactions that touch more accounts, and those fail more often in our samples.

How current are the numbers on this page?

They come from the most recent stored sample of finalized mainnet blocks, and the measurement page shows the slot range and sample size for that run. Nothing here is carried over from a previous month.

Measured transaction costs Jupiter aggregator routing Orca Whirlpool routing Cost breakdown