The Net Result Illusion: Ethereum's Proposed Safety Checks Have a Blind Spot

Read the security guidelines attached to EIP-7906 and you find something rare in this industry: a specification that warns you about itself. Buried in the draft are two admissions — a time-of-check-to-time-of-use gap and a mechanism called "reference value pollution" — that quietly undo part of the promise on the cover. The proposal wants to let your wallet reject a bad trade after it executes. The fine print says the protection strategy "must survive the actions it is supposed to judge." In a composable DeFi stack, that is a very tall order. I have spent three weeks reading this draft against the protocols I actually use, and the distance between the headline and the mechanics is exactly where your money lives. Trust is no longer a promise; it's a protocol. But a protocol that the person building your transaction can quietly weaken is not a promise at all. It is a suggestion wearing armor. In a bear market, when every lost ETH is a lost month, that distinction is everything. Here is the shape of it. EIP-7906 is a draft standard for something called transaction assertions — rules attached to the end of a transaction that inspect the net result and roll everything back if the outcome breaks your limits. It does not stand alone. It depends on EIP-8141, which introduces "frame transactions" that split validation from execution into separate frames. On top of that, EIP-7906 appends a read-only POST_TX frame — a final checkpoint where assertion code can read what actually changed and refuse to accept it. That layering matters. EIP-8141 is only "planned for inclusion" in the Hegotá upgrade. EIP-7906 is merely "considered for inclusion." Both are drafts. Neither is on a testnet. If you are hearing "Ethereum is about to protect your trades," you are hearing a roadmap, not a release. The draft was created in February 2025, and by late 2026 it still sits in discussion. That is not a delay. That is Ethereum's normal tempo, and you should plan around it. It is worth remembering what "considered for inclusion" has meant historically: a large share of those proposals never reach an upgrade at all. They get debated, refined, and quietly shelved. Price this near zero for the next twelve months. Now compare it to what already exists. Uniswap v3 has amountOutMinimum — a floor baked into the call parameters, and its example router default is zero. Safe has guards that check arguments before execution and state after. Clear Signing, announced by the Ethereum Working Group on May 12, 2026, makes a transaction readable at signing time, but it does not impose any minimum financial outcome. Simulation predicts an outcome before it lands, though the state can shift before inclusion. Each covers part of the problem. EIP-7906's pitch is a wider view: instead of checking a parameter, it checks the net effect of the whole transaction. That is genuinely more ambitious. It is also where the trouble starts. The proposal defines three new instructions. TXTRACE enumerates specified net changes and events. TXDIFF retrieves values by key. EVENTDATACOPY makes event data available to the assertion. Their scope covers native ETH balances, storage changes, newly deployed contracts, and code hashes. That sounds comprehensive until you notice what it does not cover out of the box. Token balance checks still require the assertion to interpret the relevant contract's storage and enforce whatever limit you chose yourself. Read that again. "Token-level assertions" are not free. ERC-20, ERC-721, ERC-1155, non-standard tokens, rebasing tokens — each demands its own storage interpretation. Based on my own audit work, this is where the real cost hides. The barrier to EIP-7906 is not cryptography. It is the standardization of token balance parsing. Nobody is talking about that, and it will decide whether this ships on time. Then there is the design flaw at the center of everything: the net result view. If a transaction writes to the same storage slot multiple times, the assertion sees only the starting value and the final value. Intermediate states collapse. And if a slot is restored to its original value, it vanishes from the enumeration entirely. Think about what that hides. A transaction that briefly drains an asset and returns it before the frame ends shows a net change of zero. A flash-loan or reentrancy attack that borrows, manipulates, and repays inside one transaction can leave a net footprint that is small — or invisible. The assertion checks the balance sheet at closing. It does not see the knife. This is the single most important thing to understand about outcome-based safety: a clean ending does not mean a clean process. I have watched users lose funds to hooks I could have caught in a review — a malicious Uniswap v4 hook, a flawed StablePair implementation. Those losses came from contract-layer deception, not slippage. And I keep asking the same question of EIP-7906: does a net-result assertion catch a hook that lies? If the hook returns a plausible final balance, the net view looks clean. The lie survives the check. That is not a flaw in the instructions. It is a limit of outcome-based thinking itself. The proposal itself is honest about two more holes. The first is TOCTOU: a transaction could change the execution contract after validation but before the final check. The stated mitigation is that assertion targets must be immutable and non-upgradeable. Reasonable — but most DeFi protocols run upgradeable proxy contracts. Requiring immutable targets either excludes them or forces a re-architecture. That is a migration cost dressed up as a security feature, and it lands on the same teams already stretched thin in a bear market. The second is reference value pollution. If a transaction moves the very price used to judge its own outcome, then reading the true final state cannot save the comparison. The guidance suggests reference values be fixed at signing time or read from the transaction's starting state. Good advice. It is also an admission that the mechanism is only as trustworthy as the number it compares against. Which brings us to oracles. The draft notes that ordinary oracle risk remains, because an earlier transaction in the same block can move that starting state. In an MEV environment, this is not a footnote. It is the whole game. Searchers profit by reordering; assertions try to lock outcomes. Those two impulses are structurally opposed, and the searcher moves first. Finally, scope. The guarantees apply only to a single transaction on a single network. The moment you touch a solver-based settlement flow, a cross-chain route, or a batch, the protection narrows. Solvers only stay bound if the signed order or settlement protocol explicitly binds them to the policy. That is a lot of ifs between you and safety — and cross-chain is exactly where the biggest losses happen. There is also the economic design. If an assertion fails, the execution rolls back, but the transaction still lands in a block, and whoever paid for gas still pays the consumed gas. Failure is not free. It is billed. Which means the builder collecting that fee has little incentive to make assertions stricter. The economics quietly favor loose rules. The model is opt-in and strongly constrained, but only if you configure it right. The proposal does not require every transaction to carry an assertion. But an account that relies on assertions must enforce a specific POST_TX frame in its validation logic, without a bypass. Get that configuration wrong and the protection is not weak — it is zero. Security here is a setting, and settings get misconfigured. And remember who sets the floor. A builder can derive a minimum from an already-bad quote and preserve a terrible trade inside a "protected" envelope. Deriving a limit from bad data just launders bad data. Real protection needs an independent source — an SDK, an oracle, something outside the transaction's own frame. Zoom out and the strategic read is clearer. Ethereum's account abstraction and intent roadmaps are converging on the same idea: let users express outcomes, and let the machine enforce them. EIP-7906 is a brick in that wall. But bricks need mortar, and the mortar here is standardization that does not yet exist — for token balances, for reference values, for cross-domain settlement. Until the mortar sets, the wall is decorative. This is the part I keep coming back to. The mechanism's existence is not the protection's existence. Every downstream integrator — wallets, smart accounts, DEXs, solvers — is a place where a loose rule can be chosen. Broad integration is broad attack surface. Here is the counter-intuitive angle, and it cuts against my own enthusiasm. Everyone treats "more safety rails" as unambiguous progress. I do not. A half-built rail can be worse than no rail, because it changes behavior. If a user sees "assertion-protected" on a signature screen and relaxes, they are now more exposed than before the feature existed. The risk is not asset loss at the protocol layer — there is no pool, no token, no custody. The risk is trust mismatch: relying on a shield a builder can hollow out. The deeper question is who owns the rule. A protocol-level standard sounds neutral, but neutrality is only as strong as its weakest integrator. If one wallet ships a default floor of zero — and one already does — the standard protects no one who uses it. This is not a reason to abandon the work. It is a reason to be precise about what it does and does not promise. I learned to stop preaching and start listening, and what users actually tell me is simple. They do not want more settings. They want to know the number is real. Code is law, but empathy is the interface — and an interface that promises protection it cannot guarantee is neither. So what should you do with this? Treat EIP-7906 as a signal, not a solution. It is a serious, self-critical attempt to standardize transaction outcome safety, and its honesty about its own weaknesses is a good sign. But it is a draft depending on another draft, years from mainnet, and its central promise — a net result you can trust — is structurally blind to the intermediate moves that actually hurt you. Watch for the token-storage standardization problem to be solved before you believe the timeline. And until then, keep your own floor independent. Trustless systems require trusting relationships, and right now the only one you can fully trust is the one you verify yourself.