Why Bundled Transactions Land Together (or Not at All)

Say you set up a launch with a dev wallet and ten buyers. Wallet seven was funded with 0.5 SOL for a 0.5 SOL buy and nothing extra. You press launch on mainnet.

The coin is not created. The dev wallet does not buy. Wallets one through six and eight through ten do not buy. Nothing appears on chain at all. One wallet missing a few thousandths of a SOL stopped the whole thing.

That is not a bug. It is exactly the property that makes bundles worth using, and it is worth understanding why it works that way.

#The short answer

A Jito bundle is treated as one unit from the moment it reaches Jito's block engine to the moment a validator puts it in a block. Two rules apply to that unit:

• Order. The transactions run in the order they were listed, one directly after another.
• Atomicity. If any transaction would fail, all of them are thrown away.

Put those together and you get the behavior launches rely on: either your create and every buy land in one block, in your order, or the chain looks exactly as it did before you pressed the button.

#How does the bundle stay in one piece?

There are two checkpoints, and either one can reject the whole bundle.

1. 1

   Simulation at the block engine

   Before a bundle is forwarded, the block engine simulates it from start to finish. If transaction 4 of 5 errors, the bundle never reaches a validator.

2. 2

   Execution at the validator

   A Jito-enabled validator runs the bundle's transactions back to back. If one fails at this point (state can change between simulation and execution), the validator discards the results of the earlier ones too.

3. 3

   Commit or discard

   Only if all transactions succeed are their changes written into the block. Otherwise the bundle leaves no trace, not even a fee.

Normal Solana transactions don't work like this. Each one is independent: it succeeds or fails on its own, and a failed one still pays its base fee. Bundles add a layer on top that groups several transactions into a single pass or fail decision.

#What does atomic mean for a launch?

For a pump.fun launch, atomicity gives you three things at once.

No half launches. You never end up with a coin that exists but only has the dev buy, with your other wallets left out while bots move in.

No one in between. Because the transactions run back to back, there is no gap between the dev buy and buyer one, or between buyer one and buyer two, for an outside transaction to fill.

Predictable prices. Each buy on a bonding curve raises the price for the next. Since the order is fixed, a tool can quote each wallet against the price the previous wallets will leave behind. DevBundler does exactly this, so the estimated share of supply shown per wallet matches what actually lands.

#The other side: one weak link sinks everything

Atomicity cuts both ways. Any single problem in any single transaction stops the whole launch. In practice, these are the usual culprits:

This is why DevBundler blocks the launch button when any wallet is short, flags it in red in the launch table, and refuses buys that would sell out the whole bonding curve. It also runs one fast check right before sending: pump.fun reachable, coin address unused, balances, curve not sold out. If that check fails, nothing is sent. Catching a problem there is far better than having the bundle quietly dropped.

#What a bundle does not protect

It is easy to read "atomic" as "safe from bots". It is narrower than that.

The bundle protects the sequence, not the market. As soon as your last transaction finishes, the coin is like any other on pump.fun. Anyone can trade it.

#How can you confirm a bundle landed together?

Open any of the launch transactions on a Solana explorer and look at the slot number. Then open the others. In a bundled launch, every one of them shows the same slot, and they appear in the block in the order the bundle listed them, with the create first.

If you ran the same launch on devnet, you will see something different: several slots, because there is no Jito on devnet and the transactions go out one by one. That also means a devnet launch can partly succeed, for example the create landing while a later buy fails. It is a good way to see why atomicity matters before you rely on it with real SOL.

#When a launch bundle does not land

If nothing happened after you pressed launch, the bundle was dropped and your SOL is untouched. Find the cause (usually a balance, slippage or an expired blockhash), fix it and send again. DevBundler shows the reason on the project page with a "Launch again" button. What to do when a launch fails goes through each case.

For the path a bundle takes through Jito's infrastructure, read how Jito bundles work on Solana. To see how the bundle approach compares with sniping your own coin or clicking buys by hand, read bundle vs snipe vs manual buys.