A storage slot written twice and restored to its original value vanishes from Ethereum's proposed assertion mechanism. Not flagged. Not logged. Gone. That single line in the EIP-7906 draft is the difference between a transaction safety standard and a compliance formality. The proposal was created on February 21, 2025, and as of this writing it still sits at "considered for inclusion" for the Hegotรก upgrade โ one rung below EIP-8141, the frame-transaction standard it cannot function without, which itself only reached "planned." The Ethereum Foundation published supporting research on October 5. The Ethereum Working Group announced a companion Clear Signing standard on May 12. The scaffolding reads as complete. The ledger does not. Flaws hide in the decimal places, and this proposal has several of them.
EIP-7906 proposes transaction assertions: read-only POST_TX frames appended to a transaction that inspect the net state change after execution and reject the trade if it violates a rule signed by the user. It builds on EIP-8141's frame transactions, which separate validation from execution. Three new instructions carry the load โ TXTRACE enumerates net changes and events, TXDIFF retrieves values by key, EVENTDATACOPY exposes event data to the assertion. The scope covers native ETH balances, storage changes, newly deployed contracts, and code hashes.
The mechanism exists because the current stack leaks. Uniswap v3's amountOutMinimum sets a floor inside call parameters โ execution-time conditions the router may leave at zero. Safe guards check parameters before execution and final state after. Clear Signing, announced May 12, makes signatures human-readable but, as its own specification concedes, imposes no minimum financial outcome. Simulation predicts effects against a chosen state that may shift before inclusion. Each tool covers a slice. None covers the transaction's whole net effect.
EIP-7906 tries to. The pitch is a wider view: instead of trusting a router's parameter or a simulation's guess, the account signs an assertion that the protocol itself enforces. That is genuinely new. It is also where the problems begin, because the "net" view is narrower than it sounds.
The dependency chain matters more than the feature list. EIP-7906 cannot activate before EIP-8141, and EIP-8141 is not live. The proposal was created on February 21, 2025. It remains a draft. "Considered for inclusion" is not "scheduled," and Ethereum's history is littered with considered proposals that never reached a fork. Anyone pricing this into a timeline is pricing a draft that depends on another draft, both gated behind an upgrade that has not shipped.
The net result view is the proposal's load-bearing wall, and it is hollow in the middle. When a transaction writes to the same storage slot multiple times, EIP-7906 collapses those writes into a start value and an end value. If the final write restores the original value, the slot drops out of the enumeration entirely. Consider a flash-loan sequence that borrows against a pool, moves the balance through three intermediary addresses, and repays before the transaction closes. Net change to the pool: zero. The assertion sees nothing. The attacker walks away with the fee, the slippage, or the reentrancy profit, and the "protection" reports a clean ledger. A mechanism that only sees endpoints cannot judge a path. Tracing the ghost in the ledger, byte by byte, the ghost has learned to enter and leave between the two points the assertion reads.
That is not a hypothetical class of attack. Reentrancy and flash-loan manipulation are defined by transient states. The proposal's own design filters out exactly the states those attacks live in.
I have traced this pattern before. In 2020, while building a Python tracker for Curve Finance's stablecoin pools, I found that "impermanent loss protection" was being farmed by market makers using flash loans โ reward tokens inflated 40% with no corresponding value accrual. The mechanism reported healthy numbers while the underlying economics bled. The net result view is the same category of error: a clean summary that hides the transaction that caused the damage. Impermanent loss is not luck; it is mathematics. So is a zero net change that paid an attacker.
The second structural flaw is a time-of-check-to-time-of-use gap. The assertion runs after execution, but the transaction may change the execution contract after validation and before the final check. The draft's security guidance acknowledges this and requires that assertion targets be immutable and non-upgradeable. Read that requirement against reality: most live DeFi protocols run behind upgradeable proxies precisely so they can patch themselves. EIP-7906's mitigation for TOCTOU collides head-on with the architecture the industry actually deploys. A protocol that wants assertion coverage must either freeze its contracts โ surrendering its upgrade path โ or accept the gap.
Reference value poisoning is the third, and the proposal names it without solving it. If a transaction changes the price or registry value used to judge its own outcome, reading the true final state cannot save the comparison. The draft recommends that reference values be fixed at signing time or taken from the transaction's starting state. In a single block, an earlier transaction can move that starting state. The draft concedes this: ordinary oracle risk remains because earlier transactions in the same block can shift the baseline. The assertion cannot outrun MEV, because the adversary trades in the same block the assertion is anchored to.
Then token balances. The instructions handle native ETH, storage, and code. Token balances require the assertion to interpret the relevant contract's storage and apply its own limits. That means every token standard โ ERC-20, ERC-721, ERC-1155, non-standard tokens, rebasing tokens โ needs bespoke decoding. The real barrier to EIP-7906 is not cryptography; it is standardizing how a dozen incompatible balance models get parsed inside a read-only frame. The article never develops this, and it is the detail most likely to decide whether the proposal ships or stalls.
Now the economics. A failed assertion rolls back the execution body, but the transaction stays in the block, and the payer is still charged the gas consumed. The model is fail-and-pay. For the user, that is a trade that did not happen plus a bill. For the block builder, it is fee revenue. The party best positioned to tighten assertion strictness has no economic reason to do so. This is the article's central worry restated in arithmetic: builders can weaken the rules, and the fee structure rewards them for it.
And weakening is easy. A floor derived from an already-bad quote preserves the bad trade. The draft needs an independent data source โ an SDK or oracle โ to set a meaningful minimum, and nothing in the protocol forces one. The account must, in its validation logic, require a specific POST_TX frame without a bypass. That is an opt-in strong constraint: security is entirely a function of correct account configuration. Misconfigure it, and protection is zero. This is not a criticism of the design's intent. It is a description of its attack surface. Every opt-in safety feature has the same property: it protects only the users who configure it correctly, and it misleads the users who assume it is on by default.
The scope limitation compounds everything. The guarantees apply only to a single transaction on a single network. In a settlement flow where a solver chooses the execution path, binding the solver to the policy requires the signed order or the settlement protocol to enforce it. Cross-chain, multi-hop, and batched routes โ precisely where funds are lost most often โ sit outside the assertion's reach.
One more layer deserves attention. If centralized frontends and wallet providers set the assertion rules by default, the protection becomes a policy they choose, not one the protocol guarantees. The user signs a rule they did not author, enforced by a frame they cannot verify. That is the same trust posture as today's routers, dressed in protocol language. The draft's own formulation is sharper than any critique: the policy must survive the actions it is supposed to judge. In my audit of the 2017 Tezos delegation contracts, three logic flaws sat in code the whitepaper described as secure โ the third went unpatched and produced the liquidity dip I had modeled. Code that judges other code inherits every assumption of the code it judges. Nothing in EIP-7906 isolates the assertion from that inheritance.
Here is what the skeptics miss, and what the proposal's authors got right. EIP-7906 does not pretend to be a shield. Its own security guidance names TOCTOU and reference value poisoning before any critic does. The requirement that assertion targets be immutable and non-upgradeable is not an oversight โ it is a deliberate trade of flexibility for tamper-resistance, and it is the honest choice. The three-instruction design is lean, and the decision to keep POST_TX read-only means the mechanism can only veto, never silently rewrite. That constraint is a feature: an assertion that could modify results would be a far larger attack surface. The proposal is not naive about its own weaknesses; it is candid about them. What it cannot do is make DeFi's transient states visible, and no amount of candor fixes a view that filters them out. The chain never lies, only the observers do โ and here the observer is deliberately blind to the middle of the trade.
The proposal also has a credibility advantage the DeFi sector rarely earns. The Ethereum Foundation published the supporting research; the Ethereum Working Group owns the Clear Signing standard; the process is public and adversarial by design. Compare that to the FTX case I worked in 2023, where $8 billion in unallocated user funds moved through over 400 wallet addresses while audited reports showed a $4.2 billion gap. There, no one could see the ledger. Here, the ledger is open and the draft's authors publish their own limitations. History is written in blocks, not headlines, and the blocks favor this proposal's transparency even as they expose its gaps.
The question is not whether EIP-7906 is safe. It is whether users will mistake its existence for protection. A mechanism that hides intermediate states, collides with upgradeable contracts, cannot outrun MEV, and charges you for failing has a narrow job โ and an honest one. The danger is the gap between what it does and what people will assume it does. When the next nine-figure exploit settles, ask which assertion was supposed to catch it, and where that assertion was looking. Every exit is an entry point for the truth โ including the exit the assertion never sees.