Ethereum Can Finally Check the Outcome. The Hard Part Is Who Writes the Rule.

On October 5, 2026, the Ethereum Foundation opened a post under its Trillion Dollar Security initiative with a sentence that reads like a confession from the network itself:

It is not a rhetorical question. It is a description of the largest category of loss on the network.

Two incidents the post uses make the point better than any argument could. In the Bybit case, the signers authorized something real: the replacement of the implementation contract behind a Safe. The transaction executed correctly. The attackers — linked to the North Korea-based Lazarus Group — took roughly $1.5 billion, about 400,000 ETH. The signers approved a genuine transaction that did something they never intended. Then there is the March 2026 Aave/CoW collateral swap. A user asked to swap about $50.4 million of aEthUSDT for aEthAAVE. AAVE liquidity was far too thin to absorb that size, CoW’s gas ceiling rejected the better-priced quotes, and the interface displayed a 99.9 percent price-impact warning that required the user to confirm the entire value could be lost. The user signed. They received tokens worth about $36,000.

One of these is a deception. The other is a transaction that did exactly what it was told, against a market that could not support it. Today’s security tooling handles the first far better than the second — and it handles neither by checking what actually happened onchain. EIP-7906, “native transaction assertions,” is the EF’s attempt to change that. The idea is genuinely good. Whether it protects anyone depends on a question the EIP itself cannot answer.

Two ways a signed transaction goes wrong

The post separates the failure modes, and the separation is the useful part.

It is not that one failure is technical and the other is human. It is that the signature commits to a request, not to an outcome. A signature covers a target, a value, and calldata. The EVM then executes that call against whatever code and state exist at the moment the transaction runs — which may be nothing like what existed when it was signed.

That single sentence explains most of what follows.

Where today’s defenses stop

There are three current defenses, and each one pays for its value with a specific blind spot.

Clear Signing, also from the Trillion Dollar Security initiative, tells the user what the calldata requests — before the transaction runs. It is a real improvement over blind signing. It also depends on accurate decoding, and on the signer actually noticing a mismatch.

Simulation predicts a transaction’s effects using a chosen chain state. But the chain state can change before inclusion, and the transaction that gets signed may not be the one that was simulated. In the Radiant Capital case, both the wallet interface and the simulation showed the intended transaction; malware on the signers’ machines substituted a malicious payload at signing time.

Contract checks and wallet guards enforce rules during execution. Uniswap reverts a swap if output falls below amountOutMinimum. Safe’s checkAfterExecution hook lets a guard inspect account state after execution and revert a transaction that violates its rules.

But all three share one limitation: they cannot ask the EVM what else changed. Every check must decide in advance which state to look at, and it reaches that state only through functions a contract chooses to expose. A token’s balanceOf makes balance checks easy. A proxy need not expose its implementation address through any function at all, so a guard cannot read the implementation slot directly. A guard can verify that one balance is unchanged. It cannot enumerate the full set of net state changes, so everything it was not designed to look for goes unnoticed.

Defense	When it acts	What it can see	Where it stops
Clear Signing	Before signing, at the interface	The request: target, value, calldata	Depends on correct decoding and the signer noticing
Simulation	Before inclusion, on a chosen state	Predicted effects on that state	State changes before inclusion; the signed tx may differ from the simulated one
Wallet and contract guards	During execution	Values the contract’s own functions expose	Must choose what to check in advance; cannot enumerate net changes
Native assertions (EIP-7906)	After the actions run, at the end of the transaction	The full set of net state changes and events	Only what the signed rule describes; must be included, and correctly sourced

How native transaction assertions work

The mechanism is clean, and it helps to state exactly what it does and does not touch.

• 1) EIP-7906 hard-depends on EIP-8141, the “frame transactions” proposal whose authors include Vitalik Buterin. EIP-8141 defines a new transaction type, 0x06, that splits a transaction into an ordered sequence of frames with modes including DEFAULT, VERIFY, and SENDER.
• 2) EIP-7906 appends a read-only POST_TX frame at the end of that sequence, to check the outcome. It runs as a STATICCALL, so it cannot modify state.
• 3) It adds three opcodes: TXTRACE, TXDIFF, and EVENTDATACOPY — to enumerate net state changes and events, to retrieve starting and final values for specific addresses and storage slots, and to copy an event’s data into memory. They work only inside a POST_TX frame.

The rule itself is included in the transaction and signed alongside the actions. It can require a minimum amount received, cap spending, block new approvals, preserve an account’s control logic, or permit only a specified set of changes. It may cover balances, storage and code, newly deployed contracts, and emitted events.

The rule is only as good as its source

Here is the crux, and it is where most coverage of EIP-7906 will stop short.

