A user opens Trezor Suite Web to swap 5 Ethereum for a decentralized exchange token. The transaction is signed on the hardware device, broadcast to the network, and sits in the mempool awaiting inclusion. Before the transaction is mined, another transaction suddenly appears ahead of it, purchasing the same token at a lower price. Then, immediately after the user’s transaction executes at a higher price, a third transaction sells that token for profit. The user receives fewer tokens than the quote promised. This is a sandwich attack, one of the most prevalent forms of maximal extractable value (MEV) exploitation, and it affects hardware wallet users as directly as it affects custodial platforms. The difference is not immunity; it is where responsibility for defense falls. Trezor Suite Web provides the interface, but the user must understand the mechanics and choose appropriate mitigation before signing.

Sandwich attacks work because blockchain transactions are public before confirmation. A mempool observer can see pending transactions, predict their price impact, and place their own trades to profit from that impact at the user’s expense. Hardware wallets like Trezor isolate private keys on a physical device, preventing theft through compromised computers or phones, yet that same isolation cannot prevent a DEX transaction from being observed, reordered, and exploited. The user’s transaction signing security remains intact, but the execution outcome is manipulated. Understanding why this occurs, how to identify when it is happening, and what practical defenses exist separates informed usage from false confidence in hardware-based security alone.

Why private key security does not protect against transaction reordering

The architecture of Trezor hardware wallets creates a clear boundary between signing security and execution security. Private keys live exclusively on the device, never touching the computer, phone, or cloud service. A transaction is constructed on the device’s screen, reviewed by the user, and then signed using the isolated key material. Only the signed transaction leaves the device. This prevents private key theft, unauthorized spending, and transaction forgery. An attacker cannot create a valid transaction without the hardware wallet, and Trezor Suite Web cannot be modified to drain the wallet through software alone.

Transaction reordering exists in a different domain. Once a signed transaction is broadcast to the Ethereum network, it enters a distributed mempool where thousands of validators and searchers observe it. The transaction contains a signature proving authorization, but it also contains a plaintext amount, destination, and method call. A sandwich attacker reads this information, understands what it will do to the DEX’s price curve, and submits transactions that front-run or back-run the user’s trade. The signature proves the user intended to send it. The signature does not control who mines it first, at what network conditions it executes, or whether its impact can be profitably sandwiched.

This distinction matters because users sometimes conflate „hardware wallet protection“ with „complete transaction safety.“ A hardware wallet protects the key. It does not protect the mempool or the order of execution. The signed transaction itself is the vulnerability in sandwich attacks, not the method of signing it. Whether a user signs on a Trezor device, with a Ledger, through a MetaMask browser extension, or on a centralized exchange interface, the transaction remains visible to potential attackers. The difference is that with a hardware wallet, the user retains full control over what they are signing and can choose whether to approve a transaction in the first place, whereas a custodial exchange handles signing automatically.

How sandwich attacks manipulate price impact and slippage

Automated market makers (AMMs) like Uniswap use bonding curves to determine price based on the ratio of two assets in a liquidity pool. A user swapping 5 Ethereum for a token changes that ratio, moving the price. Before the user’s transaction executes, the pool might offer 1,000 tokens per Ethereum. After absorbing the user’s 5 Ethereum inflow, the price might drop to 950 tokens per Ethereum. The user receives fewer tokens than the initial quote. This is normal slippage and is why interfaces display a minimum output amount or slippage tolerance.

A sandwich attacker exploits this by inserting a front-running transaction that also buys the token before the user’s transaction. This front-run pushes the price further in the wrong direction, so when the user’s transaction executes, it receives even fewer tokens than slippage alone would cause. Then the attacker sells their tokens immediately after the user’s transaction, profiting from the price recovery. The attacker extracts value directly from the user’s transaction. Trezor Suite Web displays the quote at the time the user signs, but the actual execution price depends on the order in which miners include transactions in the next block. If an attacker’s transaction is placed ahead of the user’s, the promise of the quote is broken.

The technical reason sandwich attacks persist is that Ethereum’s consensus mechanism does not enforce transaction ordering based on fairness; miners and validators order transactions to maximize their own revenue. They can accept bribes through Flashbots Bundles, MEV-Boost, or direct payments. A sandwich attacker offers a miner more profit than the normal transaction ordering would provide. From the miner’s perspective, it is economically rational. From the user’s perspective, it is a direct financial loss. Hardware wallet signatures do nothing to prevent this because they are orthogonal concerns. The transaction is valid and authorized. The problem is the order in which it executes.

