Launching

Protection rules

Four rules, all on by default. Each one closes a specific hole. None of them closes every hole, and the last box on every card below is the honest limit.

Protection here means one thing: keeping control of the opening moment of your launch. It is not a claim about safety, not a guarantee of price, and not a substitute for reading the simulation.

Read this first

The defaults are the recommended configuration. Every rule below has a case for turning it off, and every one of those cases is specific. If you cannot name yours, leave the rule on.

Rule 01

Private bundle routing

On by default

What it does: Submits the launch through a block engine rather than the public path, so the bundle is delivered to the slot leader instead of being broadcast for anyone to read while it waits.
Why it is on: The public path is where front running happens. A create transaction sitting in public view for even a fraction of a second is an invitation, and turning this off puts your launch back on that path.
When to turn it off: If you are launching on devnet to test, or if you deliberately want the launch visible in advance, for instance because the announcement is the point and there is nothing to snipe.
What it cannot do: It cannot hide the launch after the block is built. Everything becomes public and permanent the moment the slot confirms.

Rule 02

Transaction gating

On by default

What it does: Restricts which addresses are allowed to transact during the opening window immediately after the launch lands.
Why it is on: The slot after yours is the one snipers buy in. Gating narrows what can happen in that window while your position is still forming.
When to turn it off: If you want a completely open market from the first block, and you accept that automated buyers will be in it. Some launches genuinely want that, for instance where the distribution is the announcement.
What it cannot do: It cannot last forever. A gate is a window, and the market opens when it closes. It also cannot tell a real buyer from a bot, only an allowed address from a disallowed one.

Rule 03

Allowlist mode

On by default

What it does: Narrows the gate to a list you control. Only addresses you have approved can buy while the gate is open.
Why it is on: A private sale, a community round or a team allocation needs the opening window reserved for specific people. An allowlist is how you reserve it.
When to turn it off: If your launch has no private phase and the gate exists only to slow down automation, an allowlist adds work without adding protection.
What it cannot do: It cannot verify who is behind an address. Anyone on the list can pass their allocation to anyone else, and one person can be on your list several times under different addresses.

Rule 04

MEV protection

On by default

What it does: Routes and orders your own buys so they are not sandwiched, which is when someone buys immediately before your transaction and sells immediately after it, taking the price movement your buy created.
Why it is on: Sandwiching costs you on every buy it touches, and a launch with many buys is a large surface. This is the rule with the least reason to be off.
When to turn it off: There is rarely a good reason. The plausible one is diagnostic: you are comparing execution paths on devnet and want the unprotected result to compare against.
What it cannot do: It cannot control what happens after your bundle lands. It protects your transactions, not the token, and not the people who buy it later.

How they work together

The four rules cover different parts of the same timeline. Routing protects the launch before it lands. MEV protection protects the buys inside it. Gating and allowlist protect the window straight after.

Before the slotPrivate bundle routing keeps the launch off the public path.
Inside the slotMEV protection keeps your own buys from being sandwiched.
After the slotTransaction gating narrows who can act in the opening window, and allowlist mode narrows it further to a list you control.

The gap none of them cover

Every protection here operates on transactions. None of them operates on people. If the composition of your launch is public in advance, if the token address is shared before it lands, or if someone with the information acts on it, no routing rule helps. Operational discipline is the part that is yours.

Simulate and execute

What the pre-flight actually checks, and how to read a result before you sign.

Read it