◆ FOR DLMM BOTS
Solana infrastructure for DLMM bots.
A DLMM bot wins on coherent pool, bin, position, and token-account state - then a rebalance or exit that lands without double-firing capital.
◆ 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 one coherent view across every account the instruction depends on - not a single hero latency number.
- Filtered account updates let the bot follow selected pool, bin-array, position, and token accounts without repeatedly scanning the entire DLMM program.
- A quote based on mixed slots can be stale before it is signed. Record the slot on streamed state and refresh dependent accounts before building a rebalance or swap.
- Rebalance, compound, and exit transactions touch several accounts. Simulation catches missing accounts, stale blockhashes, compute limits, and instruction errors before capital moves.
- 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 LOOP
Production steps, in order.
Bound the working set: each pool, bin arrays around the active bin, positions you own, and the token accounts for liquidity or swaps.
Stream account writes for that set (WebSocket accountSubscribe or Yellowstone filters) and keep a slot-tagged local view.
On a relevant update, refresh dependent accounts, then build the next instruction with the official Meteora DLMM SDK.
Simulate, sign locally, submit on a measured send path, and confirm with an idempotency key so retries never double-commit capital.
◆ THE STACK
The path, mapped.
Yellowstone gRPC
Server-side account filters for the pools, bin arrays, and positions you own - keep the working set bounded as the strategy scales.
Explore Yellowstone gRPC →Solana RPC
Snapshots, dependent-account reads, simulation of SDK-built txs, blockhashes, and final position reconciliation after landing.
Explore Solana RPC →Transaction sender
Submit locally signed rebalance, compound, swap, and exit transactions while the bot keeps key custody and retry policy.
Explore Transaction sender →◆ START HERE
Paper path first
Prove a key and accountSubscribe a Meteora Lb pool with zero rebalance logic. Wiring only - not a strategy.
git clone https://github.com/rpc-edge/rpcedge-dlmm-ref.git cd rpcedge-dlmm-ref && pnpm install export RPCEDGE_KEY=your-uuid-key # app.rpcedge.com/signup # optional: export WATCH_POOL=<your Meteora DLMM pool> pnpm doctor && pnpm start
◆ FAQ
Straight answers.
Which accounts should a Meteora DLMM bot watch?
Is there an open reference implementation?
Should a DLMM bot poll RPC or use Yellowstone gRPC?
Does DLMM automation require the fastest shred feed?
Where should API keys and wallets live?
What plan is enough to start?
Bring the Meteora pools, position count, update frequency, and target region. We will size filters and the RPC path around the job the bot actually runs - then you measure landing on your path.
◆ MORE WORKLOADS