Mempool visibility and the information asymmetry problem

When a user submits a transaction from Trezor Suite Web, they must send it somewhere. That somewhere is typically a public node, a service like Infura, or a node run by the wallet application itself. Within seconds, that transaction broadcasts to the network and becomes visible to professional MEV searchers who operate thousands of nodes, monitor the mempool continuously, and run simulations to identify profitable attack opportunities. The user has no equivalent visibility. They cannot easily see who else is in the mempool, whether their transaction is being simulated for attack opportunities, or what front-running transactions are queued behind or ahead of theirs.

This information asymmetry is fundamental to how sandwich attacks work. Sophisticated attackers have access to mempool data that retail users do not. They know the pending transaction, they calculate the profit from sandwiching it, and they submit their attack transactions before the user’s transaction can be mined. A user on Trezor Suite Web has no built-in mechanism to watch the mempool or react to attacks in progress. The transaction is signed, broadcast, and then the outcome is determined by forces largely outside the user’s direct control.

Some defenses attempt to level this asymmetry. Private mempools, encrypted transactions, and proposer-builder separation (PBS) are longer-term solutions still under development. Today, a user’s most practical lever is controlling what information is leaked in the first place. Smaller transaction sizes are harder to sandwich profitably. Larger slippage tolerances reduce the opportunity for attack, though they accept a worse outcome. Using private RPCs or aggregators that batch transactions can obscure transaction timing. None of these eliminate the attack entirely, but they reduce the signal-to-noise ratio that attracts attention from searchers.

Trezor Suite Web sandwich attack mitigation strategies

The first line of defense is recognizing that a sandwich attack has occurred. If a swap execution price differs significantly from the quoted price, slippage limits may have prevented the transaction from completing, or an attacker may have inserted transactions. Trezor Suite Web displays the quoted rate at signing time, and the user can view the actual execution price on a block explorer after confirmation. If the price impact is larger than expected slippage, it warrants investigation. A single transaction experiencing 5% worse execution than quoted is unusual; repeated occurrences suggest consistent targeting.

Setting appropriate slippage tolerance is a practical control. A lower slippage tolerance (1–3%) protects the user by rejecting transactions that execute too far from the quote, but it also increases the chance the transaction fails to execute at all if volatility is high. A higher tolerance (5–10%) increases the chance of execution but accepts larger losses to sandwich attacks. The right balance depends on the token’s volatility, liquidity depth, and transaction size. For large swaps on illiquid pairs, increasing slippage tolerance to give the transaction room to execute may be necessary; for small swaps on stable pairs, a tight tolerance is appropriate.

Using private transaction pools or MEV-resistant RPC endpoints is another available option. Flashbots Protect and similar services aim to relay transactions to the network without exposing them to the public mempool first, theoretically reducing visibility to searchers. Some protocols now offer MEV Burn or MEV redistribution, where extraction is shared with the network rather than stolen entirely. These are not absolute protections, but they do reduce the expected profit from attacking a transaction, which can cause searchers to target other transactions instead.

Splitting larger swaps into smaller transactions spread across different blocks can reduce the individual transaction size attractive to attackers. If a user plans to swap 100 Ethereum for a token, executing it as five 20-Ethereum swaps increases the operational overhead but reduces the MEV incentive per transaction. Block builders and validators may choose not to sandwich a 20-Ethereum transaction if the profit margin is too thin. The tradeoff is higher gas costs from multiple transactions and more time spent interacting with the DEX. Users can access these tools through the official trezor suite web platform, where swap features integrate with multiple DEX aggregators and liquidity sources that may offer different MEV protections.

When to use alternative execution venues and protocols

Not all blockchain interactions are equally vulnerable to sandwich attacks. Transactions on Bitcoin do not experience MEV in the same way because Bitcoin lacks smart contracts and complex state machines. Litecoin, which also lacks sophisticated DeFi, carries lower MEV risk for simple transfers. Ethereum Layer 2s like Arbitrum and Optimism can reduce MEV pressure because they batch transactions with different ordering, though they are not immune. Solana’s parallel transaction execution model theoretically allows non-conflicting transactions to be processed in different orders, which complicates sandwich attacks, though Solana still experiences MEV.

