Every launch has a small number of blocks where the price is still close to where it started. After that, buying is just trading — you are paying a price someone else already moved.
The gap between those two situations is a handful of slots. Whether you land inside it or outside it is the entire game.
What "First Block" Actually Means
There is a common misunderstanding worth clearing up. "First block buy" does not mean your transaction is in the same block as the token's creation. It usually cannot be — you learn the token exists by observing that block, which means the earliest you can act is the block after.
★Realistically you are competing for blocks two through four.★ Everyone who knows about the launch is submitting into the same narrow window, which is why it is the most congested moment the token will ever see.
So the question is not "can I be first" but "can I land before the price has moved past my edge."
Where the Time Goes
① token creation lands in block N
② you observe it (block N, +parse time)
③ you decide and build (your code, sub-millisecond)
④ you submit (one network hop)
⑤ your buy lands (block N+2 if you are quick)
Steps 2 and 3 are yours and they are fast. ★Steps 4 and 5 are network, and they are where the slots go.★
The trap is that step 2 is the only one with obvious optimisations — faster WebSocket, better parser, dedicated stream — so it gets all the attention while contributing the least.
If detection is already working and step 5 is the problem, a free BoltTx key is a one-line change. The rest of this covers what you control.
The Pre-Signing Trick
The one genuine latency win in your own code is to have everything ready before the launch fires.
// Cached and refreshed in the background, never fetched on demand.
let cachedBlockhash = await connection.getLatestBlockhash("confirmed");
setInterval(async () => {
cachedBlockhash = await connection.getLatestBlockhash("confirmed");
}, 5_000);
// Warm the connection so no TLS handshake happens in the hot path.
await connection.getSlot();
★A network call between "I see the launch" and "I submit" costs you a slot you will never get back.★ An on-demand getLatestBlockhash, a DNS resolution, a TLS handshake — each one is a round trip you can eliminate by doing it in advance.
What you cannot pre-sign is the transaction itself, because the mint address does not exist until the launch. But everything else can be ready: the connection warm, the blockhash fresh, the fee logic computed, the instruction template built.
Fees During a Launch
A launch is the most contested moment on that account. A fee that works fine in normal conditions does nothing here.
import { ComputeBudgetProgram } from "@solana/web3.js";
// Fees are contested per account. During a launch, every sniper
// is writing to the same accounts you are.
const recent = await connection.getRecentPrioritizationFees({
lockedWritableAccounts: [curveAccount, yourTokenAccount],
});
const fees = recent.map((r) => r.prioritizationFee).sort((a, b) => a - b);
const median = fees[Math.floor(fees.length / 2)] ?? 0;
instructions.unshift(
ComputeBudgetProgram.setComputeUnitPrice({
// The recent median reflects normal conditions, not a launch.
// Treat it as a floor and multiply.
microLamports: Math.max(median * 3, 10_000),
}),
ComputeBudgetProgram.setComputeUnitLimit({ units: 120_000 }),
);
★Note the setComputeUnitLimit instruction.★ Without one you are charged against a default well above your real usage, which wastes budget at exactly the moment fees are highest.
Sizing Against Thin Liquidity
In the first blocks, the pool is shallow. Your own buy moves the price meaningfully, and so does everyone else's.
This produces a counterintuitive result: ★buying more can cost you more per token than buying less★, and the effect is largest in exactly the blocks you were trying to reach.
Work out what your size does to the price before you send it, using the curve or pool state you just read. If your buy alone moves the price 8%, you have to be right by more than 8% for the trade to make sense — and that is before anyone else's buy lands.
Slippage Is Not the Dial You Think
The pattern people fall into:
Tight tolerance → transaction fails, base fee still paid
Loose tolerance → you fill at a price that removes the edge
Both lose. ★The variable that actually matters is how many slots you take★, because the price movement between detection and inclusion is what the tolerance is absorbing.
If you are consistently landing four or five slots late, no tolerance setting fixes it. Tighten the slot count first, then set tolerance to whatever the remaining movement requires.
What Landing Looks Like
Real transactions through our delivery nodes: median confirmation 336ms — under one slot.
Two slots after detection puts you in the window where launch prices are still moving in your favour. Five puts you in ordinary trading, competing on price rather than on speed.
★During a launch that number stretches★ — most transactions are unaffected while a minority take noticeably longer. Snipes live in that minority by definition, because a launch is the congestion event.
Telling Execution From Strategy
The most useful thing you can do is separate two questions that look identical from a P&L statement.
log({
mint,
detectSlot,
landSlot,
slotGap: landSlot - detectSlot, // execution
priceAtDetect,
priceAtFill,
entryGapBps: Math.round(((priceAtFill - priceAtDetect) / priceAtDetect) * 10_000),
exitPnlBps, // strategy
});
★If slotGap is small and you still lose, the problem is which launches you pick, not how you execute.★ If slotGap is large, no amount of token selection compensates.
Most people assume the first and have the second. Measuring takes an afternoon and saves months.
The Part Worth Being Honest About
Launch sniping is a crowded activity. Everyone reading this sees the same launches with the same public information, and the edge from any single technique is small.
What is reliably true is that ★a large share of bots are badly tuned on submission★ — hardcoded fees, a single attempt, a stale blockhash, a general-purpose endpoint under congestion. Fixing those moves you ahead of most participants. It does not make you first, and anyone promising that is selling something.
Where BoltTx Fits
We handle step 5. Not detection, not launch feeds, not indexing.
Submissions route through our own delivery nodes in four regions with stake-weighted routing and no public mempool exposure, so a transaction is not observable in transit before it lands. You sign locally — we never hold funds, never sign, and never modify transaction contents.
The tip travels inside the transaction, paid on chain from your own wallet. If the transaction reverts, the tip reverts with it, because that is how Solana handles atomic transactions. You pay only on transactions that reach the chain.
Get a free API key. No monthly fee:
// Pick the region closest to where your bot runs
const connection = new Connection("https://la.bolttx.io/?api-key=YOUR_KEY");
Then log slotGap across a few real launches and compare against whatever you use now.
FAQ
Can I actually buy in the first block of a Solana token launch? Not the creation block itself, in practice. You learn the token exists by observing that block, so the earliest you can act is the block after. Competition is for the next few blocks, which is where the price is still close to the start.
How many slots do I have before a launch price moves? It varies with liquidity and how many bots are watching. On an active launch, meaningful movement happens within the first few blocks, which is why the difference between landing at slot 2 and slot 6 is often the whole trade.
Why do my launch snipes always fill at a bad price? Because you are landing after other buys have already moved the price. Log the price at detection and at fill. If the gap is large while your slot gap is small, you are choosing launches that move too fast to follow rather than executing badly.
Should I pre-sign transactions for a launch? You cannot pre-sign the buy itself, since the mint does not exist until the launch. You can pre-warm everything else: a cached blockhash refreshed on a timer, a warm connection, and your fee logic ready to run.
What priority fee works for launch sniping? Derive it from recent fees on the accounts you write to, then multiply for the contested case. The recent median reflects normal conditions; a launch is the least normal moment that account will ever see.
Does buying a larger size help me get filled first? No, and it usually hurts. Size does not affect scheduling, but it does move the price against you in a shallow pool. Larger buys pay a worse average price in exactly the blocks you were trying to reach.
Why does my sniper work on some launches and not others? Liquidity depth and competition vary. A quiet launch gives you several blocks of room; a heavily watched one gives you almost none. Look at whether failures cluster on the busiest launches before assuming a code problem.
How do I keep a blockhash fresh without adding latency? Refresh in the background on a short timer and read from cache in the hot path. Fetching on demand adds a round trip between detection and submission, which is the one place you cannot afford one.
Is first block sniping profitable? For some participants, on some launches. The edge comes from execution quality and launch selection together. Teams treating submission as an afterthought are usually funding the ones that do not.
What is the difference between sniping and front running on Solana? Sniping acts on a launch already visible on chain — public information. Front running acts on knowledge of a pending transaction before inclusion. Solana has no public mempool, so the second is not available the way it is on mempool chains.
Should I use multiple wallets to snipe a launch? It multiplies your fee cost and does not improve any individual transaction's chance of landing. The scheduling factors are per-transaction, so several mediocre submissions do not add up to one good one.
Why do I see the launch instantly but land three slots later? Detection and submission are different problems. Parsing a log is sub-millisecond; getting bytes to a block producer under congestion is a network path with several hops, and that is where the slots accumulate.
How do I know if my RPC is the bottleneck? Compare landing rate during quiet periods against launch windows. If it holds up when calm and falls under load, with fresh blockhashes and live fee calculation, the submission path is what is left.
What compute unit limit should a launch buy use? Simulate during development to find real consumption and set slightly above it. Leaving the default means paying against a much higher figure, which is most expensive during launches.
Does landing in block 2 versus block 4 really matter? On an active launch, yes — that is often several percent of price movement. On a quiet one it may not matter at all. Log both and you will know which kind of launches you are actually trading.
Related Reading
- pump.fun Sniper Bot
- pump.fun API Guide
- Solana Transaction Landing
- Solana Priority Fees Guide
- Solana SWQoS Explained