Sandwich attacks remain one of the most exploitative patterns in decentralized finance. A malicious actor identifies a pending transaction, front-runs it with a higher gas bid to buy the same asset, then back-runs with a sell after the victim's transaction completes—all within the same block. The victim pays more for their purchase, the attacker pockets the spread, and the protocol's integrity degrades. For a bonding-curve reward token like Immute, where every buy and sell directly impacts the curve's state and every holder's dividend distribution, preventing this vector isn't optional. It's structural.
This post walks through the smart contract sandwich attack prevention mechanisms built into Immute's IMT token, specifically the per-address buy-lock window that blocks front-run-buy and back-run-sell sequences within a single block. The implementation uses two complementary functions—isLocked() and lockedUntil()—to enforce temporal constraints that make same-block exploitation economically nonviable.
What Makes Sandwich Attacks Possible on Bonding Curves
A bonding curve defines price as a function of supply. When a user buys IMT, the contract mints new tokens at the current curve price, increasing supply and raising the price for subsequent buyers. When a user sells, the contract burns tokens, decreasing supply and lowering the price for subsequent sellers.
This mechanism is transparent and deterministic—and that's the problem. An attacker watching the mempool sees a pending buy transaction. They can:
- Front-run: Buy IMT just before the victim's transaction, driving the price up. 2. Victim's transaction executes at the elevated price, costing more for the same amount of IMT. 3. Back-run: Sell immediately after, capturing the spread between their lower buy price and the victim's higher execution price.
For a standard bonding curve without countermeasures, this attack is straightforward to execute. The profit margin depends on transaction size and gas costs, but for sufficiently large trades, the economics are favorable.
The Per-Address Buy-Lock Window
Immute's defense centers on a constraint that most bonding curve implementations ignore: temporal coupling between buy and sell operations for the same address.
When an address executes a buy transaction on IMT, the contract records the current block timestamp and sets a lock period. During this lock window, that specific address cannot execute a sell transaction. The lock expires after a configurable duration (measured in blocks), at which point the address regains full trading capability.
This approach breaks the sandwich attack in its tracks. Consider the sequence:
- Attacker submits a front-run buy. 2. Victim's buy transaction executes. 3. Attacker attempts to back-run sell—but the contract rejects it because the lock from step 1 hasn't expired.
The attacker is now holding IMT purchased at the elevated price with no immediate exit. They must wait for the lock window to expire, during which the price may revert, gas costs accumulate, and the entire attack vector collapses.
The Implementation: isLocked() and lockedUntil()
The lock mechanism is exposed through two view functions that any wallet, dApp, or audit tool can query.
The isLocked(address user) function returns a boolean indicating whether the specified address is currently subject to a buy-lock. It checks if the current block timestamp is less than the stored lockedUntil value for that address.
The lockedUntil(address user) function returns the exact timestamp (or block number, depending on the implementation) when the lock expires. If the address is not locked, this returns zero or the current timestamp, depending on the contract's convention.
A typical integration looks like this:
if (imt.isLocked(msg.sender)) { revert BuyLockActive(); } Front-end applications can query these functions before rendering trading interfaces, giving users feedback on whether they're subject to a lock. On-chain, the check executes atomically within the buy transaction's execution context, ensuring that even if a user submits a transaction through a mempool-aware mechanism, the contract enforces the constraint.
Why This Works Against Same-Block Attacks
The key insight is that same-block sandwich attacks require rapid back-to-back transactions from the same address: buy, victim transaction, sell. The lock window is measured in blocks or time, not in individual transactions. A single buy initiates a lock that persists across multiple subsequent blocks.
If an attacker attempts to sandwich within a single block:
- The front-run buy triggers the lock. - The victim's transaction executes. - The back-run sell fails because the lock is still active. - The attacker cannot exit their position within the same block.
Even if the attacker spreads operations across consecutive blocks, the lock still applies until it expires. This transforms the attack from a low-risk, high-reward exploit into a timed position with uncertain exit conditions.
The design doesn't prevent front-running entirely—nothing can block an attacker from buying before a victim's transaction if they submit it with higher gas. But it eliminates the same-block exit, which is the critical component that makes sandwich attacks profitable. Without the guaranteed back-run, front-running becomes speculation: buy now, wait for price appreciation, exit later. This removes the risk-free arb structure that makes mempool monitoring profitable.
Integration Considerations for Builders
If you're building on Immute or integrating the IMT token into a frontend, you should query isLocked() before displaying trading controls. Users who are locked can still buy (the lock only blocks sells within the window), but attempting to sell during a lock period will revert with BuyLockActive().
For protocols integrating through the Feeder contract—the primitive that routes 99% of payments to the integrating product's treasury while committing 1% on-curve—the lock mechanism remains consistent. A user who buys IMT through the Feeder triggers the same lock. Creators earning IMT through Neptime.io or players spending through ByteOdyssey will encounter the same constraints if they attempt same-window buy-then-sell sequences.
This consistency matters for price stability. Without the lock mechanism, sophisticated traders could move IMT in and out of positions rapidly, extracting value from the curve while diluting holder dividends. The lock forces longer holding periods, which means more IMT volume stays on-curve longer, which means more fee distribution to existing holders.
Mainnet Planning
Currently live on Sepolia testnet, Immute's lock mechanism has been validated through repeated testing cycles. The contract code is public on Etherscan, and developers are encouraged to review the implementation directly. Once mainnet launch completes, the same mechanisms will apply to production IMT transactions.
For developers interested in building with Immute's smart contract sandwich attack prevention architecture, the testnet environment provides a frictionless sandbox. Free Sepolia ETH is available from faucets like Sepolia PoW Faucet, and the contracts are accessible at standard Ethereum JSON-RPC endpoints. No team allocation exists, no VC rounds have occurred—the token economy is fully community-driven from genesis.
The lock mechanism is one component of a broader security posture that includes the Feeder's 1% on-curve commitment on every integration payment, deterministic bonding curve pricing, and transparent on-chain state. For a reward token where every holder earns from every transaction, protecting the curve's integrity isn't a feature. It's the foundation.
Want to dig deeper into how Immute works on-chain?
Read the whitepaper — full technical spec of the bonding curve, fee distribution, and Feeder primitive.
Audit + V4 postmortem — every finding ever raised against the contracts and how it was resolved.
Live leaderboard — top holders, dividend earnings, referral payouts.
On-chain charts — supply curve, ETH balance, Feeder fee flow.
immute.io — connect a wallet and try the mechanics on Sepolia testnet (mainnet launch coming soon).