The $3.48 Million Mirage: How 4,224 Smart Contracts Turned Wallet Simulators Into Silent Accomplices

The number looked green. That was the trick. A wallet preview. A positive balance change. A tiny "reward" blinking back at a user who only wanted to claim what was already theirs. Then the signature. Then the silence. The deposit never arrived home — it landed in an attacker-controlled address while the safety tool that was supposed to catch the theft showed a small gain. Over the past seven days, the broader market has taught us to read red. Pools losing liquidity, TVL sliding, sentiment diaries filled with panic pages. But this attack is different. This one teaches us to question green. A July 30 arXiv preprint has quantified the exact weight of that deception. The authors linked this class of malicious smart contracts to 5,742 victim addresses and roughly $3.48 million in historical losses. Their detector, a contract-bytecode tool called SimGuard, flagged 4,224 transaction-simulation phishing contracts across Ethereum, BNB Smart Chain, Avalanche, and Polygon. Think about that number twice, because I have. This is not a stray vulnerability in one dApp's frontend. This is a systemic blindness at the most sensitive moment in the entire user journey — the split second before a wallet holder signs. Speed is the only currency that matters now, and the attackers understood it before the defenders did. A simulator snapshots the transaction, flashes an estimate, and the user signs inside the dopamine window. The attacker's code exploits that window. While the user watches a positive estimate, the malicious contract's branches are already preparing another outcome for the real chain. I have seen this market go through four distinct cycles, and each wave buried one collective illusion. In 2017, the illusion was that whitepapers equal legitimacy. In 2020, it was that yield equals safety. In 2021, it was that a profile picture equals a community. Now the illusion is more dangerous because it wears the uniform of protection: the wallet's own simulation saying, softly, "This is fine." Pulse checks on the volatile heartbeat of exchange — that's what I do daily. Today, the heartbeat is irregular. THE MIRAGE MECHANIC To understand why this works, you have to understand what a transaction simulation actually is. It is a snapshot. A pre-signing photograph of what a transaction is expected to do. Modern wallets fire off something like an eth_call against a local or RPC-based fork of chain state, read the resulting balance deltas, and render them as friendly numbers. Deposit in. Slight fee out. Maybe a small reward in. Green rows. A satisfied "estimated" label. That is the flat surface of the water. Below it, the attacker's contract contains branches — logic paths that evaluate differently depending on context. The simulation context and the execution context are not identical. They only look identical from the surface. The first variant is storage-control. The contract runs a branch check that depends on its own stored state. During the simulated call, the state yields one result: the contract shows the user's deposit plus a tiny reward, exactly the kind of positive, comforting delta that makes a tired trader sigh and connect the wallet. Then, before the transaction lands, the attacker publishes a state-changing transaction of their own — for example, adding the user's address to a blacklist. The stored state flips. The branch that executes on-chain is no longer the branch that was simulated. The deposit goes to an attacker-controlled address instead. It is a dirty trick, but a simple one. The simulation is not a promise; it is a prediction. The attacker simply engineered a scenario where the prediction could be invalidated between snapshot and settlement. The second variant is timestamp-based. The contract embeds a check such as block.timestamp relative to a deadline that the contract itself controls or anticipates. The simulator evaluates at the current or expected block time; the real transaction lands in a later block. If the code branches on "before deadline" versus "after deadline," the user can get a simulation that shows one thing and an execution that behaves as the other. No state mutation from the attacker is even required. The chain's own progression does the work. The third is gas-control. This one is more subtle, so the team deserves a slow read for it. Transaction simulators and final transactions do not always share the same gas limits. A malicious contract can read gasleft() and branch accordingly. If the simulated call allocates more gas than the actual execution envelope, the contract behaves one way. When the real transaction burns with a different gas profile, the code takes the other path. The attacker can calibrate the contract so that generous simulation conditions trigger the benign branch, while the tighter real-world gas budget triggers the theft branch. I have audited hack postmortems long enough to recognize a brutal elegance here. None of these variants require a zero-day in the wallet client. The vulnerability is not in the signing code. It is in the assumption that a simulation is a rehearsal — that what the sandbox displays will be what the chain performs. The attack is less a software exploit and more an exploitation of the semantic gap between two execution environments. The gap becomes a gulf when you add the human factor. A user sees a reward. A user thinks they are claiming yield, or pulling an unlucky position out of a failing pool. The green number validates the signature. That is the attack surface, and it is the most heavily trafficked intersection in crypto: the place where trust meets action. SIMGUARD AND THE DISTRIBUTION OF PAIN The researchers did not just describe the technique. They built a detector to hunt it at scale. SimGuard scans contract bytecode, which is the actual compiled code that runs on-chain rather than the source code developers claim to publish. This distinction is important in a market where, based on my audit experience, source-code verification is too often treated as proof of virtue. Bytecode does not lie about branches the way a README can. The team identified 4,224 transaction-simulation phishing contracts across the four chains. Ethereum accounted for the overwhelming majority of the financial damage — about 91.5% of the estimated loss. The single largest inferred cluster of contracts, one presumed operator ecosystem, accounted for roughly 83% of the cross-chain total. I have seen this concentration pattern before in wallet-drainer telegram infrastructure; one operation does not build one contract, it builds a factory of variants. The cluster number is coherent with the reality that drainer-as-a-service is an industry with franchisees, upgrade cadence, and even customer support. The researchers linked the contracts to 6,223 victim transactions and 5,742 victim addresses. They called the $3.48 million figure an upper bound, because some of the activity the detector classified as victim activity may have been the attackers testing their own scaffolding. This number is conservative in a different way too. The history of recorded losses in crypto is a history of undercounting, because anonymous victims quietly walk away, embarrassed, never filing a report. The observation window deserves scrutiny. The preprint itself contains inconsistent figures for its Avalanche contract count and conflicting endpoints for the observation period. When a paper's own parameter table disagrees with its abstract, I read that as a signal that the data pipeline was stitched together over time, not as a smoking gun of fraud. But it does mean the per-chain breakdown and the exact time window remain unresolved until the authors publish a cleaned version. Also unresolved: what the victims actually saw. The paper does not identify the wallet versions, settings, or simulation backends used by the affected addresses. That is a huge empty space in the story. Knowing that 5,742 people were tricked is one thing. Knowing which wallet software failed them, and in which configuration, would be the difference between a paper and a fix. MetaMask's current documentation, publicly available, already calls estimated balance changes exactly what they are: predictions. The documentation warns that the final outcome is not guaranteed. That warning exists because wallet teams know the simulation layer is imperfect. What they may not have anticipated is how efficiently attackers weaponized that imperfection. THE 1-WEI AUDIT The researchers ran a controlled test. They took an account balance and sent it to a contract that returned as little as 1 wei — the smallest possible unit of ETH. Coin for coin, that is a refund of essentially zero. A rounding error. A dust speck. Yet several tested wallet previews displayed a positive estimate. Most did not clearly show the full outgoing amount. Let me sit with that detail a moment, because it is the hinge that the entire scam swings on. The preview said: small inbound. The preview did not say: massive outbound. The attackers did not need to hide the outflow completely. They only needed to make the inflow visible and the outflow ambiguous. When a balance delta is rendered as a single net number, a positive net figure overrides every other cue. The number was green. That was the trick. This is the UX pattern that the paper's UI findings explicitly attack. Their recommendation: show the gross amount leaving a wallet alongside an accurate net balance change, so that a negligible refund cannot be mistaken for profit. If a user sees "1 wei in, 1.2 ETH out," the transaction loses its disguise instantly. If a user sees only "+1 wei net," the attacker has already won the psychological round. I think about 2017, when I published the first Vietnamese-language breakdown of Golem's IPFS integration within 24 hours of its announcement. I was proud of speed, not of depth. I digested technical jargon quickly and pushed the hype potential to the front of the paragraph. That habit — speed over scrutiny — is the exact cognitive pattern these contracts exploit. The slower the user reads the preview, the safer they are. The industry built its entire UX around speed. The attackers built their contracts around that speed. Liquidity flows where the heat is highest. And in this attack, the heat is the green row. THE CLAIM() PAPER TRAIL The paper points to a concrete on-chain case: a Jan. 8, 2025 Etherscan transaction recording a Claim() call that moved approximately 143.45 ETH through a contract Etherscan labels as phishing. The on-chain record supports the transfer described in the paper. What it cannot show is what appeared in the victim's wallet preview. That gap — the unreachable moment between the simulated frame and the executed frame — is exactly the gap these contracts occupy. 143.45 ETH. At the time of writing, a value that would have been a life-changing sum for most retail users and a shrug for an institution. The choice of the function name is thematic. "Claim" is the most trusted word in DeFi. Users claim rewards. Claim their airdrops. Claim their staking yield. The word is a promise. The contract weaponized grammar. I look at that Etherscan page and I see the darker parallel to the ETF era I now work in. When BlackRock's IBIT filings landed, my job was to decode dense legal language into retail-friendly action. Institutional trust in crypto is the story of translation: converting opaque documents into legible routes. The attackers are doing translation too — in reverse. They translate a theft into a claim. The 4,224 figure matters for builders. If this were a single contract, a wallet team could add a blocklist and move on. But a factory-of-variants approach means the same logical flaw is re-deployed with fresh bytecode faster than any address-based blocklist can evolve. SimGuard's real contribution is not a blocklist. It is a triage lens. The detector looks for simulation-sensitive branches — code paths whose output depends on state, time, or gas in ways a simulator might not reproduce. That is a pattern, and patterns scale better than denylists. WHERE THE PAPER STOPS, THE NOISE BEGINS Here is where I have to be the journalist who has written about enough studies to read the fine print. The findings have not been peer reviewed. That alone does not disqualify them — the entire crypto industry's most cited security research began as preprints. But it does mean we should treat the aggregate numbers as directional, not as an audited ledger. The detector evaluation covered 44 contracts. Thirty of those were generated with Gemini, a respected large language model, used here as a synthetic test-bed for producing malicious branch patterns. That is a clever methodological move, but it also means the detector's precision is calibrated largely against machine-generated malware, not the full commercial toolkit of professional drainer operations. The linked code-and-data repository returned HTTP 401 when the researchers checked it. Translation: the reproducibility artifact is behind an authentication wall. Right now, an independent researcher cannot re-run the pipeline. The aggregate results remain the authors' findings rather than an independently reproduced measurement. In a field where a single fabricated dataset can manufacture an entire narrative, that distinction is not academic pedantry. It is the difference between a map and a rumor. And yet. Even under a skeptical reading, the core mechanism is undeniable. The controlled test with the 1 wei refund is a laboratory demonstration, not an unverified claim. The authors themselves disturbed their own account. They observed the misreporting with their own eyes and across multiple preview tools. That part is reproducible by any security team willing to spend an afternoon. I have seen enough exploit write-ups to know that when a minimal proof-of-concept succeeds, the production versions almost always succeed at scale. The preprint describes historical activity involving these malicious smart contracts. It is not a live July or August attack wave. The word "historical" matters, because crypto's attention cycle punishes reports that do not scream urgency. I will not rewrite this as "wallet simulators are broken right now, panic." What I will write is: the attack class exists, the damages are real, and the fix has not shipped. THE REGULATORY GHOST Nobody in the paper discusses the licensing question. I will. I watch two Asian financial hubs with sharp personal interest. Hong Kong is pushing virtual asset licensing with theatrical energy, and I have a technical position on this that I will let the evidence whisper: the licensing push is not about embracing innovation, it is about stealing Singapore's spot as Asia's financial hub. Regulatory competition is a real force. Meanwhile, the entities building the simulation engines inside your wallet are not the primary targets of either regime's licensing framework. The regulators are focused on venues: exchanges, custody, broker-dealers. They want to know which platform is allowed to touch client money. But the attack described in this paper happens at a different layer entirely. It happens between the user's intent and the signing ceremony. It happens inside a function that most regulators would not even think to audit: the balance-estimation preview. This is the institutional translation failure. I translated BlackRock filings into retail-friendly guides, and the core lesson was always the same: regulation follows the asset, not the behavior. The asset here is a user's private key, and the behavior is a blind signature. No license in the world protects a user who signs a transaction whose simulation lied to them. If Hong Kong or Singapore genuinely wanted to out-position the other as Asia's digital-asset safety capital, the smarter move would be a regulatory sandbox specifically for wallet simulation accuracy standards. Require wallet providers to disclose the gross outflow in every preview. Require simulation backends to certify their handling of state-dependent branches. That is hub-positioning through user protection, which is the only long-term competitive advantage in a trustless market. Neither hub has done that. They are fighting over the title of the financial center while the drainers occupy the unregulated territory of the transaction lifecycle where the actual damage happens. Digital gold rushes turn pixels into portfolios, but they also turn blind signatures into empty accounts. THE UX WAR THAT NOBODY DECLARED Now the uncomfortable part for the builders reading this. The fix that the paper recommends — showing gross amounts leaving a wallet — sounds easy. It is not. I have sat in enough product discussions to know the trade-offs inside the wallet UX debate by heart. Mirror the numbers: net balance changes are clean. They reduce anxiety. They are the reason a casual user can look at a preview and understand it without a finance degree. If every transaction displays a huge outgoing amount alongside a tiny incoming amount, even the most legitimate swap looks like an armed robbery. Users will start ignoring the display entirely, which is the worst possible outcome for security. Safety messages have a half-life; repeated alarms become wallpaper. The researchers are not naive to this. Their recommendation is to show gross outflow alongside an accurate net figure. The accuracy of that net figure is the hard part. A negligible refund cannot be mistaken for profit only if the refund is correctly labeled as negligible. That requires the simulation to run against the exact state the transaction will actually hit, with the exact gas parameters the real execution will use. Their practical recommendations are precise and honest: re-run the simulation when relevant contract state or gas fields change; use the gas limit and gas price from the actual request rather than a default; test the transaction against both current and future block-number and timestamp inputs. These are not exotic requests. They are the bread and butter of robust static-dynamic hybrid analysis. The reason they are not universally implemented in wallet backends is not technical impossibility. It is the tension between simulation cost and user latency. Speedy wallets became a brand. "Fast" is stamped on every product page in this industry. But speed is the quality the attackers weaponized. A simulator that re-runs on dynamic state changes is a simulator that sometimes takes half a second longer. In a bear market where every second of user attention is fought for, a delayed preview feels like a product regression. Yet, measured in dollars and dignity, the delayed preview is the cheaper failure. PULSE CHECKS ON THE VOLATILE HEARTBEAT Let me be practical, because a report of 5,742 victim addresses is an accusation of my entire profession's failure to translate risk honestly. Whether your funds sit in an exchange or a self-custody wallet, there are concrete behaviors that degrade this attack class. First: trust the gross number if it is shown. If the preview offers detail, expand it. A net positive number means nothing if the gross flow is one-directional toward a contract with no verified source code. In my 19 years of watching this industry, most of the funds lost to malicious contract interactions were lost to users who never clicked the "detail" toggle. The information was there. The attention was not. Second: re-simulate before the final signature if the transaction has been sitting in memory for more than a few minutes. The timestamp-based variant exploits exactly this decay. A preview generated during block 22,100,000 is worthless by block 22,100,025 if the contract branches on time. If your wallet has a "re-check" affordance, use it. If it does not, cancel the transaction and re-initiate it. The cost of the click is tiny. The cost of the loss is not. Third: segregate holdings by risk profile. ZachXBT's recent work on the hundreds of MetaMask wallets drained through fake update emails — $107,000 across hundreds of wallets — teaches the same architectural lesson: the wallet connected to your claim-and-reward behavior should not be the wallet that holds your long-term assets. Cold storage is not a technology solution; it is an attention solution. It reduces the number of moments where a blind signature can be used against you. Fourth: treat on-chain contract labels like weather forecasts, not like gospel. Etherscan labels a contract phishing after the fact. The label describes history, not intent. A contract with no label and a verified source that mirrors a known template deserves the same suspicion as an unverified one. Bytecode is the only language that cannot be lied to, and most users never read it. These are the survival mechanics of a bear market. The industry's default media posture is to chase new narratives. But the data here is unequivocal: malicious simulation-feedback contracts accumulated $3.48 million in upper-bound losses mostly on Ethereum, and their detection required a purpose-built bytecode tool because routine security vendors were not catching them. What does that say about the other threats that are still invisible because no one has built the detector yet? That question should keep every security engineer awake. THE CONTRARIAN READING: THE REPORT IS ALSO A LANDSCAPE PAINTING I want to argue with the paper's frame for a moment. The authors frame the problem as a deficiency in transaction-simulation accuracy. That is true. But there is a deeper imbalance the paper touches only implicitly: the asymmetry of time. The attacker can modify state before the transaction lands. The wallet, by design, only previews state at one instant. No improvement in simulation fidelity can fully close that gap if the contract retains write access to the branches the user will execute. The correct unit of analysis is not the simulation. It is the contract's capability set. If a contract can change its own storage in a way that flips a branch between simulation and execution, then the only safe simulation is one that treats the contract as hostile its entire lifetime. That is a massive requirement shift. It converts wallet safety tools from verifiers of a single transaction into continuously vigilant monitors of every interaction target's state history. No consumer wallet has that depth today. The paper's recommendation to "re-run simulations when relevant contract state changes" is sound, but it ignores an operational reality: in a mempool-driven environment, the relevant state can change between the moment the simulation finishes and the moment the transaction is included. The re-run helps. It does not guarantee. The only complete guarantee is to eliminate the blind-signature moment from the user flow entirely. That is the direction in which I expect the industry to move. Intent-based architecture, where users sign their desired outcome rather than a raw instruction, is the institutional endpoint of this attack's evolution. The signature becomes a declaration of intent, and the solver that executes it is responsible for meeting the declared condition. If the condition is "my balance must increase by at least X minus fees," then a malicious branch that sends the deposit elsewhere fails the condition by construction. Amidst the noise, the smart money whispers this exact direction. The traders I talk to daily are less interested in new meme launches and more interested in which infrastructure can credibly assert "we never show a green number unless the green number is real." Trust, in a bear market, is the only countercyclical asset. THE UNCOMFORTABLE QUESTION ABOUT OUR OWN LANGUAGE I have spent a decade translating this industry into human language. So I cannot ignore the linguistic dimension of this attack. The contract function is named Claim(). The attacker harnesses a word that means "to take what is rightfully yours." The victim was likely attempting to recover funds or rewards that felt owed. The malicious contract exploited the emotional grammar of entitlement. We want to believe the chain remembers our deposits. We want to believe the protocol owes us a yield. An attacker who labels the theft as a claim is trading on that belief. This is similar to what I wrote during the NFT mania of 2021, when I predicted the shift from speculative trading to cultural ownership. Back then, I argued that the story behind an asset had become a market indicator. The lesson generalizes: the story behind a button is its function name. A contract that says Claim but does not claim is a contract that is reading its target's psychology, not its balance. The industry loves to discuss whether NFTs need dynamic metadata or whether Bitcoin should carry BRC-20 tokens. I have a technical position: putting BRC-20 and Runes on Bitcoin is like using a Rolls-Royce to haul cargo — it insults the car and does not carry much. But the debate itself obsesses over features while the drainers optimize for a much more primitive vector: the gap between what a word promises and what code executes. Every layer of unnecessary abstraction, every extra branch, every clever dynamic behavior adds surface area for the next mirage. Riding the wave before it crashes back: that is the market's old skill. The new skill is reading the ebb — recognizing when the code is no longer acting like its label. A dynamic NFT whose metadata changes based on external state is, architecturally, the same idea as a malicious contract whose branch changes based on block state. The feature is neutral. The intent is not. The NFT artists I interviewed during the 2021 boom wanted programmable royalties and dynamic traits. What they needed was stable buyers. In the same way, users want sophisticated simulations, but what they need is the truth in gross numbers. Complexity is not a feature. It is an attack surface. WHAT THE REPORTS CANNOT SHOW Let me close the analytical loop by listing what remains unknown, because intellectual honesty is the only thing that separates journalism from propaganda in this industry. The paper does not name the wallet versions, settings, or simulation backends used by the victims. Without that data, wallet teams cannot determine whether their own products already mitigated or still exhibit this flaw. The finding is general. The fix is necessarily specific per product. The detection evaluation involves 44 contracts, mostly machine-generated. The real-world population of malicious contracts contains thousands of hand-tuned variants, often deployed in short-lived bursts designed to evade scanners. SimGuard's false-negative rate against that population is unknowable from the preprint alone. The $3.48 million figure is an upper bound. The true number almost certainly lies somewhere between the clean and the dirty count, but where exactly depends on which transactions were the attackers' own tests. More importantly, the figure does not include the largest possible cost: the silent erosion of user confidence in wallet safety tools. Every victim who stops trusting the preview is a victim of a second-order attack vector that has no dollar figure in this paper. The HTTP 401 on the code repository is the most fixable problem. The authors should open the artifact. I do not say this with malice; I say it because I have seen how reproducibility accelerates defense. When the DeFi summer produced its flood of audits, the teams that published their tooling contributed more to ecosystem safety than any single report did. Open code is the fertilizer of security. A MANUAL FOR THE NEXT SIX MONTHS Given the bear market context, every reader is asking one question: is my asset safe? The answer, based on this paper and my own experience in exchange security, is neither simple nor comforting. It depends on whether your wallet is showing gross detail, whether your transaction is re-simulated against current state, and whether you are willing to cancel and re-initiate a transaction that has been waiting too long. Here is my checklist for every interaction until the industry fixes this class of vulnerability: If the preview shows a positive net change but the transaction has any external call to a contract you have not interacted with before, expand the details. Find the gross outflow. If the gross outflow is larger than your discretionary risk tolerance, abort. If you are about to sign a transaction that was constructed more than five minutes ago, re-initiate it. Timestamp-based and state-based branches decay quickly. If a contract labels itself with a trusted function name like Claim or Withdraw, verify that the calling address matches the address you have transacted with historically. Drainers frequently spoof familiar entry points. Keep access tokens and interacting keys separated. The wallet that signs claims and claims’ own rewards should never be the wallet that holds your principal. Do not over-trust labels. Etherscan labels are historical annotations, not risk scores. A freshly deployed contract with a generic name deserves the same suspicion as an unverified one. These steps do not require a security degree. They require the same patience that the market's 2017 ICO fog taught me: in the fog, the fastest narrative was not the truest one, and the trader who decelerated usually kept their capital. Chasing the green candle through the ICO fog was my first lesson in how easily speed becomes a liability. The lesson has never aged because the human brain has not changed. THE LONG GAME The takeaway is not merely "simulation is imperfect." The takeaway is that security tools that display net numbers are vulnerable to communication failure as much as computation failure. The men in suits who run the institutional desks whisper one phrase when they look at this preprint; they say the liability now rests on whoever renders the safer-looking number. If a wallet shows a positive net change, and the user loses the deposit, who bears the responsibility? The contract? The attacker? Or the interface that displayed the mirage as profit? That question will be answered not by papers but by litigation. The ETF era taught me how institutional money reacts to new risk classes: first denial, then parsing, then standards. We are in the parsing stage. The industry's next cycle will be defined by who can credibly claim to render the gross truth. The wallet that shows "1 wei in, 1.2 ETH out" might lose some conversion in the short term, but in a bear market, conversion matters less than retention of trust. From frenzy to function: tracing the cycle from 2017's whitepaper fantasy to 2025's simulator fantasy, the pattern is identical. Every cycle, the industry builds a layer of convenience, and every cycle, the drainers find the gap between the layer and the ledger. The speed story is over. The truth story has begun. And while the researchers refine the detector and the wallets refine the UI, the practical vote is simple. The next time you see a green number in a preview, treat it as a hypothesis, not as a verdict. Look for the red that may be hidden behind it. The market will reward the cautious, because the cautious are the ones who survive long enough to compound. Liquidity flows where the heat is highest, but survival flows where the clarity is strongest. And clarity, in this market, is the only edge worth paying for. The deposit looked safe. The preview said so. But the preview was never the witness. The chain was the witness. Always, every time, the chain was the witness — and it recorded the theft exactly as it happened. From now on, read the ledger as if your balance depends on it. Because it does. From my desk in Ho Chi Minh City, watching the mempool move on a Tuesday when the market holds its breath: the ether is flowing somewhere. The only question is whose ledger claims it. One more thing. When the next exploit drops — and it will drop — the inevitable hot take will be "the simulation layer failed." That is incomplete. The simulation layer did not fail. It was never designed to be a validator. It was designed to be a convenience. We confused a convenience with a guarantee, and the attackers simply charged us tuition for the confusion. The tuition was $3.48 million. The enrollment was involuntary. The course is now in session, and the final exam is whether we rebuild wallet previews around gross outflows, re-simulated state, and honest labels before the next wave begins. Let me be blunt: I do not expect to write about the last drainer this decade. I expect to write about smarter drainers. But I also expect — and this is a rare optimistic note from a bear-market journalist — that the victims of this specific scam class are the strongest educational force this industry has. Five thousand seven hundred forty-two addresses. Each one a memory that a green number can lie. Imagine a solution that fires not when the code is malicious, but when the preview's net figure is too good to be true relative to the gross flow. That solution will be a product. It will be called something like "gross-first display." It will be boring. And it will save an order of magnitude more value than the most exciting AI agent wallet ever launched. From my experience as Exchange Market Lead, I can tell you which one institutional flow will ultimately reward; it is the boring one. The heartbeat is steady again. The pulse check is done. The next check is up to you. When you sign, sign like the preview could be lying. Because in this market, the preview usually isn't the whole story. The story is always in the branch that executes. And now you know where to look.