A Valid Signature Is Not a Promise: Three New Ethereum Opcodes Could Revert the Next $1.5 Billion Heist

The Ethereum Foundation published research on October 5 that starts from an uncomfortable fact: your signature commits to a request, not to an outcome. The EVM executes exactly what you authorize, against whatever code and state exist at the moment of inclusion. The proxy you inspected may have swapped its implementation since you signed, a sandwich may have moved the pool price underneath your swap, and the quote you approved may have been the only one that survived verification. The foundation's Trillion Dollar Security initiative now wants onchain code to be able to look at what a transaction actually did and revert it when the result does not match a rule that was signed along with the call. The write-up is here, and one possible implementation is EIP-7906.

Nothing in the proposal is live. It is research with an email address at the bottom, a draft proposal that has only reached the Considered for Inclusion stage, and a set of design questions that wallet teams and protocol teams are being asked to answer. That is precisely why it is worth reading now: the failure it describes is the failure that has drained the most money from this industry for four years, and the fix it suggests moves the check from a user interface into the EVM itself.

Two Ways a Valid Signature Goes Wrong

The foundation splits the losses into two categories, and the distinction matters because the defenses against them are different. The first is an intent mismatch: the signer approves something different from what they believe they are approving. In the Bybit incident and the BadgerDAO attack, a compromised frontend served a signing request that was not the transaction the user thought they were looking at. The second is an outcome mismatch: the signer approves exactly the request they were shown, and the request still produces a result that conflicts with their own goal.

Both categories share one property. There was no trusted rule over the resulting state, defined independently of whoever built the transaction and enforced during execution. There was only a signature, and a signature does not check anything.

The Bybit Signers Approved a Contract Swap, Not a Transfer

The cleanest example of intent mismatch is still the largest theft in the industry's history. On February 21, 2025, attackers linked to North Korea's Lazarus Group drained 401,347 ETH, roughly $1.5 billion at the time, from Bybit's cold wallet. The mechanics were not a private key break: malicious JavaScript injected into the Safe{Wallet} user interface changed what the signers saw, and the signers authorized a transaction that replaced the Safe's implementation contract instead of moving funds. NCC Group's technical teardown documents how narrowly targeted the payload was, and how normal the interface looked while it ran.

Under an assertion regime the rule for that account would have been simple and boring: the approved Safe implementation address must not change. The transaction would have executed, the POST_TX check would have read the net state diff, seen the implementation slot move, and reverted the whole thing. No signer education required, no malware detection required, no trust in the interface that was compromised.

$50.4 Million In, $36,000 Out

The outcome mismatch case is stranger, because everybody did what they were told. A user asked to swap about $50.4 million of aEthUSDT into aEthAAVE. AAVE liquidity was far too thin for a trade that size, and CoW's gas ceiling rejected the more complex quotes during verification, which left one verified quote worth roughly 329 aEthAAVE. The interface displayed a 99.9 percent price impact warning and required the user to confirm that the entire value could be lost. The user signed anyway and received tokens worth about $36,000.

An assertion would not have needed to argue with the warning. It would have carried a minimum acceptable output, calculated independently of the quote the interface showed, and the transaction would have reverted instead of filling. The foundation is explicit that this has to be enforced by the protocol or the signed order as well, not only by the wallet: in a solver-based flow, the settlement contract has to require the assertion, or the assertion is just decoration.

Why Clear Signing and Simulation Stop Short

Ethereum already has defenses, and the post is careful to explain where each of them runs out. Clear Signing explains what the calldata requests, but it depends on accurate decoding and on the signer noticing that the decoded action is not what they intended. Simulation predicts the effects of a transaction against a chosen chain state, and that state can change before inclusion, while the transaction that ends up signed can differ from the one that was simulated. In Radiant Capital's case, both the wallet interface and the simulation showed the intended transaction while malware on the signers' machines substituted a malicious payload at the moment of signing.

The stronger defenses are contract checks and wallet guards, and they are structurally limited. Uniswap reverts a swap when the output falls below amountOutMinimum. Safe's checkAfterExecution hook lets a guard inspect the account's state after execution and revert a transaction that violates its rules. Both approaches require whoever writes the guard to choose in advance which state to check. To read another contract's storage they depend on the functions it exposes: a token's balanceOf makes a balance check easy, but a proxy does not have to expose its implementation address through any function, and without that interface a guard cannot read the implementation slot directly. A guard can confirm that one particular balance did not move. It cannot ask the EVM what else changed.

Three New Opcodes and a Read-Only Frame

The proposal closes that gap by giving onchain code a view of the full set of net state changes. It builds on the frame transactions defined in EIP-8141, an ordered sequence of validation and action steps, and adds a read-only POST_TX frame at the end of the transaction. That frame runs as a static call, so the assertion can inspect the outcome without being able to change it. State changes arrive as net differences in ETH balances and storage, plus newly deployed contracts and their code hashes. A storage slot written five times shows up as one entry with its starting and final value, and a slot that ends the transaction with the value it started with does not show up at all.

Three new opcodes do the reading. TXTRACE enumerates the net state changes and the events, TXDIFF retrieves starting and final values for a specific address and storage slot, and EVENTDATACOPY copies an event's data into memory. All three only work inside a POST_TX frame. If the rule fails, the execution body reverts and the transaction still lands in the block with a failed status, with the gas payer charged for the gas consumed, a design choice that exists so an attacker cannot make builders run deliberately failing transactions for free. The assertion code can require a minimum amount received, cap spending, block new approvals, preserve an account's control logic, or allow only a specified set of changes.

All three cases lacked a trusted rule over the resulting state, defined independently of the transaction builder and enforced during execution.

The Rule Is Only as Good as Who Writes It

The foundation's own caveat is the part to keep. A compromised frontend can write an assertion that permits the attack, which means the value of the mechanism depends entirely on where the rule comes from: independently approved user intent, a standing account policy, or protocol logic that the compromised component cannot change. EIP-7906 also does not require a transaction to include an assertion at all, so whoever builds the transaction can leave it out. For a user's own transactions the wallet has to ensure every frame transaction it builds carries the required assertion, and a protected protocol function has to verify that the call comes from a frame transaction containing the exact required assertion, rejecting ordinary transactions and frame transactions with a missing or wrong one. That is a compatibility tax on callers and integrations, and an immutable contract already deployed cannot add the check.

Status, plainly: EIP-8141 is scheduled for the Hegotá upgrade, while EIP-7906 is tracked as Considered for Inclusion and not yet confirmed for it. The broader program is Trillion Dollar Security, and the foundation is asking wallet and protocol teams to join the discussion thread to shape the design.

The most interesting secondary use case is not human at all. If you delegate execution to an agent, assertions let you constrain both what the agent may do and what its actions produce: which contracts it may touch, how much it can spend, how long its permissions last, and what each transaction is required to end with. A protocol could impose its own rule on every caller using a frame transaction, and in solver execution the protocol could specify the required outcome while leaving the solver free to choose the route. The honest limit is scope: the guarantee covers one transaction on one network, so a route that hops across chains is outside it.

So the pitch is not that wallets will suddenly be safe. It is that the last line of defense stops being a warning dialog that a tired signer clicks through at 2 a.m., and becomes a rule the EVM checks after the fact. That only works if wallets and protocols opt in, and the interesting number here is not the three opcodes. It is how many of them will. For context, BTC is trading near $85,876, down about 1.0 percent over 24 hours, and ETH is near $2,714, both well under their cycle highs, so there is no shortage of users who have already learned what a mismatched signature costs.