# What EIP-7906 Would Change About Ethereum Transactions

*Author: William M. Peaster*
*Published: Sep 2, 2026*
*Source: https://www.bankless.com/read/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](https://eips.ethereum.org/EIPS/eip-7906), 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. 

> Transactions assertions will be one of those features that we look back on and wonder how we used Ethereum without them. [https://t.co/cUtPzeBCIq](https://t.co/cUtPzeBCIq)— ً (@lightclients) [September 1, 2026](https://x.com/lightclients/status/2094872313107988490?ref_src=twsrc%5Etfw)

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](https://eips.ethereum.org/EIPS/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 TransactionAdd frame abstraction for transaction validation, execution, and gas payment![](https://storage.ghost.io/c/e4/b7/e4b77544-5a37-4f0b-8824-8440aa348476/content/images/icon/favicon-708dcea6-4f64-4f93-b56d-202897237e44.png)Ethereum Improvement ProposalsEthereum Improvement Proposals![](https://storage.ghost.io/c/e4/b7/e4b77544-5a37-4f0b-8824-8440aa348476/content/images/thumbnail/eip-og-image-bae75109-ecee-4e96-9812-ff61eb40c0a2.png)](https://eips.ethereum.org/EIPS/eip-8141)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á.