Safe Wallet and MEV Protection: Why Standard Multisig Approval Doesn’t Guard Against Sandwich Attacks

A decentralized autonomous organization holds ten million dollars in stablecoins and token reserves. The treasury uses a multisignature wallet requiring five of nine signers to approve any transaction. A proposal passes governance vote and moves to execution: swap one million USDC for ETH on an automated market maker. The transaction is signed, broadcast to the network, and sits in the mempool awaiting inclusion in the next block. Within seconds, an observer notices the pending swap, front-runs it by bidding up the asset price, and then back-runs it by selling the now-expensive tokens back into liquidity. The five signatures were never forged. The approval threshold was met. Yet the treasury received measurably fewer tokens than the quoted price predicted. The multisig did not prevent the loss.

This scenario reveals a structural weakness in how multisignature wallets like Safe interact with decentralized finance. The security model of a smart contract wallet focuses on controlling who can authorize transactions—typically through threshold approval, role-based access control, and transparent on-chain verification. It does not address what happens to those transactions after approval, when they enter the public mempool and compete for block inclusion. Maximal extractable value (MEV), the profit available to block builders and searchers who can reorder or insert transactions, operates on a different layer. Standard multisig approval is orthogonal to MEV risk. Understanding why requires examining the actual attack surface, the limitations of current Safe Wallet architecture, and the emerging tools that do address order flow vulnerability.

Multisignature approval and order flow are separate security domains

A multisignature wallet such as Gnosis Safe solves a specific problem: preventing any single private key holder from unilaterally moving assets. The approval mechanism requires a threshold of authorized signers to sign off on a transaction before it can be executed. This is cryptographically sound and operationally valuable. A compromised key cannot drain the treasury. A rogue team member cannot execute unauthorized transfers. The transaction is recorded on-chain, and every approval is auditable and non-repudiable.

That security model, however, operates in the authorization layer. It answers the question: who decided that this transaction should happen? It does not answer: what happens to the transaction after I broadcast it? The latter question belongs to the ordering layer. Once a transaction is published to the mempool, it is visible to validators, block builders, and searchers. They can see the transaction details, including the assets involved, the swap size, and the slippage tolerance. They can also choose to reorder transactions relative to each other, front-run by inserting their own transactions ahead, or back-run by inserting transactions after. This capability exists independently of the multisig approval structure.

A concrete example clarifies the boundary. A Safe Wallet executes a transaction to swap 100 USDC for ETH on Uniswap. Five of nine signers have approved it. The transaction is valid and authorized. The smart contract executes correctly. The trade settles. But a searcher noticed the pending transaction in the mempool, purchased ETH before it executed to raise the price, and then sold their holdings into the inflated demand created by the treasury’s swap. The treasury’s transaction succeeded from a multisig perspective—it was properly authorized and executed. It failed from an MEV perspective—the searcher extracted value from the execution itself.

The root cause is not a weakness in the approval process. It is a vulnerability in the transaction’s visibility and ordering. The multisig approval is orthogonal to this attack. Even if the wallet required 100 signatures, or had perfect cryptographic security, or was audited by three independent firms, the front-run would still be possible because the front-run happens after the transaction is authorized and broadcast.

Why mempool transparency creates MEV exposure

Ethereum’s current architecture broadcasts transactions to a public mempool where they can be observed by all participants before inclusion in a block. Block builders and validators can see pending transactions and choose the order in which they appear in a block. This ordering power is valuable. A searcher who notices that a large DEX trade will move prices can profit by executing first, adjusting the market, and letting the original transaction execute at worse rates. The treasury’s transaction was made worse off; the searcher was made better off by the same amount.

Large transactions are particularly vulnerable because their price impact is measurable and their execution is predictable. A treasury swap worth millions of dollars in a moderately liquid pool will inevitably move prices. Any observer can estimate the slippage. A searcher or block builder can sandwich the transaction and capture that slippage as profit. The size of the exposure scales with the transaction size, the liquidity of the markets involved, and the slippage tolerance set in the original swap parameters.

Safe Wallet users executing DeFi wallet interactions through the interface are providing this observable information to the entire network. Setting a minimum output amount (slippage tolerance) provides a bound on the loss, but it does not eliminate MEV. If the market moves far enough that the minimum is not met, the transaction fails rather than executing at a worse rate. But in normal conditions, the transaction executes somewhere between the fair price and the slippage bound. A searcher can exploit this range.

The multisignature approval process does not change this dynamic. Requiring multiple signers to authorize the transaction does not hide the transaction from the mempool. Broadcasting the signed transaction reveals it to all observers. The approval threshold adds governance and control benefits, but it does not provide confidentiality or ordering control. The same MEV risks that affect a single-signer wallet affect a Safe Wallet with ten signers.

