What a sandwich attack does to a sell
A sandwich attack starts with visibility. A bot sees a pending swap in the public mempool, buys right before it and sells right after, profiting from the price impact of the victim's trade. For a seller, that means a worse fill than expected.
Selling from many wallets multiplies the exposure: each sell is a separate pending swap that a bot could target. Private submission removes the visibility a sandwich needs - if nobody can see the transaction before it lands, nobody can place trades around it.
How the Terminal routes every transaction
The Terminal on Ethereum lets you buy and sell any token across your wallets with a live chart and PNL tracking. Swaps are routed through the 0x aggregator across Uniswap and the other Ethereum DEXes, and every buy, approve and sell is sent through Flashbots Protect fast mode (rpc.flashbots.net/fast, tagged with an originId) instead of the public mempool.
Fast mode shares the transaction with all registered builders within a block, so inclusion is close to a normal transaction. Because nobody can see it before it lands, it cannot be sandwiched or front-run.
This applies to approvals as well as swaps. Routing approvals through the same private channel keeps the whole sell flow consistent and off the public mempool from start to finish.
Public mempool vs Flashbots Protect fast mode
| Aspect | Public mempool | Flashbots Protect fast mode |
|---|---|---|
| Visible before inclusion | Yes, to anyone watching | No |
| Sandwich or front-run risk | Yes | No - nobody sees it before it lands |
| Who receives it | The whole network | All registered builders, within a block |
| Inclusion speed | Normal | Close to a normal transaction |
Tracking status and failed transactions
Because a Protect transaction never appears in the public mempool, TokenBundle polls Protect's status API at protect.flashbots.net/tx/<hash> to follow it. The statuses are PENDING, INCLUDED, FAILED, CANCELLED and UNKNOWN. FAILED means the transaction was not included within 25 blocks.
On FAILED or CANCELLED, TokenBundle stops and tells you that nothing was spent and you can try again, instead of waiting indefinitely on a transaction that will not land.
Slippage guards and approvals
- Buys and sells use a 10% slippage limit by default, adjustable from 1 to 50% in the Terminal's settings.
- The 1% platform fee is taken inside the swap itself, so it is only paid when the swap lands.
- A wallet's first sell of a token waits for an approve transaction, which also goes through Protect; later sells reuse it.
Selling from many wallets: presets and Sell all
Each wallet row has sell buttons for 10, 25, 50 and 100% of its balance (you can set your own percentages), so you can take partial profit from a single wallet without typing amounts.
"Sell all" sells the full balance of every wallet ("Sell all (excl dev)" keeps the dev wallet), two wallets at a time on Ethereum. Each sell is its own Protect transaction with its own slippage limit and status tracking, and none of them is visible in the public mempool before it lands.
A FAILED or CANCELLED status on one transaction is reported on that wallet's row rather than left hanging. Nothing was spent on that transaction, and you can try it again. The Terminal's PNL shows how each wallet's position stands as the sells go through.
Custom Bundle vs the Terminal on Ethereum
The launch itself uses a different mechanism. A Custom Bundle packs the whitelist call, the open-trading call and one Uniswap V2 buy per wallet into one all-or-nothing Flashbots bundle. The Terminal handles everything after launch, sending each buy, approve and sell individually through Flashbots Protect fast mode.
Both share the same goal of keeping your transactions out of the public mempool. The difference is scope: a bundle needs several transactions to land together in one block, while a sell from one wallet only needs to land privately on its own. That is why the Terminal uses Protect fast mode rather than building a bundle for every trade.
FAQ
- Can my sells be sandwiched when using the Terminal? No. Every sell goes through Flashbots Protect fast mode instead of the public mempool, so nobody can see it before it lands.
- Is Flashbots Protect slower than a normal transaction? Fast mode shares the transaction with all registered builders within a block, so inclusion is close to a normal transaction.
- What happens if a Protect transaction fails? If the status is FAILED (not included within 25 blocks) or CANCELLED, TokenBundle stops and reports that nothing was spent so you can try again.
- How does Sell all work across wallets? It sells 100% from every wallet in the table (locked wallets skipped), two at a time, each through Protect with its own slippage limit.
- Why do sells need an approve first? A token must be approved before the router can sell it; the Terminal does it automatically on a wallet's first sell.
Coordinate your launch with TokenBundle.
Prepare wallets, review allocations and manage network-specific launch execution from one workspace.
Open Ethereum workspace