Solana trading automation, classified
Most arguments about "the best bot" are arguments between different categories of software. This desk separates the classes, describes the execution path each one depends on, and publishes the criteria we use to judge them.
The starting question is never which product to buy. It is which class of automation matches the objective, and whether the operator can survive its failure modes.
What this index covers
Five classes of Solana bot, five different jobs
A tool is only fast, cheap or safe relative to what it is trying to do. These are the five categories that cover almost every product sold as a "Solana bot", with the constraint that actually defines each one.
Buys into a new market as early as it can
Optimises for detection and landing inside the first few slots after liquidity exists. Its enemy is latency and its usual loss is a fill nobody wants.
Class 01 / SniperMirrors the trades of a chosen wallet
Optimises for attribution and reaction time. It inherits the strategy of a wallet it cannot audit, including that wallet's exits, which it usually sees late.
Class 02 / CopyGenerates continuous market activity
Optimises for sustained, distributed order flow across venues rather than for a single entry. Cost control and wallet management dominate the design.
Class 03 / VolumeQuotes both sides and manages inventory
Optimises for spread capture against inventory risk. On Solana it is mostly an AMM position and rebalancing problem, not an order-book one.
Class 04 / Market makingCloses price gaps between venues
Optimises for atomicity. If the two legs cannot be forced into one transaction or one bundle, the strategy is a directional bet with extra steps.
Class 05 / ArbitrageThe full taxonomy and comparison table
Goal, timing sensitivity, capital shape, venue dependency and the dominant failure mode for every class, side by side.
ReferenceReference pieces the desk keeps current
Four pages carry most of the weight. Read them in this order if you are new: what the software is, how a transaction survives the network, why it fails, and how to judge a vendor.
Solana sniper bots explained
Sniping without a public mempool, the detect-build-sign-land sequence, and the things a sniper structurally cannot do.
Transaction landing on Solana
Leader schedules, blockhash expiry and retry design. Landing rate is the metric that separates working automation from a demo.
Eight ways a sniper bot fails
Symptom, mechanism and fix for the failures that actually show up in logs, from late detection to unhandled pool migration.
Evaluating a trading bot
Nine criteria, a weighted scoring sheet, and a small live-test protocol that costs less than the first bad fill.
Three desks, three questions
Everything published here belongs to one of three sections, because readers arrive with one of three questions: what is this thing, why did my transaction not work, or how do I not get hurt.
Bot classes
Taxonomy and comparison. What each category optimises for, who it suits, and how the categories bleed into each other in real products.
Execution
The network layer: how a signed transaction reaches a leader, what it costs to be prioritised, and where latency is actually spent.
Risk desk
Security and operational failure. Token screening, key custody, permission scope, and the incident patterns that repeat.
Before you fund anything
Three pages that cost nothing to read and prevent the losses this niche is known for. None of them are about picking winners; all of them are about not handing away control.
- Twelve pre-entry checks — mint and freeze authority, LP status, Token-2022 extensions, and a simulated sell before the buy.
- Keys, wallets and permissions — what a pasted private key grants, what a wallet connection grants, and how to size the blast radius.
- Failure modes — the eight patterns behind most "the bot lost my money" reports, with the diagnostic for each.
Where a managed console fits
Reading about execution is not the same as watching it. A managed console is the shortest way to see the surface a running system exposes: which venues it routes across, how a run is configured before it starts, what the fee model looks like when it is written down, and what telemetry comes back while orders are in flight. That surface is exactly what the checklists on this site ask you to inspect.
Two caveats, in the order they matter. A hosted platform is a custody and dependency decision, so read what the permission model actually grants before it holds anything. And a console makes operating easy, not correct: the configuration questions in the nine-criteria framework stay yours to answer.
How this index is maintained
An index is only useful if its method is legible. Here is ours, including the parts that limit what we can say.
Mechanism first
Every claim traces to a documented protocol behaviour, a public program interface, or an observation any reader can repeat with an RPC endpoint and a block explorer.
Classes, not leaderboards
We compare categories and criteria. We do not publish vendor scores, review counts or performance tables, because we cannot verify a private execution engine from the outside.
Numbers are labelled
Protocol constants are stated as constants. Everything else is worked as clearly labelled illustrative arithmetic with its inputs visible, so you can substitute your own.
Corrections are cheap
Solana changes. When a page goes stale we amend it and say what changed rather than quietly rewriting history. The editorial policy spells this out.