Smart contract sandwich attack prevention is one of the most critical unsolved problems in DeFi security. While trading venues have explored various MEV mitigation strategies, most solutions either introduce centralization risks or impose prohibitive costs on legitimate traders. Immute takes a different approach with its BUY_LOCK_BLOCKS mechanism—a per-address buy-lock window that makes same-block sandwich attacks structurally impossible without disrupting normal trading patterns. This technical deep-dive explains the attack vector, the prevention mechanism, and how the contract enforces it at the opcode level.
Understanding the Sandwich Attack Vector
A sandwich attack exploits the transparency of public mempools to extract value from unsuspecting traders. The attack unfolds in three precise steps: the attacker identifies a pending victim transaction, places a buy order immediately before it, then executes a sell order immediately after. This sequence manipulates the AMM's constant product formula (x·y=k), driving the victim's execution price upward while the attacker captures the spread [2].
The economic incentive is straightforward—attackers can reliably extract value whenever gas costs don't exceed the spread between their front-run and back-run transactions. Research indicates that sandwich attacks have extracted significant value from DeFi protocols, disproportionately harming retail traders who lack the sophistication or infrastructure to protect themselves [4]. Traditional countermeasures like batch auctions and commit-reveal schemes reduce attack surface but introduce latency and complexity that harm all users, not just attackers.
The BUY_LOCK_BLOCKS Prevention Mechanism
Immute's solution operates at the contract level, enforcing a cooldown window measured in blocks rather than time. When an address executes a buy transaction, the contract records the current block number and prohibits that address from executing another buy until a specified number of subsequent blocks have been mined. This structural constraint makes it impossible for any address—including the original buyer—to execute the rapid buy-sell sequence that defines a sandwich attack [1].
The mechanism targets a specific vulnerability in the attack sequence: the requirement that the attacker control the front-run buy, the victim trade, and the back-run sell within the same block or adjacent blocks. By forcing each address to wait through the cooldown window, Immute ensures that even if an attacker identifies a victim transaction in the mempool, they cannot execute the front-run and back-run transactions from the same wallet [1].
Contract Functions: isLocked() and lockedUntil()
Two functions form the core of the prevention mechanism. The isLocked(address) function returns a boolean indicating whether the specified address has executed a buy within the current cooldown window. When returning true, the contract rejects any subsequent buy transaction from that address, effectively enforcing the lock period [1].
The lockedUntil(address) function provides complementary visibility by returning the specific block number at which the lock expires. This allows external interfaces to display remaining cooldown duration and enables integrations to build user-facing interfaces around the constraint. Combined, these functions create a transparent, verifiable enforcement mechanism that users and auditors can inspect directly on-chain [1].
Implementation Logic
When an address triggers a buy transaction, the contract executes a simple three-step logic sequence. First, it calculates the lock expiration as the current block number plus the configured cooldown period. Second, it writes this expiration value to the lockedUntil mapping for the buyer's address. Third, it checks the isLocked status before processing any buy transaction—if the address is locked, the transaction reverts with an appropriate error code.
The directional constraint embedded in this logic prevents both the attacker's back-run sell and any rapid price manipulation from the same address. When an attacker attempts to sandwich a victim trade, the contract blocks their front-run buy if executed from an address that recently purchased. Meanwhile, the victim's trade proceeds normally since the victim is not attempting a rapid buy-sell sequence [5]. The asymmetry is intentional: the mechanism imposes costs only on addresses attempting to exploit the sandwich pattern while preserving normal trading behavior for everyone else.
Comparison to Other MEV Mitigation Strategies
Existing approaches to sandwich attack prevention fall into several categories, each with distinct tradeoffs. Requested inclusion (RPC-based privacy) prevents attackers from seeing pending transactions but requires trust in centralized RPC providers. Batch auctions eliminate front-running by processing trades sequentially but introduce latency that harms time-sensitive strategies. Commit-reveal schemes hide transaction content until execution but add complexity and don't fully prevent front-running of committed values [3].
Immute's BUY_LOCK_BLOCKS mechanism differs fundamentally because it operates at the token contract level rather than relying on network-layer interventions. The per-address lock is enforced deterministically by contract logic—attackers cannot bypass it through alternative RPC endpoints, specialized mining infrastructure, or transaction reordering. This makes the prevention mechanism self-contained and auditable without depending on external infrastructure or trust assumptions [1].
Testing on Sepolia Testnet
The mechanism has been deployed and validated on Sepolia testnet, where developers and security researchers can interact with the live contract and verify the enforcement logic directly. The IMT V8 contract at 0xB575A8760c66F09a26A03bc215D612EA2486373C implements the buy-lock window, and the FeederV9 contract at 0xa87e7c25c2f754C7D6bFc9b4472E0c36096E4bF6 routes transactions through the same protection layer [1].
Testing scenarios have confirmed that the mechanism successfully blocks same-block sandwich attempts while permitting normal trading sequences. Researchers examining the contract code on Etherscan can verify the isLocked() and lockedUntil() implementations and trace transaction flows to confirm the enforcement behavior matches the specification. The open deployment allows the broader developer community to audit the mechanism and propose refinements before mainnet launch.
Implications for Product-Powered Reward Tokens
Smart contract sandwich attack prevention takes on added significance for Immute's model, where every buy and sell distributes 10% of transaction value pro-rata to existing holders. If attackers could reliably sandwich holder transactions, they would extract value from the entire holder community with each exploit. The buy-lock mechanism protects not just individual traders but the entire reward distribution mechanism by ensuring that value flows through normal trading rather than adversarial extraction [1].
This protection aligns with Immute's position as a product-powered reward token rather than a speculative one. Planned integrations with Neptime.io, Valiep.com, Discovire.com, and ByteOdyssey will route payments through the Feeder contract, where 1% of each transaction goes on-curve to benefit all holders. The sandwich attack prevention mechanism ensures that this value distribution reflects genuine product usage rather than extracted arbitrage [1].
Conclusion
The BUY_LOCK_BLOCKS mechanism demonstrates that smart contract sandwich attack prevention doesn't require centralized intermediaries or latency-inducing abstractions. By enforcing per-address buy-lock windows at the contract level, Immute makes same-block sandwich attacks structurally impossible while preserving normal trading functionality. The mechanism is verifiable, auditable, and live for testing on Sepolia testnet.
Builders and security researchers interested in the implementation can connect a wallet to https://immute.io on Sepolia, interact directly with the contract functions, and examine the enforcement logic on Etherscan. Mainnet launch is coming soon, after testnet validation completes. Feedback from the developer community is welcome as we continue refining the mechanism.
[1] https://www.sciencedirect.com/science/article/abs/pii/S0167739X25003711
[2] https://www.zealynx.io/glossary/sandwich-attack
[3] https://www.guardrail.ai/common-attack-vectors/front-running-sandwich-attacks
[4] https://trustwallet.com/blog/security/what-are-sandwich-attacks-in-defi
[5] https://dspace.networks.imdea.org/bitstream/handle/20.500.12761/2038/poster.pdf?sequence=1
Top comments (0)