Best MEV Tools and Frameworks for Solana Searchers in 2024

The Solana MEV landscape has matured enough that tool choice is now a real differentiator. The validators, bundle relays, and data streams that underpin competitive searching in 2024 are no longer a secret — but the gap between knowing they exist and knowing how to wire them together efficiently is still wide. This is an opinionated survey of the stack we've evaluated in production, with concrete trade-offs rather than feature checklists.

Jito Client Libraries: The Bundle Layer

Jito's MEV infrastructure is the mandatory foundation. Their Rust SDK (jito-sdk-rust) and the community-maintained jito-ts for TypeScript cover the two realistic implementation languages for production searchers. The Rust SDK is what you want for anything latency-sensitive: bundle submission, tip account derivation, and status polling are all first-class citizens.

The critical number to know is that Jito leaders currently process roughly 60–70% of Solana slots, so any bundle that misses a Jito leader has to fall back to standard TPU submission — you need a code path for that. The jito-searcher-client repo is the cleanest reference for how to handle this: it uses gRPC streams to detect the current leader schedule and routes accordingly.

Tip sizing is where most newcomers leave money on the table. There is no mempool, so you cannot observe other bids. The floor moves with network congestion and shifts dramatically in the seconds before a high-volume event. Start with dynamic tip calculation based on estimated profit and a configurable percentage floor (we use 20% of expected profit as a starting point), and log every bundle's acceptance latency so you can tune the floor empirically.

Yellowstone gRPC: The Data Plane

Yellowstone is the gRPC plugin for solana-validator that exposes real-time account updates, slot notifications, and transaction streams without going through the standard RPC polling loop. The difference in practice: polling a standard RPC for account state adds 50–150 ms round-trip and suffers head-of-line blocking under load. A subscribed Yellowstone stream delivers the same update at sub-10 ms from slot confirmation on a co-located node.

The yellowstone-grpc repo (maintained by Triton) is the canonical server-side implementation. On the client side, connect with the generated protobuf stubs in your language of choice — the proto definitions are in the repo. Watch for the confirmed vs finalized commitment distinction in subscription filters: for MEV purposes you almost always want processed or confirmed, and requesting finalized will introduce hundreds of milliseconds of unnecessary lag.

One concrete footgun: the server drops slow consumers rather than buffering indefinitely. If your processing pipeline stalls — say, you're doing a heavy simulation on every update — you will silently fall behind and then get disconnected. Decouple ingestion from processing with an internal ring buffer and monitor the delta between received slot and processed slot.

Transaction Building and Simulation

The standard @solana/web3.js v1 library is still widely used but its compute-unit estimation is unreliable for complex transactions that touch many accounts. Under-estimating CU budget causes silent simulation failures at execution time; over-estimating wastes priority fee budget.

Two better options:

• solana-transaction-builder (community): wraps the lower-level transaction assembly with better CU introspection. The simulation call returns a breakdown by instruction, which lets you set per-instruction compute budgets.
• Direct RPC simulation (simulateTransaction with replaceRecentBlockhash: true): cheaper than the abstraction layer and gives you raw logs. When debugging a failed bundle, this is the fastest way to see which instruction is hitting the CU wall or triggering an access violation.

For Rust implementations, the solana-sdk and solana-transaction-status crates give you full control. The banks-client test infrastructure in the Solana repo deserves attention: it lets you run full program execution locally against a cloned state snapshot, which is useful for validating complex multi-step arb paths before risking real capital.

DEX Aggregator APIs vs. On-Chain State Reads

Jupiter's price API and quote API are convenient, but they introduce 10–50 ms of HTTP overhead per call and their route results are cached server-side, meaning you can be quoted a stale price during high volatility. For any strategy that competes on price discovery, read pool state directly.

For Orca Whirlpools and Raydium CLMM pools, the account layouts are documented and the math is implementable in ~200 lines of Rust. The payoff: you can compute an exact quote in under 1 ms from a cached account snapshot, versus the round-trip cost of an API call. The trading bot infrastructure we build at TierZero always goes direct on the hot path, with aggregator APIs as a fallback for route discovery across long tail pools.

Monitoring and Latency Profiling

You cannot optimize what you cannot measure. Two instruments that matter most:

• Bundle landing rate by tip tier: track what percentage of your bundles land, segmented by the tip amount relative to slot profit. This is the empirical curve you need to size tips dynamically.
• End-to-end latency from account update to bundle submission: instrument this at the microsecond level. A 5 ms regression in your processing pipeline costs more than it looks — at slot speeds of ~400 ms, 5 ms is over 1% of your reaction window.

Prometheus + Grafana is the standard stack here. Add custom histograms for bundle latency and a counter for tip floor adjustments. Alert on landing rate drops before you alert on PnL drops — the leading indicator is more actionable.

Simulation Environments: Testing Without Capital Risk

The Solana program test framework (solana-program-test) is the right tool for unit-level correctness. For integration testing of full MEV flows — bundle construction, tip account validation, slot timing — solana-test-validator with a state snapshot gives you a local environment that's close enough to mainnet to catch most issues.

Forked state testing matters most when you're launching a new strategy. Pull a snapshot of relevant pool accounts at a known slot, replay it locally, and run your strategy against it to verify your PnL estimates match what you'd extract on-chain. The discrepancy almost always points to either a fee miscalculation or a pool state assumption that breaks under specific tick configurations.

---

If you are building a Solana MEV strategy from scratch or want an outside evaluation of your current stack's weak points, talk to us — we scope and ship searcher infrastructure that is already running in production.