Bundling explained
A bundle is a group of transactions that land together, in the order you set, inside one slot. This page explains why that is the difference between a launch you control and a launch someone else front runs.
The problem a bundle solves
Send a create transaction on its own and it becomes public the moment it is broadcast. Anyone watching the network sees a new token appear. Send your buys a moment later and they arrive behind everyone who was watching.
The gap between the create and the first buy is measured in fractions of a second, and it is enough. Automated buyers exist precisely to fill that gap. They buy the opening supply, your own buys fill at a worse price, and the launch you planned is not the launch you got.
The one sentence version
A bundle removes the gap by making the create and every buy land in the same slot, or not land at all.
What a slot is, and why one matters
Solana divides time into slots. Each slot has one leader, a validator whose turn it is to build the block. Everything that happens in that slot is ordered by that leader.
If your create and your buys land in the same slot, in the order you specified, then nothing can be inserted between them, because there is no between. The ordering inside a block is fixed once the block is built.
If they land in different slots, however close, everything that happened in the gap happened before your buys. That is the entire attack surface, and it is why the single slot target is not a performance feature. It is the product.
About the network
Slots are roughly four hundred milliseconds. That number is not a promise about RELICLAUNCHER and it is not a claim about how fast anything here runs. It is just how Solana is built.
How the bundle is assembled
- 01
The create goes first
The mint, its metadata and any authority revocations are the opening instruction. Everything after it depends on the token existing.
- 02
Buys are ordered
Every funded wallet gets its buy instruction, placed in the order you set. Primary before Secondary by default, because that is the order most launches want filled.
- 03
Instructions are packed into transactions
A Solana transaction has a size limit, so a launch with many wallets becomes several transactions rather than one enormous one. The packing is done for you.
- 04
Transactions are ordered into the bundle
The bundle is the ordered list. This is the unit that is submitted, and the unit that either lands or does not.
- 05
A tip is attached
The bundle carries a tip that pays for inclusion. It goes to the network, not to RELICLAUNCHER, and it is shown separately in the cost breakdown.
Block engine submission
A normal transaction is broadcast to the network and travels the public path, where anyone running a node can see it before it is confirmed. That visibility is what front running feeds on.
A bundle is submitted through a block engine instead. The block engine hands the ordered set to the slot leader directly, which means it is not sitting in public view while it waits.
Visible before it lands
Broadcast to the network, propagated between nodes, observable by anyone watching. Ordering is whatever the leader decides.
Delivered as one ordered set
Submitted through a private route to the leader. The order you set is the order that executes, and the set lands together or not at all.
Retry and partial failure
All or nothing
The property that matters most is atomicity. A bundle does not half execute. If any transaction in it fails, none of it is applied, and you are not left holding a token that exists with buys that never happened.
Why a bundle might not land
- The tip was too lowInclusion is competitive. A tip that does not clear what others are paying loses the slot.
- State moved underneath itThe bundle was built against chain state that changed before it arrived. A pool that shifted, a balance that moved, an account that no longer looks the way it did.
- A wallet could not payOne funded wallet was short of what its transaction actually cost, so its transaction failed, so the bundle failed with it.
- Slippage was exceededA buy would have filled outside the tolerance you set, so it refused rather than accepting a worse price.
What happens next
A bundle that does not land is retried under the policy you set rather than being silently abandoned or silently repeated. Retrying rebuilds against fresh chain state, because a bundle assembled against a state that no longer exists would fail for the same reason twice.
Read this before you retry by hand
Never respond to a bundle that appears stuck by manually sending the same buys yourself. If the original lands afterwards you have bought twice. Let the retry policy finish, and read the activity feed before you act.
What bundling cannot do
- It cannot guarantee inclusionA bundle competes for a slot. Competing is not winning, and no tip makes inclusion certain.
- It cannot hide the resultOnce the block is built, everything in it is public and permanent. A bundle protects the moment of the launch, not the record of it.
- It cannot stop the next slotSnipers who missed your slot buy in the one after. Protection rules narrow that window, and nothing closes it entirely.
- It cannot make a token succeedOrdering is the only thing being protected here. What happens to the price afterwards is not a technical question.
Protection rules
The four rules, what each one covers, and when turning one off is reasonable.