If you're running a Solana launchpad — IDO platform, presale platform, NFT mint launcher — your infrastructure is judged at one specific moment: the launch itself. That moment is concentrated traffic, high stakes, and unforgiving. Things that work fine in normal conditions break under launch load.
This piece covers what's actually involved in running launch infrastructure reliably: burst capacity, sandwich protection during launches, transaction prioritisation, and the decisions that distinguish good launches from disasters.
What Makes Launches Hard
Three properties that combine badly:
Burst traffic. A launch generates hours or days of normal traffic in minutes. Your infrastructure has to handle 10-100x typical load instantly.
High stakes per transaction. Users have allocated money; failed transactions are visible failures. Tolerance for silent issues is zero.
Adversarial environment. Bots compete for early allocation. MEV bots target launch transactions specifically. Front-running, sandwiching, and exploitation are baseline threats.
A platform that handles normal traffic competently can still fail at launches. Different problem.
The Launch Traffic Profile
What you're actually facing during a launch:
Pre-launch: Users connect wallets, prepare positions, monitor countdown. Mostly read traffic, modest volume.
Launch moment: Users (and bots) submit purchase transactions simultaneously. Massive write traffic spike. Network congestion is at its peak.
Post-launch settling: Allocation decisions happen on-chain. Transaction success/failure becomes apparent. Customer support questions spike.
The launch moment is the technical challenge. The other phases are normal application work.
Infrastructure Requirements
What launch infrastructure needs:
Burst-tolerant write RPC. Your RPC must handle 10-100x normal traffic without degrading. P95 latency during burst is the metric that matters.
SWQoS support. The network is heavily congested during launches. Without SWQoS support, your transactions are deprioritised.
Anti-MEV protection. Launch transactions are perfect sandwich targets. Without protection, users get sandwiched on their purchases.
Predictable transaction landing. During congestion, "probably lands" isn't enough. You need consistent landing or you have to design around failure cases.
Per-signature telemetry. When something goes wrong, you need to know specifically what happened to which user's transaction.
Customer support tooling. Look up specific transactions; explain to a user what happened.
What Goes Wrong
Common launch failure modes:
Read RPC saturated. Users can't see countdown, can't check allocations, can't do basic UI things. Read RPC needs to scale too, not just write.
Write RPC degraded. Transactions take 30+ seconds to confirm. Users panic; some submit duplicates; chaos.
No sandwich protection. Bots front-run user purchases at scale. Users complain about price impact they didn't expect.
Allocation logic doesn't handle congestion. First-come-first-served logic that assumed orderly arrival breaks when transactions arrive in unexpected orders.
Customer support overwhelmed. Every confused user contacts support. Without tooling, you can't help them quickly.
Status page and communication failure. Users don't know what's happening; speculation fills the gap.
What to Build
Launch-grade infrastructure looks like:
A read RPC that scales horizontally. Or a provider that does this for you. Burst-tolerant.
A write RPC built for transaction sending under congestion. Sub-second confirmation as a design floor (not "average"). SWQoS-aware. Anti-MEV by default.
Transaction submission with appropriate retry logic. Refresh blockhash on retry, max 2-3 attempts.
Per-signature telemetry capturing what happened to every transaction. For both monitoring and customer support.
A status page for the launch. Pre-publicised; updated in real time.
Customer support tooling. Look up by wallet, by signature, by token. Show the transaction's lifecycle.
Rate limiting on your own services. Don't get DDoS'd by bots scraping your APIs.
Sandbox mode for users. Pre-launch, let users practice flows. Surfaces bugs before real money.
Sandwich Protection Specifically for Launches
Launch transactions have specific MEV exposure:
Predictable direction. Everyone is buying. Direction is known.
Predictable size. Allocation tiers create predictable size ranges.
Concentrated timing. Many transactions in seconds. Maximum opportunity for ordering MEV.
High price impact per transaction. Pool depth is shallow at launch; each buy moves price meaningfully.
Without protection, MEV operators front-run launch transactions at scale. Users get worse fills than the math should give them. The protection is at the RPC layer — Anti-MEV routing for the launch transactions specifically.
Specific Patterns That Work
Multiple submission paths for redundancy. Primary write RPC plus a secondary. If primary degrades, secondary catches.
Blockhash freshness even more aggressive than normal. Launches mean congestion means blockhash expiry happens faster.
Compute budget set generously. Failed transactions during launches are public failures.
Tip strategy adjusted for launch conditions. Higher tips during launch make sense; the validator competition is intense.
Public-facing status updates. "We're seeing congestion; here's what's happening." Beats silence.
Post-mortem published. What happened, what went wrong, what will be different next time. Builds trust.
What to Do This Week If You're Building a Launchpad
- Define your peak load assumptions. 10x normal? 100x? Plan for honestly.
- Pick a burst-tolerant write RPC. Test under simulated load before relying on it.
- Test the read RPC under burst. Reads matter for UI; ignore them at your peril.
- Build per-signature telemetry from day one.
- Build customer support tooling early. You'll need it during the first launch.
- Run a soft launch first. Smaller-stakes launch to test infrastructure.
- Have a public status mechanism ready. Status page, Twitter, whatever — but predefined.
Try BoltTx for Launch Workloads
BoltTx is built for the burst conditions launches create:
- Sub-second confirmation under congestion — design floor, not just average
- Native Anti-MEV routing — launch transactions don't get sandwiched
- SWQoS-aware delivery — validator-side prioritisation when load is heavy
- Per-signature delivery telemetry for production debugging
- Tip-based pricing — pay only on successful purchases
import { Connection } from "@solana/web3.js";
const connection = new Connection(
"https://bolttx.io/?api-key=YOUR_API_KEY",
"processed"
);
Free tier signup. For high-stakes launches, a paid tier with dedicated capacity is often justified.
FAQ
Should I run my own validator for a launchpad? Not unless you have a specific reason. Managed RPC handles validator-side complexity better than most launchpad teams can.
How much capacity do I need? Plan for 10-100x your normal traffic for the launch window. Test under simulated load before launch day.
Should I rate-limit users? Per-wallet rate limits help against bot abuse. Public-facing rate limits should be fair to legitimate users.
What's the most common launch failure? Tail latency under load. Things work great in normal conditions; fall over at peak.
Can I prevent users from getting sandwiched? At the RPC layer, yes — route through Anti-MEV routing. At the application layer, transparent fee disclosure helps users understand what they're paying.