Common misconceptions about multisig as an MEV shield

Several intuitive but incorrect assumptions persist about multisig wallets and MEV resistance. The first is that high governance standards prevent MEV losses. A DAO might implement a nine-of-fifteen multisig to ensure broad consensus on treasury moves. The governance layer is genuinely stronger. The approval layer is harder to compromise. But MEV is not a problem with the approval. A transaction that passes nine-of-fifteen multisig approval is still just as visible to searchers and block builders as a transaction with single-signer control. The governance structure does not reduce ordering risk.

A second misconception is that on-chain transparency provides security. Safe Wallet transactions are recorded immutably on the blockchain. The transaction history is auditable. Every approval is logged. This transparency is valuable for governance and accountability. It is irrelevant to MEV. The searcher who front-runs a treasury swap does not care that the transaction is on-chain and auditable. The transparency actually helps the searcher by making the order flow observable.

A third misconception is that role-based access control and tiered approval mechanisms mitigate MEV. Some multisig structures use different approval tiers for different transaction types or values. A small treasury payment might require two of five signers; a large swap might require five of nine. This controls who can authorize which transactions. It does not control what happens after authorization. The MEV risk is the same for a small swap requiring two signatures and a large swap requiring nine. The multisig threshold is irrelevant to the ordering question.

The practical consequence is that treasury teams often overestimate the security properties of a decentralized finance wallet that uses multisig approval. They correctly focus on preventing internal fraud or unauthorized key holder action. They correctly build governance procedures around approval. But they then assume that these controls address external attacks such as MEV. They do not. The two categories of risk are distinct.

Sandwich attacks on Safe Wallet transactions in practice

A sandwich attack on a Safe Wallet transaction follows a predictable pattern. First, a searcher monitors the mempool and identifies a pending transaction that will affect asset prices or liquidity. Second, the searcher constructs a transaction that benefits from executing before the original. Third, the original transaction executes. Fourth, the searcher executes a closing transaction that capitalizes on the price movement caused by the original transaction. The sandwich is closed, and the searcher has extracted value.

The attack works against Safe Wallet transactions because Safe Wallets use the standard Ethereum transaction model. A multisig-approved transaction enters the mempool like any other transaction. It competes for block inclusion using normal priority mechanisms. Validators and block builders can reorder it. The approval cryptography is irrelevant to the ordering process. A searcher does not need to compromise the multisig, forge a signature, or guess a key. They only need to observe the transaction and insert their own transactions around it.

For a large treasury move, this can be expensive. A swap of ten million dollars in a major token might move the market significantly. The front-run transaction must buy the asset before the treasury swap executes, which is costly at scale. The back-run must sell at the peak, which requires precise execution. But the MEV available can also be substantial. A one-percent slippage on a ten-million-dollar trade is one hundred thousand dollars. If a searcher can capture even half of that through sandwich attacks, the incentive is enormous. Automation and scale make this feasible.

Safe Wallet users executing batch transactions are also exposed to MEV sandwich attacks on each component transaction. The batch feature can improve efficiency and reduce gas costs, but it does not reduce MEV risk. Each transaction in the batch can be front-run or back-run individually. The multisig approval applies to the entire batch, but the ordering risk applies to each piece.

Why slippage tolerance settings alone are insufficient

Safe Wallet users executing DEX trades can set a minimum output amount or slippage tolerance. This parameter limits how much worse the execution can be than the quoted price without reverting the transaction. For a swap of USDC to ETH, a user might set a minimum ETH output of 450 ETH when the fair market price suggests 456 ETH. The 1.3 percent tolerance is intended to account for normal market volatility and block-by-block price variation.

The slippage parameter does provide one form of protection: it prevents extreme slippage from executing silently. If a sandwich attack causes the trade to fall below the minimum output, the transaction reverts, and no value is extracted. But this is a hard threshold, not a defense against moderate MEV. If the fair price is 456 ETH and the slippage bound is 450 ETH, a searcher can sandwich the transaction and still extract value, pushing the execution to 452 ETH. The treasury still receives fewer tokens than fair price, but the transaction does not revert because the minimum was met.

Setting a tighter slippage tolerance reduces the window for MEV extraction but increases the risk of transaction failure due to normal volatility. A 0.1 percent tolerance on a large trade might revert frequently on a congested network. Each revert costs gas and delays the transaction. There is a trade-off between MEV resistance and execution reliability that slippage parameters alone cannot resolve.

The multisig approval does not affect this trade-off. Whether a transaction requires one signature or nine, the slippage parameter works the same way. The approval layer and the MEV layer remain separate. Requiring five signers to approve a swap does not improve the slippage setting or reduce the exploitable window.

