◆ FOR DLMM BOTS

Solana infrastructure for DLMM bots.

A DLMM bot wins by keeping pool, bin, position, and token-account state coherent while it quotes, rebalances, compounds, or exits.

Get Started →See the numbers →

◆ THE WORKLOAD

What decides the outcome.

A Meteora DLMM automation loop watches the pools and positions it owns, tracks the active bin and relevant bin arrays, computes a quote or new liquidity range with the official SDK, checks balances and exposure, builds and simulates the transaction, signs locally, then submits and confirms it. The hard part is maintaining one coherent view across every account the instruction depends on.

Filtered account updates let the bot follow selected pool, bin-array, position, and token accounts without repeatedly scanning unrelated program state.
A quote based on mixed slots can be stale before it is signed. Record the slot attached to streamed state and refresh dependent accounts before building a rebalance or swap.
Rebalance, compound, and exit transactions can touch several accounts. Simulation catches missing accounts, stale blockhashes, compute limits, and instruction errors before capital is committed.
Reliable confirmation and idempotent job state matter as much as submission speed. A timeout must not cause the bot to repeat a liquidity action blindly.

◆ THE STACK

The path, mapped.

Yellowstone gRPC

Stream the pool and position accounts your bot owns, with server-side filters that keep the working set bounded.

Explore Yellowstone gRPC →

Solana RPC

Load dependent accounts, simulate SDK-built transactions, fetch blockhashes, and reconcile the final position state.

Explore Solana RPC →

Transaction sender

Submit locally signed rebalance, compound, swap, and exit transactions while the bot retains key custody and retry policy.

Explore Transaction sender →

Primary implementation references.

◆ FAQ

Straight answers.

Which accounts should a Meteora DLMM bot watch?

The exact set depends on the operation, but the working set usually includes each selected pool, the relevant bin arrays around its active bin, positions the bot owns, and the token accounts used for liquidity or swaps. Derive addresses and build instructions with the official Meteora SDK, then stream only the accounts the running strategy needs.

Should a DLMM bot poll RPC or use Yellowstone gRPC?

Use a stream for changes to the bounded working set and RPC for snapshots, dependent-account reads, simulation, and reconciliation. The stream reduces polling and shortens detection; RPC remains the authority for building and verifying the next transaction.

Does DLMM automation require the fastest shred feed?

Usually no. Rebalancing and liquidity management benefit first from coherent account state, correct SDK instruction construction, simulation, and safe retries. If a specific strategy later proves detection time is the bottleneck, benchmark an earlier feed against that loop before buying it.

Bring the Meteora pools, position count, update frequency, and target region. We will size the filters and RPC path around the job the bot performs.

Get Started →See pricing →