How can a malicious contract know in advance, without tipping off the user, whether it's being executed in a simulated environment rather than genuinely on-chain?
The key lies in a set of environmental data available during blockchain execution known as "special variables" — the current block height, timestamp, and, as covered in this article, the block producer's address (COINBASE). These variables are pieces of information contract code can actively read during every transaction's execution and branch its logic on, designed originally so that contract logic could sense the on-chain state it's operating within — checking a timestamp to determine whether a given event has already ended, for instance.
The problem is this: on a genuine chain, these variables are always populated with real, meaningful values. But in a simulated environment, since no real block is ever actually assembled and no real producer actually exists, the team building the simulation tool has to decide for itself what to put in these fields — and ZenGo's research found that some implementations chose the path of least effort, simply filling in zero values or a null address. This seemingly harmless shortcut handed malicious contracts a clear-cut way to determine whether they're currently being simulated — effectively leaving a window in the contract code that lets it check whether anyone's watching from the audience.
If a simulation tool simply populated environmental variables like the block producer's address with the same specific values as the real chain, wouldn't that fully solve the problem?
This is indeed the direction the industry has largely taken for the fix, and ZenGo's team explicitly noted when disclosing this research that the remediation is relatively straightforward: stop using easily identifiable "shortcuts" like zero values or a null address, and instead populate these fields with meaningful, specific values pulled from real chain state, letting the simulated environment replicate on-chain conditions as faithfully as possible. Most vendors who received the disclosure did complete this kind of fix within a short window.
But what this fix actually solves is only the specific detection method of "is COINBASE the zero address" — not the more fundamental question of whether a contract has any way at all to distinguish a simulated environment from a real one. In theory, as long as any sliver of a detectable difference remains between a simulated and a genuine on-chain environment — a subtle gap in execution speed, a behavioral difference in certain low-level system calls, or some other environmental variable not yet publicly researched — a sufficiently well-crafted malicious contract could, in theory, find a new basis for detection. This is exactly why most security researchers' stance is that patching a known technique substantially raises the bar for attackers, but whether a simulated environment can ever be made fully indistinguishable from a real one is, fundamentally, an ongoing race that requires sustained investment to stay ahead of — not a problem that gets fully solved once and for all.
Beyond this technique exploiting environmental variable differences, are there other ways malicious contracts can evade transaction simulation checks?
Yes, and from a defense standpoint, the practical impact of this other technique may actually be more severe. Instead of getting the contract itself to detect and evade the simulated environment, an attacker can also target the step where a simulation's result gets presented to the user — meaning that even if the simulation tool itself genuinely runs and produces the correct result, if the wallet interface's logic for parsing or rendering that result into something a user can understand has a flaw, an attacker can still get the user to see a screen that doesn't match the actual simulation result. For example, if a transaction actually contains an instruction transferring ownership of the user's wallet to a contract the attacker controls, but the wallet interface's parsing logic fails to correctly identify that instruction and only displays something seemingly harmless like "you're about to receive 1 SOL," the user could still sign a transaction that completely surrenders control of their wallet, entirely without knowing it.
This class of risk — where the simulation's underlying result is fine, but what gets displayed to the user is broken — is closely connected to the core logic of Blind Signing already covered on this site. Both point to the same underlying principle: what a user actually sees on screen and what's genuinely happening at the technical level behind it are always separated by an intermediary layer that some piece of software is responsible for translating — and that translation layer, whether it's the simulation engine or the wallet interface, can itself be attacked or poorly designed.
Facing this kind of risk where even the transaction simulation tool itself might be bypassed, what can an ordinary user actually do? It sounds like no tool is genuinely reliable.
That conclusion moves too fast. What this research reveals is that transaction simulation isn't an absolute guarantee — not that transaction simulation is useless. In fact, most attacks that require this kind of advanced evasion technique to succeed represent a considerable investment of technical resources and planning on the attacker's part, and this kind of carefully engineered attack is typically not wasted on small, low-value, or poorly targeted transactions. For the vast majority of everyday transactions, a transaction simulation tool remains the most effective, lowest-cost first line of defense currently available — continuing to use it remains far safer than not using it at all.
A more practical mindset is treating a transaction simulation tool as a necessary measure that substantially lowers risk probability, rather than an all-encompassing guarantee where passing means you can stop thinking about it entirely — and it's worth staying especially alert in a few specific scenarios: a transaction involving an especially large amount, a contract that was only recently deployed, an approval target that isn't a well-known mainstream protocol, or a simulated return so high it doesn't quite seem reasonable. In these scenarios, spending a few extra minutes cross-checking a contract's logic through a second, independent source — or simply holding off for a few days and letting other users encounter any problems first — costs very little while genuinely raising the margin of safety. Security was never about any single tool being airtight; it's about layering multiple defenses so that any one layer being breached doesn't mean the entire outcome is lost.
If you've read this site's article on Blind Signing risk, you might remember one specific piece of advice: before signing a transaction, run it through a transaction simulation tool first to see what it will actually do to your holdings before deciding whether to sign. That advice isn't wrong — transaction simulation tools, now built into mainstream wallets and extensions like Coinbase Wallet, Rabby, and Blowfish, genuinely catch a large number of malicious transactions. But a technique disclosed by security research team ZenGo in 2023 exposed a blind spot that had rarely been discussed publicly before in this tool once considered one of the go-to lines of defense: a malicious contract can "detect" that it's being simulated, deliberately behave well within that simulated environment, and only reveal its true nature once the transaction is genuinely broadcast on-chain.
ZenGo's team called this technique a red pill attack, and its core mechanism exploits certain "environment variables" a smart contract can read during execution — such as COINBASE, which represents the address of the current block's miner or validator. In a genuine on-chain transaction, this variable is always populated with a real, non-zero address. But in a simulated environment, since no real block or miner actually exists, some simulation tool implementations, for convenience's sake, simply set this field to the all-zero address. A malicious contract only needs a simple line of conditional logic in its code — "if COINBASE is the zero address, return a fake favorable result to the user; if it isn't, execute what I actually want to do" — to precisely distinguish whether it's currently running in a simulated environment or genuinely executing on-chain.
ZenGo's team actually demonstrated how this attack works on the Polygon chain: a malicious contract asked users to first send roughly 0.1 MATIC (worth roughly $0.10 at the time), with the simulation showing the user would receive 0.016 WETH (worth roughly $30 at the time) in return — looking like a can't-lose, highly profitable trade, and users would confidently hit confirm. But when this transaction was actually broadcast and executed on-chain, since COINBASE was by then populated with a genuine block-producer address, the contract recognized it was no longer in a simulated environment and simply skipped the reward it had promised, keeping every bit of the MATIC the user sent for itself. This research subsequently expanded in scope, finding that six mainstream wallets and security extensions — including Coinbase Wallet, Rabby, Blowfish, and Pocket Universe — all had protection gaps against this class of technique at the time. Most vendors patched the issue quickly after receiving responsible disclosure, and ZenGo was awarded multiple bug bounties as a result.
The core lesson this research reveals isn't "transaction simulation tools are useless, don't bother" — in fact, most mainstream tools have since patched this specific, now-known detection technique, and simulation continues to catch the vast majority of malicious transactions that don't involve this kind of advanced evasion trick; continuing to use it remains far safer than not using it at all. What genuinely needs recalibrating is this: the "safe" result a transaction simulation gives you is a highly reliable probabilistic signal — it was never an absolute, unbypassable guarantee, and extra caution remains warranted, especially when facing a contract of unknown origin, one recently deployed, or one deliberately designed to closely resemble a well-known protocol's interface. Concrete steps worth taking include, for especially large transactions, cross-checking a contract's logic through a second, independent source beyond a single simulation tool's output — a blockchain explorer's contract source-code lookup, for instance; staying more alert than usual toward any transaction claiming to be a can't-lose deal with a return conspicuously higher than reasonable, since that's exactly the scenario an attacker has the most incentive to fake a simulation result for; and prioritizing simulation providers that invest ongoing resources into continuously updating their detection logic against new evasion techniques, rather than treating "I ran a simulation" as a one-time check you can then stop worrying about entirely.