Ethereum proposes native transaction assertions to tackle blind signing

Ethereum wants your transactions to come with a built-in fact-checker. A new proposal would let on-chain code verify what a transaction actually changed and reverse the whole thing if the outcome breaks the rules a user set in advance.

The idea, called native transaction assertions, was highlighted by the Ethereum Foundation in a blog post on October 5, 2026. It targets one of the oldest and most stubborn weak spots in crypto: blind signing.

What the proposal actually does

Blind signing is the crypto version of agreeing to terms and conditions you never read. A wallet pops up a request, the details are unreadable or unclear, and the user clicks approve anyway. Most of the time, nothing bad happens. When something does, it tends to be expensive.

The Ethereum Foundation framed the new work as a direct response to those risks, which were flagged under its Trillion Dollar Security initiative. That program already includes measures like Clear Signing, which focuses on making transaction requests legible before a user approves them.

Native transaction assertions work at a different moment in the process. Clear Signing tries to help you understand a transaction before it runs. Assertions check whether the result matched expectations after it runs.

The technical core is EIP-7906. It introduces three new opcodes to the Ethereum Virtual Machine: TXTRACE, TXDIFF, and EVENTDATACOPY. Opcodes are the low-level instructions the EVM understands, so adding new ones expands what smart contract code can see and do.

In this case, the new instructions give on-chain code a way to inspect the real state changes a transaction produced. That shifts verification from what a transaction claims it will do to what it demonstrably did.

How it plugs into EIP-8141

EIP-7906 does not stand alone. It relies on the framework laid out in EIP-8141, known as the frame transaction format.

Frame transactions break a single transaction into distinct segments, or frames. EIP-7906 adds a new one to that structure: a POST_TX frame.

The POST_TX frame operates as a static call during execution. A static call is a read-only operation, meaning it can examine state but cannot modify it. If the conditions defined in that frame are not met, the transaction’s effects can be reverted.

Where it stands, and when it could ship

Nothing here is live yet. EIP-7906 remains in draft status.

The goal is to include it in the Hegotá upgrade, which is anticipated for deployment in 2027. Preliminary demonstrations have already been run on a development network, which suggests the mechanics function outside of a whitepaper.

EIP-7906 also depends on EIP-8141, so its fate is tied to whether the frame transaction format makes the cut too.

Why this matters beyond the code

Native assertions move part of the burden of signing risk into the base layer. If the protocol can enforce outcome checks directly, users are less dependent on any single wallet getting its display logic perfect.

For institutions and businesses, the appeal is easy to see. Organizations moving large sums tend to want guarantees, not best efforts. A mechanism that can automatically reverse a transaction whose results fall outside defined parameters fits neatly into the kind of risk controls those players already use elsewhere.

Developers will also need to figure out how ordinary users define the rules their transactions must satisfy, since a safety net that requires expert configuration may end up protecting mostly experts. The usability layer built on top of EIP-7906 could matter as much as the opcodes themselves.

Every new opcode expands the surface area that must be implemented and audited across multiple Ethereum clients. Security improvements that introduce new edge cases have to justify that trade.

Watch whether EIP-7906 moves out of draft, whether EIP-8141 secures a place in Hegotá, and whether more devnet testing follows the early demonstrations.