How to Choose a Market Making Bot

If you're running market making for a token — as the project's own team or as a hired desk — your results come from two things: the strategy you run, and the technology that executes it. Strategy and the traders behind it get all the attention, deservedly. But even the best strategy is carried out as thousands of small mechanical outcomes: whether your transaction landed in the next block or forty blocks later, whether a sandwich bot took a bite out of it, whether you paid triple the priority fee you needed to, whether a wallet spent all week retrying a buy it could never afford. This post is about that second layer — how to compare the technology you trade with.

Most teams pick their trading technology the way they'd pick a phone plan: compare the sticker prices, pick the cheapest. This article is about why that's usually the most expensive decision they make — and what a serious execution stack should be doing for you instead. It's the checklist we wish more people used, because the tools that fail it don't fail loudly. They just quietly leak your money.

The standard checklist: necessary, but nowhere near sufficient

Every comparison starts with the same four questions, and they're fine questions — you should ask them.

Coverage. Can the tool trade where your token lives? Sumo supports 29 DEXs across 6 chains — Solana, Ethereum, BNB Chain, Base, Robinhood Chain, and Tron — under one execution model, so a token that migrates or expands doesn't force a tooling change.

Landing rate. What fraction of your transactions actually make it on-chain? Sumo lands 99.5%+. But here's the caution: landing rate is the most inflated number in this industry. Everyone claims a great one, and most claims don't survive one follow-up question: how is it measured? Landed on the first attempt, or eventually? Are orders that failed simulation quietly excluded from the denominator? Is the number from a calm Tuesday or from the middle of a launch-day congestion spike? A provider that curates the denominator can advertise any number it likes. A real landing rate is earned with infrastructure — fanout, rebroadcasting, expiry-aware retries — all of which we'll get to below.

Landing speed. When it lands, how fast? On Sumo's fast paths, next-block — the transaction confirms in the block after it's sent. For a market maker reacting to live flow, the difference between next-block and five-blocks-later is the difference between trading the move and trading its aftermath.

Fees. The pricing page: subscription, per-trade percentage, tip pass-throughs. Worth reading. Also the least important number in this article.

Because here's the uncomfortable truth the standard checklist misses: the direct fee is usually the smallest line in your true cost of execution. The hidden costs — a builder fee skimmed on every single transaction, losses to sandwich attacks, arbitrage leakage from careless routing, overpaid priority fees, gas burned by wallets retrying doomed trades — more often than not add up to far more than anything the provider charges you openly. None of them appear on a pricing page. All of them appear in your PnL. The rest of this article is the checklist for those.

You can't manage what you can't see

Start with visibility, because every hidden cost below is invisible by default. If your tool shows you a bare list of trades — time, size, price — you have no way of knowing whether you're bleeding, let alone where.

Sumo's live trading panel tags every transaction in your pool, in real time, with the context that actually matters to a market maker:

• MEV indicators — trades flagged as part of a sandwich attack, with the attacker and the victim marked separately. If your own transactions keep showing up as victims, your execution path is leaking money on every trade — and now you can see it, count it, and fix it.
• Arbitrage flags — trades where the maker's balance barely changed net of the round trip: someone extracting value from a price gap in your pool. Persistent arb flow means your pool's price is drifting from the market and someone else is being paid to correct it.
• Holder context — every maker classified by share of supply (whale, dolphin, fish, shrimp), plus flags for first-time buyers and full exits. A 2 SOL sell from a shrimp and a 2 SOL sell that's a whale's first step out the door are very different events.
• Execution source — the actual platform behind each trade, recognized from over a hundred known routers and trading bots: Photon, Axiom, Maestro, BonkBot, Banana Gun, Jupiter, and the rest. Watching which platforms your flow comes from tells you who your counterparties are.
• Your flow vs. organic flow — your own strategy trades are tagged and filterable, so you can see your footprint in the tape exactly as outsiders see it.
• Tracked wallets — label the addresses you care about (team wallets, known snipers, a competitor's desk) and their trades light up in the feed.

This isn't decoration. Each of those badges answers a question that directly moves money: Am I getting sandwiched? Is my pool leaking to arb? Who is actually selling to me? Most tools can't answer any of them.

Landing transactions is a systems problem, not a setting

On a congested chain, getting a transaction included reliably is genuinely hard, and no single trick solves it. Helius wrote a good explainer on why transactions fail to land on Solana — dropped packets, expired blockhashes, underpriced fees, lagging RPC nodes. Read it and you'll notice something: every fix it recommends is something you'd have to build. The right question for a technology provider is: which of these have you already built?

Multiple RPC providers, used intelligently. One RPC connection is one point of failure. Sumo maintains a pool of providers with independent health tracking: reads go to the fastest healthy provider with automatic failover down the list, while transaction sends are fanned out to all healthy providers in parallel — the first to accept wins. Every provider is wrapped in a circuit breaker (a provider that starts failing is benched and probed until it recovers), and rate-limited providers go into a temporary penalty box rather than being hammered. Latency is tracked separately for reads and writes, because a provider that's fast at one is often slow at the other.

Priority fees priced from data, not fear. The lazy way to land transactions is to overpay every time — which is exactly what tools do when they hardcode a "high" fee. Sumo estimates fees from live network data as percentile tiers, scoped to the specific accounts your transaction touches — so congestion in someone else's hot market doesn't inflate what you pay in yours — and clamps everything between a floor and a hard cap. You pay what inclusion costs, not what panic costs.

Rebroadcasting that can't execute twice. Here's a subtle one that separates real execution engines from scripts: when a transaction doesn't confirm quickly, you want to re-send it — but naively "retrying" a trade risks executing it twice. Sumo rebroadcasts the same signed bytes on a timer. The network deduplicates by signature, so a rebroadcast can only help the original land — it can never create a second fill. Only when the transaction's blockhash actually expires (its ~1-minute validity window closes without inclusion) does the engine rebuild and re-sign — and every order carries a unique ID with distributed locking, so even a crash and restart mid-flight can't fire the same order twice.

Confirmation you don't have to babysit. Every submitted transaction is tracked over a WebSocket subscription with polling as a fallback, plus block-height monitoring to detect expiry. Orders interrupted by a restart are found and resumed automatically. "Did that trade actually go through?" is a question the system answers — not one you should ever be asking it.

Anti-MEV is a feature, not a plan

A sandwich attack is a direct transfer from your treasury to a bot: it spots your pending buy before it executes, buys before you, lets your trade push the price up, and sells right after — you bought higher than you should have, and the difference is their profit. For a market maker executing all day, every day, unprotected transactions are a standing donation.

The core defense is simple to state: don't let bots see your transactions while they're in flight. In practice that takes several mechanisms working together:

• Jito bundles (Solana). Transactions submitted as atomic bundles through Jito’s block engines go straight toward the block producer — they never appear in the public mempool, so there is nothing to sandwich. Sumo submits bundles across Jito’s regional endpoints with automatic failover, and MEV-sensitive strategies use this path by default.
• Private relays. Not every chain has Jito, but every chain has the same problem — and the same principle applies: deliver transactions through private channels instead of the open network. On Ethereum, BNB Chain, and Base, Sumo has a dedicated private-relay execution mode that submits orders through private endpoints, so they never sit in the public mempool where sandwich bots hunt. On Solana, relay services and staked connections play the same role. One caveat worth knowing: some fast relay paths race a protected route against an unprotected one and take whichever lands first — speed and safety are different promises, and a good stack knows exactly what each path does and doesn’t protect against.
• The jitodontfront guard. For transactions that do travel over regular RPC, Sumo attaches a special marker account recognized by Jito’s infrastructure: any bundle that tries to place its own transaction in front of yours gets rejected. It’s a cheap, clever safeguard — and almost no tools bother to implement it.

Because these paths make different trade-offs, Sumo labels every execution route it offers — protected, partially protected, or unprotected — and defaults MEV-sensitive strategies to the protected ones, while leaving you the choice when raw speed matters more. Hold your provider to the same standard: if they can’t tell you which of their paths are sandwichable, the safe assumption is that all of them are.

Own the transaction: native building, direct pools, smart routing

There's a quiet fee hiding inside many trading tools: they don't actually build transactions themselves. They call an external swap API that returns a ready-made transaction — and that convenience is paid for on every single trade, as an extra fee, a forced tip, or a platform skim baked into the transaction. It's a tax on your entire flow, and at market-maker volume it dwarfs any subscription price.

Sumo builds transactions natively — its own instruction builders for 11 Solana DEXs (Pump.fun, PumpSwap, Raydium AMM/CPMM/CLMM/Launchpad, Meteora's four pool types, Orca Whirlpool), with quoting, slippage math, and price-impact calculation done in-house against pool state. No middleman in the transaction, no per-trade toll. The same native model extends across the EVM chains and Tron.

Routing deserves the same scrutiny. The overwhelming majority of projects — comfortably 99% — have one pool that matters. For them, direct pool execution is strictly better: fewer moving parts, lower latency, no aggregator fee, no risk of a router taking a scenic path through your own liquidity. But some tokens genuinely live on multiple pools across multiple venues, and for those Sumo flips to aggregator mode: routing through Jupiter, DFlow, or OKX on Solana — and 0x or Uniswap’s routing API on the EVM chains — so large orders split intelligently across venues for the best all-in price, while Sumo still owns the compute budget, priority fees, account setup, and signing. Direct where direct wins, aggregated where routing wins. A tool that only does one of these is making the choice for you, and for someone it's the wrong one.

Millisecond data or stale data — there's no third option

Execution quality starts before the trade: with how fast you find out something happened. If your tool learns about a buy in your pool by polling an API every few seconds, you're reacting to history.

Sumo's market data comes from a dedicated ingestion service, written in Rust, that subscribes directly to the chain over streaming gRPC — the same class of firehose the serious trading firms use — scoped precisely to the pools you're watching. Incoming transactions are parsed with hand-written binary decoders in under a twentieth of a millisecond and published to in-memory streams, with no database or disk write anywhere on the hot path. Measured end to end, a swap that lands on-chain becomes an event your strategies can act on in tens of milliseconds — and the full loop from someone else's buy to your counter-trade hitting the wire is budgeted at half a second. If the stream drops, it reconnects and replays exactly what was missed, so a network blip never becomes a blind spot. Equivalent streaming pipelines run for the EVM chains and Tron, feeding the same trade streams and the same UI.

Two things fall out of this design. First, the live charts and the trade feed in the panel are built from the same stream your strategies trade on — what you see is literally what the engine saw, not a third-party chart with its own delay. Second, latency is treated as a measured quantity, not a vibe: Sumo ships an internal probe that benchmarks streaming endpoints per region — delivery gap, slot lag, handshake time — and infrastructure gets placed where the data says, not where the marketing says.

Wallets that know when to stop

Here's a hidden cost almost nobody audits: wallets that keep trying. A wallet runs low on quote currency, and a naive bot happily keeps submitting buys with it — failing, paying gas, and trying again, all day, until a human notices. Multiply by fifty wallets and a week of runtime, and "cheap" tooling has quietly burned a real budget on transactions that could never succeed.

Sumo treats wallet health as the engine's job:

• Proactive warnings with suggested fixes. Sumo continuously checks every active wallet against what its strategies will actually need — gas for fees, quote for buys, tokens for sells — and warns you before anything fails, escalating from warning to critical as the buffer shrinks. Each alert comes with a ready-made fix: swap a small, per-wallet-sized amount of the wallet’s stablecoin balance into gas, or archive the wallets that can’t be refilled. The payoff is double — you don’t miss trades because a wallet quietly ran dry, and you don’t spend gas on doomed transactions finding out.
• Automatic benching. A wallet that fails with insufficient balance three times in a row is automatically archived — pulled out of the trading rotation, with a notification telling you which wallet and why. One successful trade in between resets the count, so a healthy wallet is never benched over a transient hiccup. If a strategy runs out of usable wallets entirely, the strategy itself is parked rather than left spinning.
• Drain before benching. Optionally, a wallet that can no longer afford its configured sell will make one final trade sized to its actual remaining balance — sweeping the dust into your treasury instead of stranding it.
• Simulate before spending. Transactions are simulated before submission; a trade that would fail on-chain is cancelled at the simulation stage, where it costs nothing, instead of landing as a failed transaction that still pays fees.
• Small leaks, plugged. Temporary wrapped-SOL accounts are closed after use so their rent comes back; token-account creation is idempotent so it can never double-pay; every wallet keeps a reserve so operations never leave it unable to pay its own way out.

None of these is glamorous. All of them are the difference between a fleet of wallets that compounds and one that evaporates by a thousand cuts.

Security is table stakes (and mostly isn't offered)

A market-making tool holds the keys to wallets with real money in them. That sentence should end the conversation with most tools on the market — Telegram bots where one leaked session drains everything, browser tools holding keys in local storage, platforms whose "security page" is a paragraph of adjectives.

The bar to demand: private keys and seed phrases encrypted with envelope encryption (each seed sealed by its own AES-256-GCM key, which is itself sealed by a master key), with signing isolated in a dedicated service — in Sumo's case a separate Rust process that is the only component able to decrypt anything, reachable only by explicitly allowlisted internal services on an isolated network path. Keys never appear in the application database, in logs, or in any API response; signing requests go in, signatures come out. Tenant isolation is cryptographic, not just a database filter: your organization's identity is baked into the encryption itself, so one tenant's data is mathematically undecryptable in another's context. On top sit role-based access (analysts can look but not trade; trading and treasury actions require explicit roles) and audit logs of every sensitive operation — written before the operation completes, not after.

The full design is public in Sumo's security documentation — which is itself a signal worth checking for. A provider that won't describe its key handling in writing is telling you something.

What we deliberately don't do (and why)

A feature list only tells you half of a team's judgment. The other half is what they evaluated and turned down.

We don't run our own validator. It sounds impressive, and buyers occasionally ask for it. But transaction landing on Solana is governed by stake-weighted quality of service (SWQoS): validators get network bandwidth in proportion to their stake, and an unstaked validator gets roughly none. Running your own node without a large stake behind it improves nothing — the effective route to priority bandwidth is access through heavily-staked infrastructure, which is exactly what Sumo's premium submission paths are. Paying for a validator would be paying for theater.

We don't submit directly to leader TPUs. Same analysis, same conclusion: without significant stake, direct-to-leader submission gets you deprioritized traffic and costs you the MEV protection and retry infrastructure of the proper paths. We evaluated it and wrote it off.

We don't pre-emptively throttle ourselves. Many stacks put a rate limiter in front of every RPC call to avoid provider limits — adding latency to every request to solve a problem that occurs on a tiny fraction of them. Sumo reacts instead: a provider that returns rate-limit errors goes into a penalty box and traffic shifts to the others, at zero cost to the requests that were never going to be limited. In trading, latency you add yourself is the most embarrassing kind.

Nine questions to ask before you buy

Put every provider — including us — through this list. A good provider answers all of them specifically; a reseller of someone else's infrastructure usually can't.

Market making is a business of accumulating small edges and refusing small leaks. The strategy you run matters — we've written about counter trading and launch tooling before — but the strategy only ever performs as well as the execution underneath it. Choose the stack the way you'd choose a counterparty: assume every claim is marketing until you've seen the mechanism.

We built Sumo to pass every row of that table:

• Fills you can count on — 99.5%+ landing, next block, on MEV-protected paths by default. The two costs that hurt most — missed fills and sandwich losses — handled first.
• No toll on your flow — every transaction built natively, so no builder fee, forced tip, or skim rides along on each trade, and priority fees are priced from live data instead of panic.
• See everything in real time — every trade in your pool tagged for MEV, arbitrage, and who is actually on the other side. No other market making tool shows you this.
• Wallets and keys that mind themselves — warnings before wallets run dry, automatic benching when they can’t trade, and keys sealed in an isolated signing service nothing else can read.

One stack, 29 DEXs, 6 chains. See it on your own token at app.sumo.trade.