The first block of a token launch is supposed to be the moment a public market opens. In practice, on many chains and venues, the first block is already closed by the time the public sees it. A single coordinated actor submits a bundle of transactions that add liquidity, buy a dominant share of the supply, then route the proceeds into follow-on transactions, all inside one atomic block that no one else can interleave with. By the time the second block arrives, the economics of the launch are already decided.
This is the bundle attack. It is not exotic. It is not new. And it is arguably the single most damaging launch-day pattern in the current on-chain environment, because it strips retail participants out of the opening distribution entirely.
This article walks through how bundle attacks actually work, why they are so hard to defend against with ordinary mempool discipline, why Layer 2 sequencers have not solved the problem, and what launch infrastructure has to do to give block zero back to public buyers.
What a Bundle Actually Is
A bundle is a set of transactions that a block builder commits to execute together in a specific order. Flashbots popularized the concept on Ethereum with a simple goal: let searchers submit complex multi-step strategies without worrying about their transactions being broken up or reordered by the network. The same mechanism that enables efficient arbitrage also enables launch capture, because both require atomic execution of multiple steps in a chosen sequence.
At a launch, a typical bundle looks like a four-step sequence inside a single block. Step one is the deployer transaction that adds the initial liquidity to the newly created pool. Step two is a buy from a wallet the attacker controls, executed against the freshly opened pool at the lowest possible price along the curve. Step three is one or more follow-on buys that consume additional supply before any external transaction can interleave. Step four is a routing transaction that fans the captured tokens out into a set of distribution wallets that will sell into retail demand later. The entire sequence is committed to the builder as a single atomic unit, which means no public buyer can land a transaction in between any of the four steps.
The result is that block N opens and block N closes with the launch having moved through several supply tiers, but with no external participant able to access those tiers. By the time the next block is reachable, the price is several standard deviations away from where the curve started.
Research from Flashbots and on-chain analytics from EigenPhi and Dune shows that bundled transactions routinely consume large portions of launch-block gas, leaving minimal room for independent buyers to participate at the opening price.
Bundled transactions can absorb a launch block in its entirety, leaving no opportunity for independent buyers to participate at fair prices.
Source: Flashbots bundle data, on-chain mempool traces
Why the Mempool Is Not a Defense
A common intuition is that if you hide your launch transaction well enough, bundle attackers cannot target it. This is not quite right, and understanding why explains a lot about why the problem has been so durable.
Bundle attackers do not need to read a pending launch transaction in the public mempool. They can simply watch for the moment a liquidity pool is created and race to the next block with a bundle of their own. On chains with low block times, this race is fast enough that even a team that launches from a private relay can still be overtaken if the builder they use is connected to a searcher pipeline. On chains with builder concentration, the problem is worse, because a small number of builders handle the majority of blocks and any searcher connected to those builders has a structural advantage.
A further complication is that the defense mechanisms that help elsewhere, like slippage tolerance or gas caps, do not help here. The bundle attacker is not competing on slippage. They are competing on position inside the block, and position inside the block is not something a normal user controls.
Measured losses from block-zero bundling have climbed alongside launch volume, particularly on chains with permissive private mempools.
Source: EigenPhi, Dune Analytics
Why Layer 2 Sequencers Did Not Fix This
A reasonable question is whether Layer 2 rollups have made bundle attacks easier or harder. The answer is that they have changed the shape of the problem without solving it.
Most major rollups today route transactions through a single sequencer, which is operated by the rollup team. The sequencer has total discretion over the order of transactions inside a block, which on paper looks like centralization but in practice has often been used to provide first-come-first-served ordering. That sounds protective, but it has its own attack surface. A searcher with a low-latency private connection to the sequencer, or with infrastructure colocated near it, can submit a bundle faster than any public participant, and the sequencer's "fair" ordering rule then guarantees the bundle the position it wanted.
The result is that on many L2s, block-zero capture is not less common than on Ethereum mainnet. It is just executed by a different set of actors using different infrastructure. The economics that drive the attack are unchanged, because the attack still depends on the order inside a block being a property someone can control.
The honest framing is that bundle attacks are not a Layer 1 problem or a Layer 2 problem. They are an ordering problem, and ordering problems do not get solved by changing chains. They get solved by changing the rules that determine where a transaction lands.
What Actually Stops Bundle Attacks
Defending against bundle attacks requires changing the rules of block zero itself. Three mechanisms have shown up repeatedly in launch designs that meaningfully reduce bundle capture.
The first is a protected launch window. Instead of a launch going live at block N with no constraints, the protocol enforces that block N and a small number of following blocks apply different rules. These rules can include maximum purchase sizes, per-wallet caps, or transaction-throttling mechanisms that reduce the value of capturing the block. A bundle that can only buy a tiny fraction of supply is not worth assembling in the first place.
The second is decentralized builder relationships. When a launch is wired to a single builder, that builder has an implicit pricing power over the launch. When a launch accepts transactions from a broader set of builders and relays, the cost of collusion rises. This is not a cryptographic defense, but it is an economic one, and it narrows the attack surface considerably.
The third, and strongest, is cryptographic ordering at the moment of launch. If block zero itself is ordered by a verifiable random function or a commit-reveal scheme, then no bundle can guarantee its own position. This is the approach our V2 MEV article explores in depth, because it is the same primitive that protects ordinary trading from sandwich attacks. Applied to a launch, it turns block zero from a bid-for-position auction into a coin flip among eligible participants.
Each of these mechanisms attacks a different part of the bundle equation. Caps reduce the value of capture. Decentralized builder paths increase the cost of capture. Cryptographic ordering removes the certainty of capture. Together they push the expected return from a bundle attack below the cost of running one, which is the only condition under which the attack actually stops.
How ZeroTick Fits
ZeroTick's V1 launch framework was built around exactly this failure mode. Every token launched on the platform runs under Serialized Trade Execution, the protection the docs label Anti-Bundle, which is enabled by default on both Quick Launch and Advanced Launch. The contract forbids multi-wallet calls inside a single transaction, which is the exact mechanic bundle attackers rely on. An attacker attempting a 20-wallet bundle would have to send 20 separate transactions, which normal block scheduling would intermix with other users' transactions, and the price on the curve would update after every single buy so the attacker pays incrementally more with each one. They cannot lock in a large quantity at the initial price in one atomic call.
Anti-Bundle is paired with Anti-Insider, which is always active and cannot be disabled. The contract address stays hidden until the exact moment trading goes live across all currently supported chains simultaneously, so there is no pre-launch window for a bot to stage a bundle against a known contract. For creators who want more, Advanced Launch adds optional Buy Limits (presets at $500, $1,000, and $1,500 per wallet per purchase), Anti-Whale accumulation caps, and Anti-Bot filters, each of which raises the cost of a multi-wallet strategy even if an attacker could somehow land one. Every protection is enforced at the smart-contract level for the entire bonding curve phase and surfaces on the Marketplace as a green or red indicator. Real-time Bundler Holding and Top 10 Holders metrics on every project card let users see whether a bundle strategy actually succeeded before committing capital. The same baseline carries over to the broader insider advantage and whale concentration failure modes covered elsewhere in this series, because all three share the same root cause: privileged access to block zero.
V2 raises this further. The public roadmap commits to replacing Anti-Bundle with commit-reveal intent hiding and VRF-randomized execution, which would remove the residual advantage of being fastest. V2 remains in active research with no public timeline and none of its mechanisms are live today.
Conclusion
Block zero is not a random moment. It is the single most economically important block in the life of a token, and for most of the current launch environment, it is also the most exposed. Bundle attacks are not going away on their own, because the infrastructure that enables them also enables legitimate searcher activity elsewhere.
The fix is not to close the mempool. It is to change the rules that apply when a launch is live, so that being first in the block is not a commodity you can buy. When you evaluate a launch platform, ask what happens at block zero. If the answer is "the usual rules", the launch is already lost. If the answer is "a protected window with uniform rules", the launch has a chance.
Follow the ZeroTick approach at the ZeroTick documentation and the ZeroTick blog. This article is educational and is not financial advice.
