Mitigating Miner Extractable Value (MEV) with Gnosis Safe
MEV poses unique challenges to smart contract wallet users, but awareness and preparation can protect against them.
The amount of miner extractable value (MEV) has been rising significantly recently. This blogpost shines a light on different cases of MEV and how to mitigate them with the Gnosis Safe in order to raise awareness.
MEV is a measure of the profit a miner (or validator, sequencer, etc.) can make through their ability to arbitrarily include, exclude, or re-order transactions within the blocks they produce. (Source)
At this point, MEV is mainly extracted on trades. However in the future we expect to observe more sophisticated MEV such as on timed protocol updates or similar cases.
Case 1: “Classic” MEV
Whenever a user would like to execute a transaction, the transaction data is first signed and then broadcasted to the mempool. From there, miners pick up the transaction and include it in a block in order to execute the transaction and persist it on the Ethereum blockchain.
The mempool is public for anyone to access. Miners are free to sort transactions to their choice. The following “classic” types of MEV exist:
Frontrunning
A transaction is inserted immediately before an anticipated user transaction, with knowledge that the user transaction is attempted to be executed right after. Examples include liquidations happening in lending protocols or frontrunning of smart contract exploits. In both of these examples, the user transaction typically fails.
Backrunning
A transaction is inserted immediately after the user transaction, knowing that the user transaction is attempting to to execute their transaction right before. This could happen, for instance, to users performing large trades on a single protocol instead of using DEX aggregators.
Sandwiching
A user transaction is both frontrun and backrun. The typical example here are trades with high slippage. This is particularly relevant for multi-signature wallets such as the Safe since a high slippage tolerance to account for market movements is required in case signatures are collected over a large timespan.
Initiatives such as more powerful mempool explorers and flashbots have made it easier for so-called searchers to find transactions that are susceptible to MEV and actually capitalize on them.
Any transaction submitted to a public mempool is susceptible to what we call “classic” MEV. This includes transactions triggered via smart contract wallets such as the Safe as well as directly via a private key based account (EOA). Even for transactions submitted via private mempools, there is some risk of MEV extraction due to the possibility of orphaned blocks which would allow searchers to examine the previously private transactions.
One could argue that Safe transactions are slightly more vulnerable to MEV than traditional transactions authored by an EOA. For instance, a sandwich attack on an EOA transaction has to be submitted via a “bundle” containing the original user transaction (e.g. a trade) as well as 2 more transactions by an attacker attempting to extract MEV. While flashbots try to execute bundles in an “all-or-nothing” manner there is no guarantee. In theory, the opening transaction could get included in an orphaned block without the victim’s trade and attacker’s closing transaction.
With the Gnosis Safe, the opening and closing transactions of such a “sandwich” can be bundled together inside one atomic Ethereum transaction, making the MEV attack more predictable. More on this in the subsequent section.
Case 2: MEV with smart contract wallets
The Gnosis Safe is a smart contract wallet. Each Safe has a set of signer accounts (“owners”) and a threshold. Transactions can be executed once a sufficient number of owners has signed and the threshold has been met. The Safe supports different types of signatures. Mostly relevant for this article are off-chain signatures. Gnosis Safe uses off-chain signatures since they allow for better UX, in comparison to approvals that require another on-chain transaction. On the other hand, they have to be exchanged via an off-chain service. For the Safe this is done via our safe-transaction-service (Code).
We designed the Gnosis Safe in a way that any account can execute a Safe transaction as long as this threshold has been met. Execution is not limited to the owners. This is to allow for instance transaction relayers to execute transactions and therefore actually similar in all other smart contract wallets that support transaction relaying.
What does this mean for MEV?
Enabling execution for non-owners means that searchers don’t need to wait until a Safe transaction appears in the public mempool. Instead, they could query the API of our public signature service — although this involves some effort as each Safe would have to be monitored separately.
Once the searchers find a transaction with MEV potential, and all the required signatures to meet the threshold, they can themselves trigger execution. This can only happen in case the last signing Safe owner did not execute the Safe transaction right away. Assuming they did indeed just sign, but not execute, the transaction could potentially be sandwiched within one atomic Ethereum transaction which removes some of the risk involved for the attacker as mentioned in the previous section.
Therefore Safe transactions where all signatures have been collected but which have not yet been executed are slightly more vulnerable to MEV.
PLEASE NOTE: This does not mean that anyone can just trigger any Safe transaction. In the scenario presented above, the Safe owners have signed the transaction and have therefore authorized it. Signatures cannot be taken back easily in the blockchain environment.
Mitigate MEV when using the Gnosis Safe
The following 3 sections elaborate on what can be done to mitigate MEV specifically when using smart contract wallets. The attack vectors of the “classic” MEV from above still apply.
Don’t add last signature before execution
If a Safe transaction should not be executed, yet, then the most simple mitigation measure to prevent someone else from doing so, is just not adding the last signature. Only once the transaction should actually be executed, the last owner does so.
In the Gnosis Safe interface, it is the default setting that the last required owner executes the transaction right away. Users would have to actively decide to just sign the transaction without execution.
This prevents case 2 from above but not case 1.
Use authenticated service for signature collection
Currently, signatures for Gnosis Safe transactions are exchanged via the safe-transaction-service. It has a public API for anyone to retrieve signatures. To prevent case 2 from above, advanced users or teams could host their own instances of the backend instead to exchange signatures. This could be further secured via a VPN or other means of authentication.
Restrict execution to Safe owners
While the Safe core contracts don’t restrict which account can execute a signed Safe transaction, with Safe v1.3.0 it is possible to configure transaction guards. Transaction guards can be leveraged to add additional checks before executing a Safe transaction. Such a check could be that the `msg.sender` of the call to the Safe is actually an owner of the respective Safe, thereby preventing external accounts from execution. Transaction guards need to be enabled explicitly on Safes.
While the previous 3 sections apply to users of the Gnosis Safe exclusively, the following ones apply to users of any wallets and attempt to mitigate the “classic” MEV.
Submit transactions via a private mempool
By using a private mempool service such as Taichi users would not allow searchers to detect their transactions in the public mempool. This prevents some MEV scenarios however introduces another trusted party, the mempool operator.
Use dapps / networks with built-in MEV protection
Eden (formerly known as ArcherDAO) is a transaction network that protects users from MEV. In case MEV cannot be prevented, they make sure to extract it themselves and share the profits amongst token holders.
While Eden requires users to hold a token and profits are shared, CowSwap, an exchange built by Gnosis, protects users from MEV, by reducing the amount of extractable value via peer to peer matching (coincidences of wants => CoW) and delegating trade execution to a professional party that uses very tight slippage bounds at execution time. CowSwap is specifically attractive for trades made with the Gnosis Safe since users are only committed to a limit price, not a specific trading path (the optimal path may change as signatures are collected) and their system ensures that all trades in the same batch/block receive the same, fair clearing price. .
Conclusion
Although smart contract wallets aren’t generally more susceptible to MEV, compared to private key based accounts, users need to be aware of the implications when signing transactions without immediately executing them.
Private mempools seem to be currently a suitable solution for preventing the classic types of MEV, but present a serious risk of turning Ethereum into a permission chain unless the following questions are addressed:
- How can miners join the respective network and get access to the transaction flow? If anyone can join the network becomes pointless though, as it would basically be again a public mempool.
- How is monitoring done whether or not miners misbehave? This is not trivial since for instance miners joining a network could create a block (that exploits MEV) that uses a different coinbase address and thus is not directly connected to it.
This post is based on a conversation with poolpitako and monoloco from yearn.finance. They currently went with the option of letting the last signer execute the transaction right away via Tachi. They might switch to enforcing owner-only execution via transaction guards soon.
