Ethereum Foundation Explores Fix for Blind Signing Risks

Published October 6, 2026, 04:52 UTC

The Ethereum Foundation on Monday, October 5, published a post arguing for "native transaction assertions," rules attached to a transaction that would undo its effects if the final result breaks them. The post, from the foundation's Trillion Dollar Security initiative, names EIP-7906 as one possible way to build this. The proposal is a draft and is not live on Ethereum.

The problem it targets

Ethereum "executes exactly what you authorize, without judging whether the result is what you wanted," the post says. It describes two ways that goes wrong.

In the first, users sign something different from what they believe they are approving. The post cites the Bybit and BadgerDAO attacks, where a compromised website or app supplied the signing request. In the second, users sign what they meant to, but the result still goes badly. The post's example is a collateral swap through Aave and CoW, in which a user swapped about $50.4 million of aEthUSDT for aEthAAVE despite a 99.9% price impact warning and received tokens worth about $36,000.

Existing defenses help but have limits, the post says. Clear signing explains what a request asks for, and simulation predicts its effects, but chain state can change before a transaction runs. Contract checks only test what they were designed to test.

How EIP-7906 would work

EIP-7906, titled "Transaction Assertions via State Diff Opcode," adds three new instructions to the Ethereum Virtual Machine (EVM): TXTRACE, TXDIFF and EVENTDATACOPY. Together they let code see a transaction's net changes to balances, storage and contract code, plus the events it emitted.

Those instructions would only work inside a new read-only step, called a POST_TX frame, that runs at the end of a transaction. If the assertion fails, everything the transaction did is rolled back. The transaction still appears in the block with a failed status, and the gas is still paid, which the post says stops attackers from forcing builders to process failing transactions for free.

An assertion could, for example, require a minimum amount received, cap spending, block new token approvals or make sure a wallet's control settings stay the same.

What is not settled

EIP-7906 is marked Draft. It depends on EIP-8141, which defines "frame transactions," and which the post says is scheduled for the Hegotá upgrade. EIP-7906 itself has advanced to "Considered for Inclusion" for Hegotá but "is not yet confirmed for the upgrade," the foundation wrote.

The proposal also does not force anyone to use assertions, so a wallet or protocol would have to require them. The post warns that "a compromised frontend can write an assertion that permits the attack," so a useful rule has to come from somewhere the attacker cannot change, such as a standing wallet policy or protocol code.

Why it matters

Signing mistakes and tampered signing requests are behind some of the largest crypto losses. Sunday's Base vault drain, where security firm ExVul said the vault's multisig re-enabled the attacker's contract with valid signatures shortly before the theft, is a recent reminder that a valid signature does not guarantee a safe outcome. The foundation is asking wallet and protocol teams for feedback, so the design may still change.

This article is news reporting and is not investment advice.

Sources

• Ethereum Foundation Blog, How native transaction assertions could enforce a transaction's final outcome (Oct. 5, 2026), primary source
• Ethereum Improvement Proposals, EIP-7906: Transaction Assertions via State Diff Opcode, accessed Oct. 6, 2026, primary source