Meteora DLMM volume bot: how bin steps change your cost
Meteora DLMM does not hold liquidity on a curve. It holds it in discrete price bins, and that single design decision changes almost everything about what a volume campaign costs there. A swap contained inside one bin has no price impact at all, which is a property no other Solana venue offers. A swap that crosses bins behaves like a series of small jumps instead of a smooth slide. Understanding where that boundary sits for your pair is the difference between the cheapest venue you can run on and an unpredictable one.
What a bin actually is
This is a genuinely different model from constant-product pools and from tick-based concentrated liquidity. On a constant-product pool every trade, however small, moves the price a little. On Meteora DLMM, a trade that fits within the active bin moves it not at all, and the price only changes when a bin is emptied and trading moves to the next one.
For a volume campaign that property is unusually valuable. The goal is to generate genuine transaction activity without pushing the price around, and a venue where correctly sized trades have literally zero price impact is the closest thing to purpose-built for it. The relationship between transaction count and what a chart displays is covered in makers versus volume.
The catch is that bins have finite depth. The active bin holds only what liquidity providers put in it. Trade larger than that and you consume the bin, cross into the next, and the price steps. The step is not a rounding error, it is the full bin step width.
What bin step means and why it is chosen at pool creation
The trade-off is precision against continuity. A small bin step tracks price finely, so crossing a bin is a small jump, but liquidity is spread across many bins and each individual bin is shallower. A large bin step concentrates liquidity into fewer, deeper bins, so more trades fit inside one bin, but crossing a boundary is a bigger jump.
For volume generation this cuts in a specific direction. A larger bin step means a deeper active bin, which means more of your trades fit inside it with zero price impact. The downside, that price moves in coarser steps, matters mainly to traders trying to capture small moves. It matters much less to a campaign whose objective is activity rather than a price outcome.
So when a pair has multiple DLMM pools, the one with the wider bin step and real liquidity in the active bin is often the better venue for a campaign, even though a discretionary trader would prefer the tighter one. This is one of the few cases where the right venue for a bot and the right venue for a trader are genuinely different.
The dynamic fee: why timing changes your bill
The mechanism exists to compensate liquidity providers for the risk they carry during volatile periods, and it works as intended. But it has a direct consequence for anyone running a scheduled campaign: running through a volatile window costs more per swap than running through a calm one, on top of the higher failure rate volatility already causes.
This compounds with priority fees, which also rise when the network is busy. A campaign that runs during a market-wide move is paying more in three places at once: higher priority fees to land, higher variable DLMM fees, and more retries because more swaps fail. None of those appear in a quoted cost per swap.
The practical response is to treat pacing as a cost lever rather than only a detection concern. Spreading a campaign across calmer periods reduces the bill measurably, and it also produces a more natural looking transaction pattern than a burst does. How priority fees behave under the same conditions is covered in how Solana priority fees work.
What Meteora actually costs, measured
| Program | Sampled tx | Failure rate | Median fee | Cost per landed swap |
|---|---|---|---|---|
| Meteora DLMM | 109 | 69.7% | 8,450 | 27,888 |
| Raydium CLMM low sample | 49 | 65.3% | 10,570 | 30,461 |
| Orca Whirlpools low sample | 18 | 77.8% | 5,225 | 23,536 |
In our current window Meteora DLMM showed a median fee of 8,450 lamports with a 69.7% failure rate across 109 sampled transactions, which is roughly 27,888 lamports per swap that lands.
Failure rates on concentrated designs sit well above the network average, and DLMM is no exception. The reason is the same across all of them: quotes are computed against liquidity that is in range right now, and range membership changes when other people trade. What distinguishes DLMM is that inside a bin there is no gradual degradation, so the outcomes cluster into clean successes and clean failures rather than a spread of partially bad fills.
Rows with small samples are marked as such rather than presented as equivalent, and every figure carries the window it was measured over. The complete percentile distribution is on the measured transaction costs page, and the cross-venue comparison is on which Solana DEX is cheapest for a volume bot.
Sizing trades to stay inside a bin
Finding the threshold is a matter of requesting quotes at increasing sizes and watching for the point where quoted price impact stops being zero. That point is the edge of the active bin. Sizing meaningfully below it leaves room for someone else to trade before you land without pushing you over the edge.
Two further considerations shape the number:
- Bin depth changes constantly. Liquidity providers add and remove, and other traders consume the bin. A size that fitted an hour ago may not fit now, so the threshold is worth re-checking rather than setting once.
- Smaller trades produce more transactions per SOL. Since campaign effect comes from transaction count and distinct participants rather than from the size of any single trade, smaller trades are usually better on two axes at once here.
This is a rare case where the safe setting, the cheap setting and the effective setting all point the same way. On most venues you trade one against another. On DLMM, staying inside a bin gets you all three.
How DLMM differs from Raydium CLMM and Orca Whirlpools
On a tick-based pool there is no size at which price impact is zero. Every trade moves the price a little, and the question is only how much. On DLMM there genuinely is such a size, and it is discoverable. For a campaign that wants activity without price movement, having a hard threshold to stay under is easier to work with than a continuous curve to minimise against.
Against that, tick-based pools fail somewhat more predictably. A DLMM pool where the active bin empties can jump a full bin step in one trade, which is a larger discontinuity than a tick crossing produces. Neither design is universally better; they fail differently, and the settings that suit them differ accordingly.
The Raydium comparison is covered in detail in Raydium CLMM vs CPMM for a volume bot, and Orca specifics are in Orca Whirlpool routing.
Running a campaign on a Meteora pool
- Size under the bin. Find the threshold by quoting increasing sizes, then work meaningfully below it. This is the single highest-leverage setting on this venue.
- Set slippage to about one bin step plus a margin. Tighter and ordinary bin crossings fail you. Much wider and you have opened a window for someone else to profit inside, as described in sandwich MEV protection.
- Pace around volatility. The dynamic fee, priority fees and failure rates all rise together during fast moves. Spreading activity across calmer periods is cheaper and looks more natural.
- Re-quote on failure. The minimum output is baked into the signed instruction, so resubmitting the same transaction after a bin crossing fails identically and costs another fee.
When you enter a token address in the dashboard, the venue and pool are resolved from where liquidity actually sits, so you do not have to identify the bin step yourself. What you set is size, interval and tolerance, which is where the differences above turn into money. To model the total before committing anything, the calculator converts a target volume into cost at current measured rates, and the full budget arithmetic is in the cost breakdown.
Publishing the measured inputs instead of asserting a single cost per swap is the premise the whole volume bot for Solana is built on, and it is why the tables above carry a timestamp rather than a marketing figure.