Private transactions have taken off across the Ethereum ecosystem. In the graph below you can see that private transactions have been steadily growing post-Merge from ~5% to nearly 15% of all smart contract interactions today, with a large jump around April and May. The reason for many of these private transactions is to protect users from being frontrun by MEV bots that target their transactions in the public mempool. However, an analysis using the Blocknative Mempool Archive has shown that private transactions receiving front-running protection does not equal better settlement—in fact, looking at a 60 day sample of public and private transactions revealed that users who sent their transactions privately incurred more slippage than those who sent publicly. This article explores why this happens and what can be done to prevent it.
Number of Private Transactions Since the Merge
Percentage of Private Transactions Since the Merge
% of private transactions grow from ~5% pre-Merge to nearly 15% today
How private transactions grew to encompass 15% of transaction on Ethereum
In the pre-Merge days, a user had one main option for private transactions—Flashbots. They owned 90+% of blockspace through the relationships they built with miners. Fast-forward to our post-Merge reality under MEV-Boost and now we have a fragmented blockspace market across several entities called block builders. Previously, if a user wanted to send their transaction privately, they would have to choose one builder who only owned a fraction of the overall blockspace, severely hampering execution speed and the value in transacting privately. This changed with the introduction of Order Flow Auctions (OFAs).
Enter the Order Flow Auction Era: MEV Blocker and MEV-Share
MEV Blocker is an OFA introduced by the CoW Swap / Gnosis / Agnostic teams to solve two main problems: 1) aggregate the fragmented blockspace market across many builders and 2) provide a system that refunds or rebates the MEV the transaction creates back to the transaction originator. As of August, 2023, MEV Blocker has been extremely successful in sending transactions privately with over 5.5MM successful private transactions, while MEV refunds have been a little slower to gain adoption. MEV Blocker has processed about ~8,000 refunds totaling 370ETH.
MEV-Share is an OFA introduced by Flashbots that also rebates value derived from MEV back to the transaction originator, however their focus is more on user-privacy. With MEV Blocker, they will share all of the transaction details (except the signature of course!) to searchers who bid for the right to backrun the transaction and rebate the transaction originator. Flashbot’s MEV-Share, on the other hand, gives users the option to reveal some, all, or none of the transaction details. This makes it harder for searchers to backrun the transaction, but provides more privacy guarantees to the transaction originator. As of August, 2023, MEV-Share has facilitated 3.2MM private transactions. MEV rebate data is not yet publicly available.
Zooming in on the private transaction market below, we can see that the large jump starting in May is primarily due to the rise of these order flow auctions—in particular, MEV Blocker and MEV-Share.
Number of Private Transactions by Category
MEV-Blocker and MEV-Share represent 50+% of all private transactions today
Private Transaction Market Share by Category
Despite the successful adoption of both MEV Blocker and MEV-Share for private transactions, it is important to keep in mind the goal of private transactions. The ‘private’ part is actually a means to an end. The transaction, hopefully, will land on-chain and be fully public, so being private before its on-chain is just a mechanism to help the user accomplish its execution goals. If we are focusing on swaps, the execution goal typically boils down to getting the ‘best price’ as fast as possible. While this goal seems simple enough, there are a surprising number of factors and dynamics at play that most users (even power users!) don't fully grasp. These factors and dynamics lead to two common misconceptions with private transactions: front-running protection and execution speed.
Misconception #1: Front-running protection means better settlement
To understand what it means when private transactions offer ‘front-running protection’ and, more importantly, what it doesn’t mean, we will first begin by unpacking the journey of a user who got ‘front-run’ despite sending their transaction privately.
I want to be clear upfront: none of the actors involved in the transaction—be it the builders, private transaction services, searchers etc—acted nefariously. Instead, this particular user’s journey highlights the difficulty users face transacting on Ethereum today as they attempt to navigate the MEV landscape.
Let’s start by looking at this transaction. It looks incredibly innocent and normal. Just a user trying to dump a token (PSYOP) for some ETH. What if I told you this user ‘lost’ 13.3ETH in this transaction?
How?
Slippage. Lots of slippage.
Let’s call our user “Slip”.
If we look closer at Slip’s transaction in relation to the block, we see there was quite the frenzy on the same pool address that they swapped on. There were many trades in both directions, but, most importantly, we see a massive jaredfromsubway.eth sandwich with all the meats one can eat.
If we look at Jared’s final transaction, Jared paid 8.7ETH for the right, neigh, the pleasure of being top of block. Looking closer at this transaction we see that Jared first backran the top two transactions here and here, which were making a swap in the same direction as Slip! Because Slip transacted privately, Jared had no idea about their transaction and couldn’t include it in his bundle. As a result, Slip’s transaction came after Jared’s bundle and Slip incurred 13.3ETH of slippage while Jared paid only ~8.7ETH for the right to be top of block. This means there was 4.6ETH of ‘margin’ that Slip could have used to outbid Jared and gain a better outcome!
Slip didn’t even realize that they NEEDED to compete in this de-facto ‘top-of-block auction’. They thought they were doing everything right by sending privately to avoid front-running and sandwich attacks. But “front-running” protection does not equal better settlement. It turns out that in this case, Slip would have been better off sending publicly so that they could be included in Jared’s bundle (as part of the back-run) and be top-of-block.
It’s also important to point out here that Slip must have set poor slippage parameters. Just because you are transacting privately, doesn’t mean you can ignore slippage parameters!
Why do private transactions receive worse settlement?
When Slip’s transaction was sent privately to the builder network, the transaction was completely at the whims of the complex builder algorithms. Builder algorithms order transactions in any way they see fit, with no regard to a single user's transaction (even if it was sent privately).
The combinations and permutations required to most profitably order a given set of public transactions, searcher bundles, and private transactions is enormous. Builders deploy many concurrent and proprietary algorithms to try and order transactions more cleverly than their competitors. When you send your transaction privately to the builder network, whether directly or through a 3rd party, you have no idea which builder will win the block and which algorithm of theirs will be the best algorithm for that block. This means your transaction can end up anywhere in the block. And, if your transaction can end up anywhere in the block, it can incur slippage from bundles and their transactions just like Slip’s transaction above.
Private transactions ‘lost’ $12.8M over a 60 day period due to slippage
We looked at 3+MM private transactions over a 60 day period (June and July 2023) and analyzed the net balance changes as if the transaction executed at the top-of-block vs. the net balance changes of what actually happened on-chain. Of those 3+MM private transactions, 1.4MM have a ‘tokenOut’ of WETH - ie. the user was trading a token for WETH. By looking at this subset of transactions, we can use ETH as our unit of account to understand slippage between top-of-block execution and actual execution.
Of those 1.4MM swaps, 206K (15%) incurred slippage of some kind compared to only 12% on public transactions. If you assume a $1600 per ETH price, across the entire 206K swaps that incurred some slippage, the total ‘loss’ was almost $12.8M over the 60 day period, including Slip’s loss of 13ETH.
Below we have summarized these results looking at Private vs. Public transactions where WETH is the token out.
Given the table above, private transactions do not perform any better than public transactions. Digging deeper, there is a core underlying issue why.
If we look at the percentage of transactions that have greater than 10% slippage from top of block, we find that this occurs at a rate of ~4% for private transactions and ~2% for public transactions. Since public transactions are public, you can expect users to get exactly the amount minimum specified in their transaction parameter (MEV bots gonna MEV!), so you can loosely make the assumption that 2% of users are choosing a slippage parameter of 10% or greater.
However, private transactions are not seen by sandwich and front-running bots; they are ‘accidentally’ incurring more slippage and worse execution. Therefore, if 4% of private transactions are incurring 10+% of slippage suboptimally, we can infer that these users are selecting slippage of greater than 10+% more often than those transacting publicly.
Many users likely naively select or ignore slippage because they believe front-running protection means slippage protection. This is false. And the slippage they incur is not because private transaction services (builders and OFAs) are doing anything wrong, but instead because users have fallen prey to community-wide marketing that front-running protection will always lead to more optimal outcomes than sending publicly.
Misconception #2: Private Transactions’ Execution Speed is Comparable to Public Transactions
Gone are the days when you send your private transaction to one builder and receive fast execution time. Blockbuilder market share fluctuates—sometimes dramatically—for a variety of factors both outside the builder’s control and within. This means if you only send your private transaction to one blockbuilder, your transaction cannot be guaranteed to land in the next block because they only have a limited access to blockspace. In times of volatility, most builders have even smaller access to blockspace. Even using MEV Blocker, who sends to all popular builders giving you access to 90+% of blockspace, still does not guarantee next block inclusion because not all validators support MEV-Boost. Plus there is a long-tail of builders that MEV Blocker does not send order flow to.
Pros and cons of sending private transaction as a bundle vs raw transaction
There are many nuances to blockbuilding algorithms, but the main way to get faster execution is to pay a higher gas fee than current market conditions. The other big consideration is to send to the builder as a bundle or private transaction (eth_sendBundle vs. eth_sendRawTransaction). Most users do not understand the difference and tradeoff between the two.
Typically, builders prioritize bundles first before public and private transactions. This is why most blocks have bundles at the top of the block. Why? MEV! Most bundles contain some sort of MEV in them. These bundles could be a CEX-DEX bundle of 1, a backrun bundle of 2+, or a sandwich bundle of 3+. These bundles are taking advantage of a mismatch in pricing across different venues and they use some of that value to increase the incentive to builders for top of block inclusion via higher gas prices or direct ETH transfers to the builder.
While it can be helpful to send your private transaction as a bundle in terms of block positioning (ie. closer to the top of block), you may be inadvertently hurting yourself on execution speed. Your bundle would just consist of gas cost and no MEV, so, compared to other users bundles that have MEV, it is unlikely your bundle of 1 private transaction will be competitive.
Because builders simulate bundles, many builder algorithms have a cap on the number of bundles they try to include before moving on to regular public and private transactions. Therefore, if you aren’t in the top N number of bundles, you won’t even be considered by the builder. Simulating bundles is one of the main bottlenecks for a block builder, so by sending as a bundle you are requiring the builder to do more simulations than necessary.
The main benefit you get by sending your transaction as a bundle is revert protection (ie. the builder will not include your bundle if it reverts). But definitely keep in mind that this is a trusted social contract between you and the builder. There is no guarantee that the social contract lasts forever.
And the main downside of sending as a raw transaction is the lack of this revert protection - ie. builders will attempt to include your private transaction even if it fails/reverts on-chain. Blocknative data shows that only about 4.2% of private transactions reverted on-chain compared to 13.8% of public transactions. Because some private transaction services offer revert protection (by sending as a bundle)—like MEV Blocker’s norevert endpoint—private transactions do a much better job than public transactions at preventing failed transactions.
$7.4MM of additional slippage attributed to slow execution time
Looking at the graph below, we can see the unsurprising insight that adding a simple 1 GWEI or more priority fee makes an enormous difference in your private transaction execution speed. Private transactions with a priority fee of 1 GWEI or more confirm in about 6 seconds on average (i.e they typically get next block inclusion). However, private transactions with less than 1 GWEI tip saw orders of magnitude slower execution speed—around 40s on average.
Private Transaction Execution Speed
As they say, “Time is money”. Because both MEV Blocker and MEV-Share report the time they received the transaction in their private mempool we can look at the slippage from the pending block state to what actually happened on-chain. Over the 60 day time frame we calculated an additional $7.4MM of slippage on top of the $12.8MM of slippage from our table earlier. Put another way, over the 60 day timeframe, the total slippage incurred between pending block state and actual on-chain execution was $20.2MM where $7.4MM can be attributed to slow execution time.
Tip your validators, folks!
How to improve settlement on private transactions
While the private transaction market has grown rapidly over the past year, it is clear it will continue to evolve rapidly moving forward presenting wallets and their end-users with many challenges. Users should not be expected to understand the intricacies of MEV, builder dynamics, de-facto ‘top-of-block’ auctions, etc. They just want to NOT be SUCKERS.
We believe that wallets and applications play the biggest role in helping users maximize their transaction outcomes, which is why we built Transaction Boost. Transaction Boost is a private RPC aggregator that gives wallets and applications maximum observability over their users’ transactions. You can enable your users to participate in all of the OFAs at once—MEV Blocker, MEV-Share and more. Or just send directly to builders. But most importantly, know what is happening with your private transaction in real-time and retrospectively, just like you can monitor your public transaction.
We have an ambitious roadmap that aims to solve many of these challenges discussed here—more to come soon!
In the meantime, as a user, understand your execution goals and what could go wrong. Set proper slippage parameters! Use a DEX aggregator or similar when possible vs. trading directly on a low liquidity pool. And, finally, tip your validators!
Special thanks to Alex Viñas and Felix Leupold at MEV-Blocker and Yuki Yuminaga at Fenbushi for your help providing feedback on this article.
