Meteora volume bot: bins, dynamic fees and where campaigns go wrong

How DLMM actually works

Most AMMs price along a smooth curve: every trade, however small, moves price a little. Meteora's DLMM takes a different approach. It divides the price range into discrete bins, and each bin holds liquidity at a single fixed price.

The practical consequences are worth understanding before you route volume through it:

• Zero slippage inside a bin. A swap small enough to be filled from the current bin executes at that bin's price exactly, with no curve to slide along.
• Step changes between bins. A larger swap consumes the current bin and moves into the next, taking each at its own price. Execution is a series of steps rather than a smooth slide.
• Liquidity can be extremely uneven. Providers choose which bins to fill. A pair can look deep in aggregate while the bins immediately around the current price hold very little.

That last point is the one that catches campaigns out. Aggregate TVL tells you almost nothing about what your next swap will actually cost.

Why bins change campaign design

On a constant-product pool, doubling swap size roughly doubles price impact in a predictable way. On DLMM, impact is a step function: swaps stay cheap while they fit inside populated bins, then get abruptly worse when they cross into empty ones.

For a volume campaign that argues for smaller, more numerous swaps rather than fewer large ones. Small swaps stay inside the populated bins, execute efficiently, and produce more trade count for the same SOL - which happens to be what you want anyway, since trade count is one of the things discovery surfaces read.

It also argues against directional pressure. Repeated buys walk price up through bins one at a time, and because each step is discrete, the resulting chart can develop a visible staircase. A balanced ratio keeps price oscillating inside populated bins instead of marching out of them.

Dynamic fees and campaign cost

Meteora pools can apply a variable fee that rises with volatility, designed to compensate liquidity providers when price is moving fast. It is a sensible design for LPs, and it has a direct implication for anyone generating volume: the network-side cost of your swaps is not constant.

Two things follow. A campaign run during a volatile window costs more per swap than the same campaign in a calm one, in fees paid to the pool. And a campaign that itself creates volatility - through heavy one-directional pressure - can raise the fee it then pays, which is a quietly expensive way to run.

None of this affects what you pay us. The service fee is a flat 2% of target volume, and network fees, Jito tips and wallet funding are inside that number. But it does affect how the router behaves: legs are weighted by live conditions, not by a static plan drawn up before the campaign started.

DAMM pools

Alongside DLMM, Meteora runs dynamic AMM pools, which sit closer to the familiar constant-product model with additional yield mechanics on the idle side of the pool. For campaign purposes they behave much more like a standard AMM: smooth pricing, predictable impact, no bin edges to worry about.

If a token has both DLMM and DAMM liquidity, the useful approach is the same as everywhere else on Solana - split by real depth rather than choosing one and ignoring the other. Concentrating everything into a single pool is both less efficient and easier to identify.

Meteora as a launch destination

Meteora infrastructure sits underneath several launch mechanisms on Solana, which means a token can arrive in a Meteora pool without its creator ever having chosen Meteora directly. That is fine, and it is another reason the router follows liquidity rather than asking you to name pools.

In the console you pick the launchpad the token was created on - Pump.fun, Bonk.fun, Raydium LaunchLab, Jupiter Studio and the rest - and exchange routing, including Meteora, happens automatically based on where depth actually is at run time.

What a sensible campaign looks like

1. Small swaps, many of them. Stays inside populated bins, maximises trade count, minimises step-through cost.
2. Balanced ratio. Keeps price oscillating rather than marching in one direction through bins.
3. Depth-weighted split. Across DLMM, DAMM and whatever else the token trades on, rather than one pool taking everything.
4. Window matched to attention. Density matters more than the raw total, and it costs nothing extra to choose it well.
5. A realistic target. Read the screener, look at what tokens in your position are actually doing, and size to that. The sizing guide covers the method.

None of that is Meteora-specific advice dressed up as expertise - it is what the venue's mechanics force if you are paying attention to them.