What EIP-7906 Would Change About Ethereum Transactions

“The total value of crypto assets that have been stolen to date exceeds the yearly GDP of a medium-sized nation.”

So reads the start of the Motivation section in the EIP-7906 draft proposal, which was created in early 2025, meaning that “GDP” has swelled from various exploits since then.

Of course, the problem of onchain theft isn’t unique to the Ethereum ecosystem, but Ethereum does undoubtedly have a major thorn here, namely “de facto blind signing” of everything, as EIP-7906’s authors put it, since today there’s no way to easily vet and restrict what transactions will do once signed.

In other words, there’s no network-level handle on outcomes, only on signed calldata. This means something like a wallet or a tx simulation UI can display wrong data, or miss hostile intentions, and Ethereum will still commit whatever was executed because a provided signature authorizes execution, and not a checked outcome.

This gap between intention and execution is exactly what EIP-7906, a.k.a. transaction assertions, is meant to solve. This standard’s introduction will be pivotal, to the point that its arrival will mark a sort of “before” and “after” milestone in Ethereum UX.

It seems we won’t have to wait very long, either. EIP-7906 is proposed for inclusion (PFI) in Ethereum’s Hegotá upgrade and has already been demoed in a Hegotá devnet next to frames. The EIP isn’t officially considered/scheduled for inclusion yet, and it may get pushed to Ethereum’s following upgrade, but it’s possible we’ll see it live in 2027 at the earliest.

That’s all the general background here, but to understand how transaction assertions actually work, you have to know the basics of “frame transactions” per EIP-8141, which is already formally slated for Hegotá and which EIP-7906 is fundamentally built around.

As you can imagine from the name, frame transactions break transactions into frames, i.e. short, labeled steps with different jobs. One frame can validate a signature, another can let a sponsor pay your gas, with others you can make approvals, swaps, batches, etc.

EIP-8141: Frame Transaction

Add frame abstraction for transaction validation, execution, and gas payment

However, in its default structure, EIP-8141 doesn’t have a baked-in outcomes check to make sure your list of frames only do what your wallet screen has indicated. Here then cue in transaction assertions, as EIP-7906, if pushed to mainnet, would add a frame mode for precisely this type of checking job.

The EIP’s new proposed frame mode is specifically POST_TX, which would have to sit at the very end of your frames list. It’d run as a static call, so it could read but not write anything, and its three new opcodes, TXTRACE, TXDIFF, and EVENTDATACOPY, would only work inside it.

The neat thing is that by the time POST_TX runs, your real balance, storage, and event diff changes would already exist, and then your smart account would get a look at that data. If the results don’t match with what’s expected, the execution frames will revert. Accordingly, EIP-7906 can provide vetoes on onchain outcomes rather than mere (and potentially flawed) previews of them.

Under this paradigm, you’d be able to guarantee a swap will fire off as expected or dodge an approval drainer after trying to ape into an NFT mint that was discreetly nefarious, and so on. Everything that opcodes expose could get checked against your transactions’ literal traces instead of simulations or calldata summaries that hostile frontends can fake.

To be sure, transaction assertions aren’t a panacea for all of the Ethereum ecosystem’s security problems, but it’s safe to say that they can prevent plenty future onchain losses. We don’t have to sign transactions and just hope for the best. We can authorize execution and then refuse to keep the results if something’s gone wrong.

That’s a powerful shift that will prove to be a big level up for Ethereum UX. For now, the main question that remains is the timeline. In one week, Ethereum client teams will submit their ranking preferences for further Hegotá inclusions, so we’ll know more then on the community’s appetite for transaction assertions coming sooner or later, like the upgrade after Hegotá.