MEV-resistant order flow solutions and their limitations

Several tools now exist to reduce MEV exposure by controlling order flow rather than relying on public mempool transparency. Private mempools (also called dark pools in some contexts) allow transactions to be sent directly to builders rather than broadcast publicly. The transaction is hidden from searchers until it is included in a block, reducing the front-running window. Services such as Flashbots Protect or MEV-Relay allow users to send transactions privately.

For a Safe Wallet executing a large DEX trade, private order flow submission can materially reduce sandwich attack risk. The transaction is hidden from searchers. The block builder receives it but does not have the same incentive to sandwich it (though this remains a theoretical concern). The actual MEV exposure is reduced compared to public mempool submission. However, this introduces new trade-offs. The user is trusting the private relay operator not to extract MEV themselves or sell the transaction information to searchers. The centralization risk is traded for confidentiality. This can be appropriate for large treasury moves, but it is a new form of risk, not its elimination.

Another approach is in-protocol MEV mitigation through encrypted mempools or threshold encryption schemes. These would require protocol-level changes to Ethereum or require Safe Wallet users to interact with alternative execution layers that implement these mechanisms. Some Layer 2 solutions are exploring MEV-resistant designs. But for Safe Wallet users operating on mainnet Ethereum or standard EVM-compatible chains, private order flow is currently the most accessible mitigation.

Intent-based architectures represent another emerging direction. Rather than broadcasting a transaction specifying exact inputs and outputs, a user specifies an intent (swap 100 USDC for at least 450 ETH at best available price). Multiple solvers then compete to fulfill the intent, and the solver who provides the best execution is selected. This can reduce MEV by disaggregating the ordering decision from the user’s specific transaction. But intent systems are still evolving, and their security properties are not yet fully understood at scale.

Governance and treasury best practices for MEV exposure

Safe Wallet users managing large treasuries should treat MEV as a distinct security and financial risk from theft or unauthorized access. The multisig approval controls the authorization layer effectively. It does not control the ordering layer. Acknowledging this boundary is the first step toward appropriate mitigation.

For large transactions, using private order flow (Flashbots Protect, MEV-Relay, or similar services) reduces sandwich attack risk substantially. The trade-off is some centralization risk and trust in the relay operator, but for million-dollar-plus trades, this is often an acceptable cost. Smaller transactions may not justify the complexity. The MEV loss from a small trade is typically minor compared to the opportunity cost of delaying execution or the complexity of alternative routing.

Batch transactions through Safe can reduce gas costs and improve efficiency, but they should not be assumed to reduce MEV risk. Each component transaction is still ordered independently. If possible, separating large trades into multiple smaller trades across different blocks can reduce the attractive size of any single sandwich opportunity, though this increases gas and operational overhead.

Treasury governance should explicitly account for MEV loss in budget planning. A protocol that regularly executes multimillion-dollar swaps might lose tens of thousands or more per month to sandwich attacks if no mitigation is deployed. Quantifying this loss and assigning responsibility for MEV research is more effective than assuming that multisig approval provides implicit MEV resistance. Some DAOs now employ MEV researchers as core team members or contractors.

The evolving threat landscape and longer-term directions

The separation between approval security and ordering security is becoming more pronounced as MEV becomes more systematic and as multisig wallets become more widely used for large treasury operations. Early in DeFi, MEV was often regarded as a minor issue affecting only the largest trades. As extraction techniques improved and as block building became more specialized, MEV losses scaled. Sandwich attacks are now a major source of leakage for large on-chain actors.

Protocol designers are exploring solutions at multiple layers. Encrypted mempools, threshold encryption schemes, proposer-builder separation with MEV-resistant commitments, and Layer 2 designs with different ordering mechanisms all represent attempts to address the root issue: public visibility of pending transactions before ordering. None of these solutions is production-ready at scale on Ethereum mainnet, but they represent directions that could eventually provide stronger guarantees.

For Safe Wallet users, the practical implication is that multisig security and MEV resistance are both necessary but neither is sufficient alone. A well-designed treasury management process uses multisig approval to control authorization and uses MEV-resistant order flow tools to control execution. The two layers of security address different threat models and should be treated independently. Conflating them—assuming that strong multisig governance provides MEV resistance—is a common error that leads to larger-than-necessary treasury leakage.

As smart contract wallets become more sophisticated, some designs may eventually integrate MEV-resistant execution primitives directly into the wallet interface or use specialized order flow providers by default. But for current Safe Wallet users, understanding the distinction between approval and ordering is essential for informed risk management. The multisig protects the authorization layer. Explicit MEV mitigation protects the execution layer. Both are required.