Solana MEV bot development
A Solana MEV bot, or searcher, reads live validator data, finds an opportunity such as a backrun arbitrage or a liquidation, and submits it as a Jito bundle with a tip. We build the pipeline, tip policy and ledger around your strategy, with full source code, from a fixed $500.
Fixed price
from$500
Up to
$1,950
with every module
One price, in writing, before any work starts. It does not change after you approve it.
- Price agreed in writing before any work starts
- You bring the strategy, we build everything around it
- Inputs from the gRPC and shred feeds we operate
How a searcher moves through four slots
Drag the line along one leader’s four slots. Each stage says what happens there and who runs it, and yellow marks where NoLimitNodes sits in the path.
Build
The bundle builder orders the transactions, adds the tip and simulates the result before anything is sent.
Built by us
The six stages of a searcher pipeline
- 01
Input
Shreds and gRPC updates arrive as the network produces them. The bot never polls.
Runs on NoLimitNodes
- 02
Decode
Raw accounts and transactions become market state: pools, prices, positions.
Our decoders, or your own
- 03
Detect
Your strategy module reads the new state and decides whether an opportunity exists and what it is worth.
Your strategy, in our pipeline
- 04
Build
The bundle builder orders the transactions, adds the tip and simulates the result before anything is sent.
Built by us
- 05
Submit
The bundle goes to a Jito block engine, which runs parallel auctions at 50 ms ticks.
Jito’s block engine
- 06
Include
The leader decides whether the bundle lands. A bundle that does not land is dropped whole.
The leader decides
What data does a Solana MEV bot read?
The searcher reads live validator data. Yellowstone gRPC delivers transactions and account updates as the validator processes them. Shredstream delivers raw shreds earlier, but with no execution results, so the bot has to decode them and handle failures itself.
Delivered
- Yellowstone gRPC subscriptions for the accounts and programs your strategy watches
- Reconnects that replay from the last processed slot
- A health check that stops the bot when a feed goes quiet
- Shredstream ingestion as an optional module
inputs: grpc: endpoint: grpc.mainnet.solana.nolimitnodes.com:443 commitment: processed accounts: [pool_a, pool_b] reconnect: { from_slot: last_processed } shreds: enabled: false # MOD-05 stale_feed_stop_ms: 2000LimitsShreds carry no execution results, so anything built on them is a prediction until the transaction confirms.
How does the bot keep market state?
A local replica of the pools and positions your strategy needs, updated from the stream. Decoders cover Raydium, Orca, Meteora and PumpSwap pools and lending accounts, and the replica is reconciled against confirmed state.
Delivered
- Per-venue decoders for pool and position accounts
- A snapshot per slot, so detection never reads half-updated state
- Reconciliation against confirmed state after forks and gaps
state: venues: [raydium_clmm, orca_whirlpool, meteora_dlmm] snapshot: per_slot reconcile_commitment: confirmed on_gap: mark_staleLimitsA replica is only as fresh as its feed. During a fork or a gap the bot marks state stale and does not trade on it.
How does it find an opportunity?
A strategy module reads each new snapshot and returns either nothing or an opportunity with an expected net. We build the modules in the bill of materials, and the interface is documented so your own strategy can plug into the same pipeline.
Delivered
- A documented strategy interface: state in, opportunity or nothing out
- Backrun arbitrage, liquidation and new-pool gap modules, each priced separately
- Expected net computed after pool fees, compute cost and tip
strategy: module: backrun_arb # MOD-02 min_net_lamports: 200000 max_position_sol: 5 pairs: [SOL/USDC, SOL/USDT]LimitsWe build the plumbing and the modules listed. The edge in your own strategy is yours.
How does a searcher build a Jito bundle?
A bundle is up to five transactions that execute in order and all together, or not at all. The builder orders them, fits them inside compute and size limits, adds the tip and simulates the whole bundle before it is sent.
Delivered
- Transaction ordering and sizing inside compute, account-lock and size limits
- The tip placed in the main transaction by default, with a separate tip transaction only when space is tight
- Address lookup tables for your accounts, never for tip accounts
- Simulation of the full bundle before every send
bundle: max_txs: 5 tip_in_main_tx: true tip_account: random_of_get_tip_accounts simulate_before_send: true compute_unit_limit: auto- A bundle holds up to five transactions, in order.
- They all land together or none of them do.
- The tip is one transfer to one of the eight published tip accounts.
- Tip accounts never go in an address lookup table.
LimitsBundles only matter when a Jito-Solana validator is the leader. Tips do not prioritise transactions for any other leader.
How should a Jito tip be set?
Jito enforces a minimum tip of 1,000 lamports, and its documentation warns that this may not be enough when demand is high. We build the tip as a policy you can read and change: a share of the opportunity’s expected profit, held between a floor and a ceiling, per strategy.
Delivered
- A tip policy: share of expected profit, a floor and a ceiling, per strategy
- A cap on total tips per hour, enforced by the risk layer
- The tip account chosen at random from the published list
tip: policy: share_of_expected_profit share: 0.30 floor_lamports: 10000 ceiling_lamports: 500000 max_per_hour_sol: 0.5At an expected profit of 0.00120 SOL the bot would tip 0.00036 SOL (360,000 lamports), set by the share.
Jito’s own minimum tip is 1,000 lamports, and its documentation warns that this may not be enough when demand is high. The floor slider starts at that minimum.
LimitsPaying more raises the chance of landing and lowers what you keep. The right number depends on your strategy and the market, and no policy guarantees inclusion.
How does it land a bundle and retry safely?
Every opportunity gets an id. The bot tracks the status of each bundle and resends the same opportunity with a fresh blockhash and a repriced tip, and it never keeps two live bundles for one opportunity.
Delivered
- Bundle status tracking against the block engine
- One live bundle per opportunity id, with a cap on resubmits
- Opportunities dropped once they are stale, rather than chased
landing: one_live_bundle_per_opportunity: true max_resubmits: 2 drop_after_slots: 2 status_poll_ms: 200LimitsA bundle that does not land costs nothing in tip, but the opportunity may be gone by the time the bot tries again.
How does it show its work?
Every decision is written down: the opportunity, its expected net, the bundle, the tip, whether it landed and, if not, why. Realised results are set against expected ones so a strategy that stops paying is visible.
Delivered
- A per-bundle ledger: opportunity, expected net, tip, status, landed slot and drop reason
- Expected against realised net, per strategy
- Structured logs, plus Telegram and webhook alerts
- An operations dashboard as an optional module
ledger: store: postgres record: [opportunity, bundle, outcome, costs]alerts: telegram: true webhook: https://example.com/hookLimitsThe ledger records what happened. It does not predict what will.
What stops it losing more than you allow?
Limits that the strategy cannot override: a kill switch, a cap on tips and losses, and a cap on position size. The signing key lives in its own process on a server you control, and the strategy never touches it.
Delivered
- A kill switch you can trip from a file, a command or an alert
- Caps on tips per hour, loss per day and position size
- A separate signing process with a dedicated hot wallet
risk: kill_switch: file:/etc/bot/STOP daily_loss_stop_sol: 2 max_tip_per_hour_sol: 0.5 max_position_sol: 5signer: process: separate wallet: dedicated_hotLimitsRun the bot from a dedicated wallet funded with only what you are prepared to lose.
What we build and what you bring
The division of labour, line by line. The strategy and the capital are yours. Everything that carries them to the leader is ours.
| Area | We build | You bring |
|---|---|---|
| Feeds | gRPC and shred ingestion, reconnects and health checks | Which accounts and programs matter to your strategy |
| State | Decoders and the state replica | The venues and markets you care about |
| Strategy | The plumbing and the modules in the bill of materials | The edge: your parameters, or your own strategy logic |
| Bundles and tips | The builder, simulation, the tip policy and the resubmission rules | How much of the expected profit you are willing to pay away |
| Money and keys | Risk limits and a key-handling layout | The capital, the wallet and the limits themselves |
| Operations | The ledger, alerts and a runbook | A server you control. NLN VPS or bare metal both work |
Bill of materials
A fixed price for the core and for every part you add. Part numbers match the datasheet above. Choose the parts and the total follows.
| Part | What it is | Price | Include |
|---|---|---|---|
MOD-01Core searcher framework | Inputs, decoder, bundle builder, tip policy, retries, ledger and risk controls | $500 | |
MOD-02Backrun arbitrage module | Finds a price gap a swap has just opened between two pools and backruns it | $250 | |
MOD-03Liquidation module | Watches lending positions and liquidates the ones that cross their threshold | $250 | |
MOD-04New-pool cross-venue gap module | Compares a new pool’s price with the same token on other venues | $250 | |
MOD-05Shred ingestion | Adds Shredstream as an input alongside gRPC, with a decoder for raw shreds | $200 | |
MOD-06Historical replay harness | Replays recorded slots through your strategy to test it before it spends | $300 | |
MOD-07Operations dashboard | A web view of the ledger, tips, landing rate and risk limits | $200 | |
| Total, fixed price | $500 | ||
Included in every price: full source code, documentation and a runbook, two weeks of support, and free NLN RPC and gRPC access while we build it. These are introductory prices while we open MEV builds.
How the build runs
Four steps, no surprises. You know what is happening at every stage and you approve the quote before any code is written.
- 30-minute call
Scope call
You describe the strategy and the venues. We tell you whether we can build it, what it takes, and confirm the price.
- Fixed price
Written quote
A written spec with milestones, deliverables and the fixed price. Nothing starts until you approve it.
- Weekly demos
Build
A working demo every Friday against live mainnet data, so you see the bot decide before it trades.
- Support included
Ship and support
We deploy to a server you control, hand over the source and documentation, and stay on for two weeks of support.
What you receive
- The complete source code, in your repository
- A configuration reference for every rule
- Documentation and an operations runbook
- Deployment to a server you control, including NLN VPS or bare metal
- Two weeks of post-launch support at no extra cost
- Free NLN RPC and gRPC access while we build it
Software, not custody and not advice
MEV is a high-risk activity. We build the tool; what you do with it is yours to decide and yours to answer for.
You hold the keys and the funds.
We never take custody of your keys or your capital. The bot signs from a wallet in your environment.
We build software, not advice.
We do not recommend wallets to copy or tokens to buy, and nothing on this page is financial advice.
MEV can lose money.
Bundles can fail to land, tips and fees are paid on every attempt that does, and opportunities close before a transaction arrives. We make no claims about returns.
Running it is your call.
Rules differ by country. If you plan to offer the bot to other people, tell us on the scope call, because custody and licensing change the design.
Questions about MEV bots
Not here? Send the brief and ask on the scope call, or read how we work on custom development.
What is a Solana MEV bot or searcher?
A Solana MEV bot, usually called a searcher, reads live validator data, finds an opportunity such as a backrun arbitrage or a liquidation, and submits it as a transaction or a Jito bundle with a tip. It is only paid when the opportunity lands, so the plumbing around the strategy matters as much as the strategy.
What is a Jito bundle?
A Jito bundle is a group of up to five transactions that execute in order and atomically, all or nothing, with a tip paid to one of Jito’s tip accounts. Bundles go to a Jito block engine and only matter when a Jito-Solana validator is the leader.
How much does it cost to build a Solana MEV bot?
The core searcher framework is a fixed $500. Strategy modules for backrun arbitrage, liquidations and new-pool gaps are $250 each, Shredstream ingestion is $200, a historical replay harness is $300 and an operations dashboard is $200. The bill of materials above adds up as you choose, and the most it can reach is $1,950. The price is agreed in writing before any work starts, and these are introductory prices while we open MEV builds.
What data does a Solana searcher read?
Yellowstone gRPC delivers transactions and account updates as the validator processes them. Shredstream delivers raw shreds earlier, but without execution results, so the bot has to decode them and handle failures itself. Most searchers start on gRPC and add shreds when a strategy needs the earlier signal.
How should a Jito tip be set?
Jito enforces a minimum tip of 1,000 lamports, and that may not be enough when demand is high. We build the tip as a policy you set: a share of expected profit between a floor and a ceiling, per strategy. Paying more raises the chance of landing and lowers what you keep, so the right number depends on your strategy and the market.
Does a MEV bot guarantee profit or inclusion?
No. The leader decides what lands, and the market decides what pays. Bundles only matter when a Jito-Solana validator is the leader, and many searchers compete for the same opportunities. We make no claims about either.
How does the bot avoid sending two bundles for one opportunity?
Every opportunity gets an id. A resend carries the same id with a fresh blockhash and a repriced tip, and the bot never keeps two live bundles for one opportunity, so a retry cannot double a position.
Who owns the strategy and the code?
You do. The source code, the configuration, the documentation and the deployment scripts are yours, with two weeks of post-launch support included. Your strategy logic never has to be shared with us.
Tell us what the searcher should find. We’ll scope it.
Send the brief and an engineer comes back with questions, not a sales script. Here is what happens next.
- 1An engineer reads your brief and replies by email to book a 30-minute scope call.
- 2You get a written spec and your fixed price after the call.
- 3Nothing starts until you approve the quote.
Prefer to talk it through first? Email [email protected] or join us on Discord.