Home › Execution & Safety › Flashbots Protect and Arbitrage: Private Transactions Explained
Flashbots Protect and Arbitrage: Private Transactions Explained
Flashbots Protect is a way to send Ethereum transactions privately to block builders rather than broadcasting them in the public mempool. For arbitrage, that matters because a visible pending trade can be copied or sandwiched. Private routing reduces that exposure, but it does not guarantee profit or remove competition.
The problem: pending transactions are public
When you send a normal Ethereum transaction, it first appears in the public mempool, where any node can see it. Searchers run software that scans that pool for profitable patterns. If your arbitrage transaction reveals a gap, a competitor can copy the trade and attach a higher tip so theirs is included first. Yours then fails or earns nothing, and if it reverts, you may still pay gas.
A related hazard is the sandwich: a searcher places a trade before yours that moves the price against you, lets your trade execute at the worse price, then trades back. The ethereum.org MEV overview describes these patterns among the ways ordering can be exploited. For a deeper look at the attacker’s side, our comparison of MEV bots and arbitrage bots explains how they differ.
How private submission works
The Flashbots Protect documentation describes an RPC endpoint you point your wallet or bot at. Instead of going to the public mempool, transactions are shared with a set of builders. The documented benefits include protection from front-running and sandwiching, and no payment for failed transactions, since a transaction that cannot be included as intended is not mined.
For arbitrage specifically, there is an additional approach: searchers can submit bundles, groups of transactions with a specified order, along with a payment to the builder. If the bundle’s conditions are not met at the target block, it is simply not included. This is the model that lets a bot say “run this only if it is profitable”.
| Method | Visible to public? | Pays gas if not included? | Typical use |
|---|---|---|---|
| Public mempool | Yes | No, if never mined; yes if mined and reverts | Simple transfers, low-stakes swaps |
| Private RPC (e.g. Flashbots Protect) | No | Generally no | Protecting user swaps and simple bot trades |
| Bundle to builders | No | Generally no | Searchers with ordering and profit conditions |
Key takeaway: private routing mainly changes who can see and copy your trade, and what a failure costs. It does not change whether the underlying gap is profitable.
What vendors say about it
CryptoMEV Bot’s Ethereum arbitrage bot page says its software sends transactions privately through Flashbots to avoid front-runners, gas wars and sandwich attacks. The page also states that the bot is “safe from front-running” because Flashbots bypasses the public mempool. As a description of the routing choice, this is consistent with how Flashbots is documented. As an absolute claim it should be read carefully: avoiding the public mempool removes one route for copying, but it does not remove competition from other searchers who submit privately and bid for the same gap, and it does not protect against bad logic or contract bugs.
A fair reading is that private routing is a valuable control, not a complete shield. The vendor’s own disclaimer acknowledges technical faults, connectivity problems and market conditions as sources of loss.
What private routing does not solve
- Competition on the same gap. Other searchers also submit privately. Whoever pays the builder the best inclusion bid generally wins.
- Stale simulation. If state changes before inclusion, the trade can still be unprofitable, though a well-built bundle should simply be dropped.
- Smart-contract risk. A bug in the bot’s contract or in a protocol it calls can lose funds regardless of routing.
- Builder and relay trust. Private submission shifts trust to the builders who see your transaction. Review current documentation on how this is handled.
- Availability. Private services have their own latency, coverage and policy changes. Check the current docs rather than assuming past behaviour.
A scenario: the same trade, three routes
Consider the same two-leg arbitrage sent three different ways. This is a thought experiment, not a measurement.
Public mempool. The bot broadcasts the transaction with a moderate tip. A competing searcher sees it pending, simulates it, and sends an identical trade with a higher tip. The competitor’s transaction lands first and takes the gap. Yours is mined next, finds the gap gone, and reverts. You pay gas for nothing, and if this happens repeatedly the loss compounds.
Private RPC. The bot sends the transaction only to builders. Nobody sees it pending, so nobody can copy it from the mempool. If another searcher independently found the same gap and also sends privately, the two compete on what they pay the builder, but your failed attempt generally does not cost gas if it is not included.
Bundle with a profit condition. The bot packages the trade with an explicit bid to the builder and conditions that must hold at the target block. The builder includes the bundle only if it is valid and the bid is attractive. The bot’s loss on a missed block is zero gas, but it has also given up part of the profit as the bid.
The lesson is that private routing changes the shape of the loss: fewer paid failures, more competition on bid size. That is better for most bots, but it makes the bidding policy a central part of profitability. It also means the margin you calculate in gas fees and arbitrage profit must include the builder payment, not just gas.
For readers who want to see how a vendor positions the same idea for bot users, the product description on CryptoMEV Bot’s front-run bot page covers the other side of the coin, including the tactics that private routing is meant to defend against. As always, read the page and its disclaimer rather than relying on a summary.
Questions to ask about a bot’s execution
- Does it send through public mempool, private RPC, bundles or a mix?
- What happens when a transaction is not included? Does it retry, and at what cost?
- How does it set the tip it pays? Is there a cap as a share of profit?
- Can you see logs of attempts, inclusions and reverts?
- Which builders or relays does it use, and can you change them?
These questions fit into the broader evaluation in how to choose an arbitrage bot. Execution details also interact with cost, because a transaction that is not included costs nothing but a reverted public one costs gas, as shown in gas fees and arbitrage profit.
Summary
Flashbots Protect and related bundle services let arbitrage transactions bypass the public mempool, which reduces copying and sandwiching and can avoid paying for non-included attempts. They are a sensible default for any serious bot, but they are not a promise of profit. Read the current Flashbots documentation, test with small amounts and treat vendor safety claims as claims until verified. This is general information, not financial advice.
Frequently asked questions
What is Flashbots Protect?
A service that lets you send Ethereum transactions to builders privately instead of broadcasting them to the public mempool, reducing exposure to front-running and sandwich attacks.
Does Flashbots make an arbitrage bot front-run proof?
It reduces public-mempool exposure but does not remove all risk. Competitors can still bid for the same opportunity, and bugs or bad simulation can still lose money.
Do failed Flashbots transactions cost gas?
Generally a transaction sent privately is only included if it is valid at the intended position, so non-included attempts do not pay gas, but check current documentation for the specific method.
Why does the public mempool matter for arbitrage?
Pending transactions there are visible. Others can copy your trade and outbid you, which wipes out the margin.
Sources
- Flashbots Docs – Flashbots Protect – https://docs.flashbots.net/flashbots-protect/overview
- ethereum.org – Maximal extractable value (MEV) – https://ethereum.org/en/developers/docs/mev/