Ethereum explores native assertions against blind signing

The Ethereum Foundation’s “Trillion Dollar Security” initiative is exploring native transaction assertions as a mechanism to combat blind signing and transaction uncertainty. Its October 5 blog post lays out a mechanism where onchain code inspects the full set of net state changes after a transaction’s actions have already executed — not before, not during.

The rule lives inside the transaction itself. A user signs it alongside the actions; read-only logic then compares starting and final values against that rule, reverting everything if the rule fails. That gives users a transaction-level check on what actually happened, which the Foundation frames as a fix for two distinct failure modes: intent mismatch and outcome mismatch.

Both have real incidents attached. Bybit and BadgerDAO both involved users authorizing permissions they never meant to grant after frontends were compromised. In an Aave and CoW collateral swap, a user signed a $50.4 million exchange of aEthUUSDT$0.9999▲0.01% for aEthAAVE and received tokens worth about $36,000, because of thin liquidity and gas-ceiling rejections. That is a loss of about 99.93%: ($50.4 million – $36,000) / $50.4 million × 100. Radiant Capital is the third case: malware substituted a malicious payload at signing time even though the wallet interface and simulation both showed the intended transaction.

EIP-7906 — “Transaction Assertions via State Diff Opcode” — is the candidate implementation. It builds on frame transactions defined in EIP-8141, which is already scheduled for the Hegotá upgrade. EIP-7906 itself has reached “Considered for Inclusion,” though the Ethereum Foundation is clear that confirmation in Hegotá hasn’t happened. Its inclusion timing remains an open question.

Three new opcodes: TXTRACE, TXDIFF, and EVENTDATACOPY. All three can only run inside a POST_TX frame — a static call executed at the very end of the transaction. State changes come through as net differences in native EETH$2,708.26▲0.26% balances and storage, plus newly deployed contracts and their code hashes.

In the desk’s assessment, that placement is what makes the model coherent. The assertion sees execution after the actions have run, checks the resulting state against the signed rule, and if the rule is violated, the entire execution body reverts. The transaction stays in the block with a failed status, and the gas payer gets charged for what was consumed.

A related change, EIP-8148, addresses queue control at the system-call level. The October 4 EIPs commit explains that a system call with non-empty calldata storesEXCESS_INHIBITOR in the excess slot and disables the queue; under the updated text, every system call uses empty calldata, so the restore path becomes unreachable. The specifics differ from EIP-7906, but both proposals share a preoccupation with what control paths are actually reachable given the conditions present at execution time.

The October 5 EIPs commit adds a harder constraint: assertion inputs must be controlled by the transaction. Reference values have to come from data fixed at signing time or from “before” values. Any assertion whose comparison target could shift mid-execution therefore can’t do the job it was designed for.

In the desk’s analysis, wallets get the cleaner story here — a signed condition capable of checking net balances, storage, deployments, and events after execution. Protocols, in the desk’s analysis, face a messier question: how does every frame transaction include the required assertion when already-deployed immutable contracts are in the path?

Whether any of this lands in Hegotá is still open. The user-facing cost when assertions reject outcomes — failed transactions, burned gas — will be the real test of how broadly wallets and protocols actually adopt it, assuming inclusion happens at all.