The five classes are sniper, copy trading, volume and market activity, market making, and arbitrage. A sniper optimises for one early entry. A copy bot outsources the decision to another wallet. A volume tool optimises for sustained distributed flow. A market maker earns spread and carries inventory. An arbitrage bot needs atomic execution across venues. Everything else is one of these with a different interface.
The five axes we classify on
Feature lists do not discriminate between products, because every vendor lists the same features. What discriminates is the shape of the problem each class is solving. We use five axes throughout this page, and they are the same five axes used in the matrix further down.
- Goal. The single quantity the software is trying to maximise or hold steady. If you cannot state it in one sentence, the tool has no design centre.
- Timing sensitivity. How much value evaporates per unit of delay. This determines whether infrastructure spending is justified.
- Capital shape. Not the amount but the structure: one lump, many small parcels, a persistent inventory, or a float that must be available on both sides at once.
- Venue dependency. Whether the strategy dies when one venue changes its program, its fee, or its migration behaviour.
- Dominant failure mode. The way this class loses money when nothing exotic happens. Ordinary failure is far more expensive over time than dramatic failure.
Reading a product through these five axes takes about ten minutes and eliminates most category errors before any money moves.
Class one: sniper
A sniper watches for a market to become tradable and buys into it immediately. Its goal is entry price relative to the market's opening moments, and it is the most latency-sensitive class by a wide margin: value decays over hundreds of milliseconds, not minutes.
Capital shape is many small parcels, because the class has a high loss rate per attempt and depends on a small number of outcomes covering the rest. Venue dependency is severe, since detection logic is written against a specific launch program and breaks when that program changes. The dominant failure mode is not the dramatic rug: it is the accumulated cost of entries that landed correctly into markets that never developed, plus the transactions that never landed at all.
Snipers are the class most often bought by people who have not yet measured anything. The full mechanism, including what this class structurally cannot do, is in Solana sniper bots explained.
Class two: copy trading
A copy bot subscribes to the activity of one or more wallets and reproduces their trades in your own. The goal is replication fidelity: matching the target's exposure closely enough that your outcome resembles theirs.
Timing sensitivity is moderate but asymmetric, and this asymmetry is the whole story of the class. You detect the target's entry after it has landed, so you buy into a pool their own buy has already moved. You detect their exit the same way, which means you sell after the price impact of their sell. Structurally, you enter worse and exit worse than the wallet you are copying, and the gap widens with the target's position size relative to pool depth.
Capital shape is a proportional mirror of another portfolio, which is why sizing rules matter more than speed here. Venue dependency is low, because you follow a wallet rather than a program. The dominant failure mode is copying a wallet whose edge is not reproducible: airdrop farming, insider allocation, or a market maker's inventory management that looks like conviction from outside.
Wallet leaderboards are ranked on realised history. Any wallet visible on one has already had its best period. The interesting question is not what the wallet returned last month, but whether its trades are reproducible by someone who sees them one block late and cannot access the same allocations.
Class three: volume and market activity
This class does not chase a single entry. It generates continuous trading activity in a market over a defined period, distributed across many wallets and, in the more capable implementations, across several venues. The goal is a sustained flow profile rather than a price outcome, and that changes every design decision downstream.
Timing sensitivity is low per action and high in aggregate: no individual swap needs to land in a specific slot, but a run that loses a third of its transactions to failed landing is paying for work it did not receive. Capital shape is a working float that cycles, with a per-wallet minimum imposed by rent-exempt account balances and fee headroom. Venue dependency is medium and manageable, because a well-built system treats a venue as a routing target rather than an assumption.
The concrete version of this class is easier to understand than the abstract one. A platform offering multi-venue volume automation exposes the parameters that define the category: how many wallets participate, how the flow is spread across time, which venues are in the route set, and what the fee model charges against the flow it produces. Those four controls are the class definition made visible, and they are the same controls you should demand to see in any implementation before funding it.
The dominant failure mode is cost leakage. Each individual swap looks cheap; the aggregate of fees, price impact, failed transactions and per-wallet rent is not. Anyone considering this class should price the run before starting it, using the six cost lines in the cost of running automation.
Class four: market making
A market maker quotes both sides and earns the spread while managing the inventory it accumulates. On Solana the classic order-book version exists, but a large share of practical market making is really automated liquidity provision and rebalancing around an AMM position.
The goal is spread capture net of inventory risk. Timing sensitivity is continuous rather than event-driven: quotes must be refreshed or ranges adjusted as the reference price moves, so the cost of being slow is adverse selection rather than a missed entry. Capital shape is the demanding part, because the strategy needs both sides available simultaneously, and the capital is locked in the position rather than cycling.
Venue dependency is high, since the economics depend on the exact fee tier and the pool mechanics. The dominant failure mode is inventory drift: the maker ends up holding the asset that fell, having sold the one that rose, and the accumulated spread does not cover it. This is the class where the arithmetic is least forgiving and where an appealing interface hides the most.
Class five: arbitrage
An arbitrage bot closes a price gap between two venues or two routes. The goal is a risk-free spread, and the word risk-free carries the entire load, because it only holds if both legs execute or neither does.
Timing sensitivity is extreme, and unlike sniping, the competition is other professionals rather than retail. Capital shape is a float that must be pre-positioned across venues or borrowed atomically within the transaction. Venue dependency is total by definition.
The dominant failure mode is a half-filled pair. If leg one lands and leg two does not, the operator now holds an unintended directional position at a price they did not choose. This is why atomicity is the central engineering requirement: the two legs are pushed into a single transaction where possible, or into an all-or-nothing bundle where a single transaction cannot hold both. If neither is possible, the honest description of the strategy is a fast directional bet.
The comparison matrix
The same five classes on the same five axes. This table is the reference version of everything above.
| Class | Goal | Timing sensitivity | Capital shape | Venue dependency | Dominant failure mode |
|---|---|---|---|---|---|
| Sniper | Earliest possible entry into a new market | Extreme, decays in hundreds of milliseconds | Many small parcels, high per-attempt loss rate | High: written against a specific launch program | Landed entries into markets that never develop |
| Copy trading | Replicate another wallet's exposure | Moderate but asymmetric on exits | Proportional mirror of another portfolio | Low: follows a wallet, not a program | Copying an edge that is not reproducible |
| Volume and market activity | Sustained distributed order flow | Low per action, high in aggregate | Cycling float across many funded wallets | Medium: venues are routing targets | Cost leakage across fees, impact and failures |
| Market making | Spread capture net of inventory risk | Continuous; slowness means adverse selection | Both sides locked in position simultaneously | High: fee tier and pool mechanics decide the maths | Inventory drift outrunning accumulated spread |
| Arbitrage | Close a price gap between venues or routes | Extreme, against professional competition | Pre-positioned float or atomic borrow | Total: the strategy is the venue pair | One leg lands, the other does not |
Where the categories genuinely overlap
The classes are distinct as objectives but share infrastructure, and that shared plumbing is why one vendor can plausibly offer several of them. All five need the same four components: a data path that reports market state quickly, a builder that turns a decision into a valid transaction, a submission and retry layer that gets it landed, and an accounting layer that records what actually filled.
That shared foundation is a useful evaluation shortcut. If a vendor's execution layer is opaque, it is opaque for every class they sell, and the class you buy will inherit that opacity. When a product exposes landing rate, retry behaviour and realised versus quoted price for one strategy, it is probably capable of exposing them for the others. When it exposes none, the strategy label is decoration.
Overlap also appears in the strategies themselves. A sniper that scales into a position over several minutes has borrowed from market-activity design. A market maker on a thin pair is doing a slow, continuous form of arbitrage against the wider market. A copy bot restricted to first buys into new pools is a sniper with an outsourced trigger. None of this is dishonest, but it means the label on the box tells you less than the parameters inside it.
Choosing by objective, not by label
Start from what you actually want to happen, then read across. This table is deliberately blunt, including in the cases where the honest answer is that no bot class fits.
| What you actually want | Class that fits | What people buy instead | Why the substitute disappoints |
|---|---|---|---|
| To be early into brand-new markets | Sniper | Copy bot following "early" wallets | You are one block behind a wallet that is already in |
| To follow a strategy you cannot write yourself | Copy trading | Sniper with aggressive filters | Filters encode your judgement, which was the missing part |
| Continuous, visible activity in one market | Volume and market activity | Sniper run repeatedly by hand | No distribution logic, no wallet management, no cost model |
| Yield from providing liquidity | Market making | Passive LP with no rebalancing | Inventory drifts and the position quietly becomes directional |
| Low-risk return from price differences | Arbitrage | Two manual swaps on two venues | Without atomicity it is a directional bet with extra fees |
| To stop losing money on manual trades | None of them | Whichever bot is most advertised | Automation increases the frequency of an unchanged decision process |
The last row is the important one. Automation does not improve a strategy; it executes it more often and more consistently. A process that loses slowly by hand loses faster when automated, and it does so while paying an additional infrastructure and fee bill.
What the marketing labels hide
Three specific patterns show up often enough to be worth naming, because each one is a category error dressed as a feature.
"All-in-one" suites
A product offering all five classes is telling you it has built the shared plumbing and layered five strategy configurations on top. That can be genuinely efficient. It also means the depth of any single class is bounded by the generality of the underlying engine, so the correct question is which class the engine was originally built for. The answer is usually visible in which settings are detailed and which are a single toggle: a suite built on a Solana trading volume bot engine will expose wallet counts, timing distribution and venue routing in detail while reducing its sniper mode to two fields, and that asymmetry is more informative than the feature list.
Speed claims without a denominator
Latency figures quoted without saying what was measured, from where, and over what sample are unfalsifiable. The measurement that matters to a user is end-to-end: from the on-chain event to a confirmed signature, expressed as a distribution rather than a best case. Anything else describes a component, not an outcome.
Strategy names as differentiation
Proprietary-sounding mode names usually map to one of the five classes with two or three parameters preset. Asking which class a mode belongs to, and which parameters it fixes, converts marketing into specification in a single question. If the answer is not forthcoming, run the vendor through the nine criteria in evaluating a trading bot before spending anything.
Classification is not an academic exercise here. It determines what infrastructure you need, how much capital the strategy consumes before it can work at all, and which failure you should be instrumenting for. Get the class right and the vendor question becomes tractable; get it wrong and no amount of vendor diligence rescues the outcome.