Why slots are the unit, not milliseconds
Solana advances in slots of roughly 400 milliseconds. A transaction is either included in a given slot or it is not. There is no partial credit for arriving 40 milliseconds earlier within the same slot, and no penalty for arriving 200 milliseconds earlier if you were going to make that slot anyway.
This makes most millisecond marketing incoherent. A tool that claims to be 80 milliseconds faster than another is claiming an advantage smaller than the resolution of the thing being competed for, unless that 80 milliseconds happens to straddle a slot boundary, which is a matter of timing rather than a property of the tool.
The four stages where time is spent
Every sniper does the same four things in the same order. Total delay is their sum, and the largest term dominates, which is why optimising the smallest one changes nothing.
| Stage | What happens | Typical cost | Who controls it |
|---|---|---|---|
| Detection | New mint or pool observed | Slots if polling, none if decoded live | The tool |
| Screening | Contract checks run | Bounded or unbounded, by design | The tool and your settings |
| Build | Transaction constructed and signed | Negligible | The tool |
| Submission | Transaction reaches a leader | Queue position, or private | You, through routing and fees |
Read the typical cost column. Two of the four stages can cost whole slots and two are effectively free. Any speed discussion that does not say which stage it is talking about is not a speed discussion.
Detection: the stage that decides most outcomes
There are two ways to learn that a launch happened. You can decode program logs as the slot is processed, which means the event reaches your screener in the slot it occurred. Or you can poll an API that aggregates launches, which means you learn about it whenever that service publishes, typically slots or seconds later.
The gap between those two approaches is larger than every other optimisation in the stack combined. A tool polling a third-party feed cannot be fixed by a faster server, a closer region, or a higher priority fee, because the information arrived late and nothing downstream can recover that.
How to tell which one you are using
- Ask which program IDs the listener subscribes to. A real answer names them; polling tools cannot name any.
- Ask what happens when a new launchpad appears. Log decoding needs the program decoded; an aggregator needs the aggregator to add it.
- Ask whether launches from smaller venues appear at all. Aggregators cover what is popular, which is exactly where competition is worst.
Screening has to have a time budget
Screening is where a sniper earns most of its value, because the trades it prevents cost nothing and the trades it allows are the only ones that can go wrong. But every check takes time, and a check that runs after the slot has passed protected nothing.
The design question is not which checks to run but which checks fit in the budget, and what to do when they do not. A screener that runs an open-ended list will sometimes be correct and late, which is the same as being wrong.
- 1Run cheap structural checks firstMint authority, freeze authority and LP disposition can be read from account state without simulating anything.
- 2Run expensive checks only if the cheap ones passedA sell simulation is worth its cost on a candidate that already survived; it is wasted on one that failed at step one.
- 3Cap the total budget explicitlyThe screener should know how long it has and return a decision within it, including the decision to skip.
- 4Treat skipping as a valid outcomeNot taking a launch because it could not be screened in time is a correct result, not a failure.
Submission: queued or private
Once the transaction exists, the remaining question is how it reaches a leader. Submitted through a public path, it sits somewhere other participants can observe it, and on a thin new pool the intent itself is information.
Submitted as a private bundle through a block engine, it is not visible before landing and it executes as a unit. That is what the tip pays for, and it is the one place where paying more genuinely changes the outcome on contested launches.
| Public path | Private bundle | |
|---|---|---|
| Visible before landing | Yes | No |
| Cost | Priority fee only | Priority fee plus tip |
| Partial execution | Possible | All or nothing |
| Worth it | Quiet launches | Contested launches, thin pools |
Where speed meets everything else
- The full sniper bot guideDetection, screening, execution and exits end to end
- What a sniper bot costsPriority fees and tips are the price of landing early
- Are sniper bots profitableWhy speed is the weakest durable edge
- How to judge a sniper botTurning a speed claim into a checkable question
How to read a speed claim
| Claim | What to ask | What a weak answer looks like |
|---|---|---|
| Fastest sniper bot | Fastest at which stage | No stage named |
| Sub-100ms execution | Measured from what to what | No start or end point given |
| Covers 40+ venues | Which program IDs are decoded | A logo grid instead of IDs |
| Instant detection | Log decoding or API polling | Vagueness about the data source |
| Never misses a launch | What the fill rate is | Win stories instead of a rate |
The pattern is consistent: a real capability can be described in terms of where it starts and where it ends. A decorative claim cannot, which is why it gets stated as a number without a boundary.
Questions people ask
These come up in the ticket queue often enough to answer once, properly. If yours is not here, send it over and it probably ends up on this page.
The useful measure is whether it acts in the launch slot or a later one. Solana slots are roughly 400 milliseconds, so speed differences smaller than that only matter when they happen to cross a slot boundary.
Key takeaways
- Solana advances in slots of roughly 400 milliseconds, so slots are the unit of sniper speed.
- Delay is spread across detection, screening, build and submission, and the largest term dominates.
- Detection is usually the real bottleneck: log decoding arrives in-slot, API polling does not.
- A venue your tool does not decode has infinite detection latency, so coverage is part of speed.
- Screening must have an explicit time budget, with cheap structural checks running first.
- Private bundle submission improves fill rate on contested launches rather than raw latency.