Protocol-level solutions are gradually being deployed. Encrypted transactions using threshold encryption or homomorphic encryption would keep transaction details hidden until after they are sequenced, preventing attackers from reading the mempool. MEV-aware DEX designs like CoW Swap (Coincidence of Wants) match trades off-chain and settle them on-chain in a single batch, eliminating the ability to sandwich individual orders. Threshold Encryption and Encrypted Mempools are being tested on Ethereum testnets and could eventually provide stronger protection at the protocol level.

For users on Trezor Suite Web today, the practical strategy is to understand which transactions are MEV-vulnerable and apply proportional defenses. Token swaps on Uniswap v3 are vulnerable. Large transactions on new or illiquid pairs are higher-value targets. Yield farming transactions that execute at specific times are predictable. By contrast, simple ETH transfers, governance votes, and NFT purchases are not sandwich-attack targets. Matching the defense to the actual risk prevents over-engineering for every transaction while strengthening protection where it matters most.

Transaction verification and device-level transparency

One advantage of hardware wallets is that the Trezor device displays transaction details on its own screen before signing. A user can see the destination address, the amount, the token being sent, and the gas fee without trusting the computer’s display. This prevents a compromised application or malware from substituting a different destination. However, the information displayed on the Trezor’s screen does not include the expected output of a swap or the execution price. Those details are calculated off-device and displayed on the computer before the user is asked to review and sign.

A sophisticated attack could theoretically display a different expected output on the computer screen than what the user will actually receive, manipulating the user into accepting a bad deal. More realistically, sandwich attacks happen after signing; the computer accurately displays the quote, the user signs it, but network reordering causes a worse outcome. The Trezor device cannot prevent this because it does not have network access or knowledge of how the transaction will be ordered.

What hardware wallets do prevent is the scenario where the computer signs a different transaction than what the user approved. This is a crucial protection against keystroke logging, UI hijacking, and compromised applications. In a sandwich attack scenario, the transaction signed is exactly what the user intended to sign. The problem is execution, not authorization. Trezor Suite Web’s transparency about transaction details at signing time is helpful for catching obvious mistakes—swapping the wrong token or sending to the wrong address—but it cannot catch reordering attacks that occur after broadcast.

Portfolio tracking and real-time attack detection

Trezor Suite Web includes portfolio tracking functionality that shows holdings, current prices, and transaction history. This visibility can help users identify patterns of poor execution prices that might indicate repeated sandwich attacks. If every DEX swap comes in at 3–4% worse than the quoted price, it suggests consistent targeting. Random variance is normal, but systematic underperformance warrants investigation and defensive adjustments.

Real-time detection of sandwich attacks is difficult for individual users because it requires knowledge of the block before it is mined. After a transaction is confirmed, it is straightforward to calculate what the fair price should have been and determine whether reordering occurred. But by then, the damage is done. Some advanced users run local simulations using Tenderly or similar tools to backtest transaction prices, but this is beyond the typical user experience. Trezor Suite Web does not offer built-in sandwich attack detection, and no wallet application can reliably do so without access to the mempool and ordering information that only validators possess.

The practical implication is that users should treat sandwich attack detection as a forensic activity, not a real-time prevention mechanism. After a transaction executes with unexpectedly poor results, review the block and the executed price. If the pattern repeats, adjust defenses like slippage tolerance, transaction size, or MEV-resistant pools. Over time, this iterative approach can reveal which combinations of parameters work best for the user’s specific transaction patterns and liquidity needs.

Governance, transparency, and the future of MEV

The long-term solutions to sandwich attacks will come from protocol changes, not wallet software alone. Ethereum is exploring MEV-Burn, where a portion of MEV is burned rather than captured as profit, reducing the incentive to attack transactions. Proposer-builder separation (PBS) aims to decouple the role of selecting transactions from the role of executing them, potentially reducing a single actor’s ability to reorder transactions for profit. Encrypted mempools would keep transaction details hidden until after ordering is finalized.

Hardware wallet manufacturers like Trezor can contribute by clearly documenting MEV risks, offering integrations with MEV-resistant protocols and RPC endpoints, and providing tools for users to set slippage limits and choose execution venues. Transparency about these limitations is more valuable than false claims of protection. A wallet that says „we cannot prevent sandwich attacks, but here is how to reduce your exposure“ is more honest and more useful than one that obscures the problem.

Users should expect that both Trezor Suite Web and competing wallet platforms will increasingly integrate MEV-aware features as the problem becomes more widely understood. This might include recommendations to split large transactions, integration with private mempools, or direct routing to MEV-resistant protocols. None of these will eliminate MEV exploitation entirely because it is a consequence of transparent blockchains and public mempools, but they can reduce individual user losses substantially.