Transaction assertions, a safeguard that reverts based on the outcome

Strawmap Hegotá (2027) · transaction assertions

A read-only check step is attached at the very end of a transaction, and if balances or storage changed in a way that differs from the conditions, the whole execution result is reverted. This lets wallets enforce on-chain the range of things that can happen to a user's account.

Why it is needed

Today, once a transaction is signed, there is no way to restrict what that transaction actually does. It is also very hard for ordinary users or wallet apps to find, read and analyze all the code that will run. So most people sign without knowing the contents (blind signing). The proposal points out that the cumulative amount of crypto assets stolen this way exceeds the annual GDP of a mid-sized country. Instead of reading the code in advance, this proposal chooses to block based on the outcome. It places a read-only check step at the very end of the transaction and uses a new opcode (TXTRACE) to read the balances, storage, code and nonces the transaction changed and the events it emitted. If a wallet attaches conditions, the execution body is reverted entirely when they are violated, so users can set for themselves the range of things that can happen to their account. This item is designed as the fourth mode of the frame transaction (EIP-8141) and must go together with the frame transaction. At ACDE #246 in September 2026 it was put up for Considered for Inclusion (CFI) in Hegotá, and at ACDT #100 in October it was decided to include it in bogota-devnet-1 for validation. The Strawmap places it in the Hegotá column, but which fork it will enter is only a projection and not a commitment.

How it works

  1. Attach the check step at the end A wallet or dapp places an ASSERT-mode frame at the end of a frame transaction. This frame runs read-only, unable to change state, and once one appears, every frame after it must also be ASSERT.
  2. Read what changed After the body finishes executing, the TXTRACE opcode reads the difference between before the transaction and now. It looks up, item by item, where and how balances, storage slots, code and nonces changed, as well as the events that were emitted.
  3. Revert if the conditions are violated If the check fails, the entire execution body is reverted and the logs are discarded. The transaction remains in the block, and the fee payer pays for the gas used up to the point of failure.

Related EIPs

← Roadmap