The rule’s source matters as much as the check itself. A compromised frontend can write an assertion that permits the attack. It can specify a permissive minimum, an empty allowed-change set, or a rule that simply ratifies whatever the malicious transaction does. The assertion then passes, the transaction finalizes, and the user is told they were protected. A useful rule has to come from independently approved user intent, a standing account policy, or protocol logic that the compromised component cannot alter.

The assertion also has to be required. EIP-7906 does not require a transaction to include one, so whoever builds the transaction can leave it out. That places the burden in two exact places:

• 1) For a user’s own transactions, the wallet must ensure every frame transaction it builds includes the required assertion.
• 2) For a protocol’s protected function, the contract must verify that the call comes from a frame transaction containing the exact required assertion, and reject ordinary transactions, or ones with a missing or incorrect assertion. An already-deployed immutable contract cannot add this check afterward.

Two more constraints follow from the same logic. Assertion target contracts must be immutable or non-upgradeable; if the assertion contract can be upgraded, a malicious transaction could upgrade it mid-execution and step around the check. And reference values must come from data fixed at signing time, or from “before” values the transaction cannot modify. Otherwise the transaction can steer the assertion toward accepting a harmful result — move the oracle price the assertion reads, and the rule agrees with the attack.

There is a genuine upside in the design: multiple POST_TX frames are allowed, so independent assertion providers can compose without coordinating with one another. The trust boundary is not the opcode. It is whoever writes the rule and whoever decides it must be present.

What it will not fix

The EF is unusually direct about the limits, and this honesty is worth repeating.

It would not stop attacks driven by stolen keys or social engineering. An adversary who holds the keys signs the assertion too. The post names its own examples: the Drift exploit, $285 million, after a six-month social-engineering operation that compromised contributors’ machines, and Bitget’s $387.5 million September loss from compromised hot-wallet keys.

In other words, the largest losses cluster exactly where a signed assertion offers no help.

The more insidious risk sits on the other side. An assertion that checks too little is worse than no assertion at all, because it manufactures a false sense of security. The ecosystem has to treat an incomplete assertion as no better than none.

Two practical limits remain. Enumerating TXTRACE results can exhaust gas; under current Ethereum configuration a transaction can produce up to about 42,600 events, and an assertion running out of gas must be treated as an assertion failure — not as a pass. And the security gains add new edge cases that have to be implemented and audited across multiple Ethereum clients, which is real cost paid by every team that ships one.

Timeline, trade-offs, and the open questions

Nothing here is live. EIP-7906 is a draft (Standards Track: Core), created 2025-02-21, with authors including Alex Forshtat, Shahaf Nacson, Dror Tirosh, Yoav Weiss, Fredrik Svantes, and Daniil Ankushin. EIP-8141 — the frame-transaction base — is also a draft, created 2026-01-29, with Vitalik Buterin among its authors, and is scheduled for the Hegotá upgrade. EIP-7906 has advanced to “Considered for Inclusion” for Hegotá, but is not confirmed. The target is not before 2027, though preliminary demonstrations have run on a development network, so the mechanics function outside a whitepaper.

Three design questions are still open:

• 1) What information the EVM exposes — state changes, events, or both.
• 2) How assertion code accesses it — enumerate entries, look up specific values, or copy the full change set into memory.
• 3) Where the opcodes may run — restricted to particular transaction types or execution phases, or anywhere in the EVM.

Beyond security, the same primitive supports other work: strengthening delegation, so that when you let an agent act for you, you constrain not just what it may do but what its actions must produce; solver execution, where the protocol specifies the required outcome and leaves the solver free to choose the route (within one transaction on one network, so it would not cover a cross-chain route); and workflow checks that assert a workflow returns unused tokens and revokes remaining approvals.

The EF is soliciting feedback from wallet and protocol teams at trilliondollarsecurity@ethereum.org, with discussion on the EIP-7906 thread at ethereum-magicians.org.

The check, the suggestion, and the hard part

Strip away the opcodes and the frame modes and the argument is simple.

A check the attacker can write is not a check. A check nobody is required to include is a suggestion. EIP-7906 gives Ethereum something it has never had: the ability to compare a transaction’s outcome against a rule signed with it, as a net diff over balances, storage, code, and events. That is a real and overdue capability, demonstrated on a devnet, aimed at Hegotá, and not before 2027.

But the mechanism is the easy part. It always is. The hard part is the trust boundary — deciding who writes the rule, which component is allowed to omit it, and how the user learns the difference between an assertion that protects them and one that merely agrees with what already happened. EIP-7906 answers “what changed.” It cannot answer “who decided that was acceptable.” That question stays ours.

(The End)