Key Highlights
- The Ethereum Foundation is exploring native transaction assertions as part of its Trillion Dollar Security initiative.
- The proposed system could allow onchain code to check a transaction’s final state and revert the transaction if predefined rules are violated.
- EIP-7906 is one possible approach, adding a post-transaction frame and three new opcodes to inspect state changes and events.
The Ethereum Foundation is exploring native transaction assertions as a way to add another layer of checks to Ethereum transactions.
According to an announcement published on October 5, the Trillion Dollar Security initiative said the research focuses on risks around blind signing and transaction uncertainty, alongside existing measures such as Clear Signing.
The approach is intended to add a rule that can be checked after a transaction executes, rather than relying only on what was signed or simulated beforehand.
Signatures do not guarantee the intended outcome
The Foundation said a valid signature does not necessarily mean a transaction will produce the result the user expected.
Ethereum executes the action authorized by a signature based on the contract code and blockchain state present when the transaction runs. Those conditions can change between signing and execution.
The Foundation described two types of problems: intent mismatch and outcome mismatch.
An intent mismatch occurs when a user signs a transaction that is different from what they believed they were authorizing. The Foundation cited the Bybit incident and BadgerDAO attack as examples.
In the Bybit case, signers authorized a change to the Safe implementation contract after a compromised frontend supplied a different signing request. In the BadgerDAO attack, users granted token-spending permissions to an attacker.
An outcome mismatch occurs when the user signs the transaction they were shown, but the transaction still produces a result that conflicts with their economic objective or an existing safety rule.
The Foundation cited an Aave and CoW collateral swap in which a user attempted to swap about $50.4 million of aEthUSDT for aEthAAVE. Due to limited AAVE liquidity and other execution constraints, the user received tokens worth roughly $36,000 after signing the transaction.
The interface displayed a 99.9% price-impact warning and required the user to confirm that the entire value could be lost.
Existing protections have limits
Ethereum already has several mechanisms designed to reduce transaction risks.
Clear Signing shows users what a transaction’s calldata is requesting, but it depends on accurate decoding and the user recognizing whether the request matches their intent.
Transaction simulation can estimate the effects of a transaction before execution. However, the Foundation said the blockchain state can change before inclusion, and the transaction that is ultimately signed may differ from the one that was simulated.
The Foundation cited Radiant Capital as an example in which wallet interfaces and simulations showed the intended transaction while malware on signers’ machines substituted a malicious payload at signing.
Smart contract checks and wallet guards can enforce specific rules during execution. For example, Uniswap can revert a swap when the output falls below amountOutMinimum, while Safe’s checkAfterExecution hook allows a guard to inspect an account’s state after execution.
However, these mechanisms generally need to know in advance which state or value they should check.
The Foundation said existing checks cannot inspect the full set of net state changes and events produced by a transaction.
Native assertions could check the final state
Under the proposed system, an assertion would use read-only logic to compare a transaction’s starting and final values against a predefined rule.
The rule could cover changes to balances, storage and contract code, as well as newly deployed contracts and emitted events.
For example, an assertion could require a minimum amount of tokens to be received, place a spending limit, prevent new token approvals, preserve an account’s control logic or permit only a defined set of changes.
The Foundation said the source of the rule would be important. A compromised frontend could itself create a malicious assertion, so useful rules would need to come from independently approved user intent, an account policy or protocol logic that the compromised component cannot modify.
EIP-7906 offers one possible design
One possible implementation discussed by the Foundation is EIP-7906, which builds on frame transactions proposed in EIP-8141.
Under the design, a frame transaction contains validation and action steps, followed by a read-only POST_TX frame that checks the transaction’s outcome.
EIP-7906 would expose both state changes and events. State changes would be represented as net differences in native ETH balances and storage, along with newly deployed contracts and their code hashes.
For example, if a storage slot is written multiple times during a transaction, the system would report its starting and final values rather than every intermediate change. If the slot ends with its original value, it would not appear as a net change.
The proposal introduces three opcodes:
- TXTRACE to enumerate net state changes and events.
- TXDIFF to retrieve starting and final values for specific addresses and storage slots.
- EVENTDATACOPY to copy event data into memory.
The POST_TX frame runs after the transaction’s action steps and can inspect the resulting state without modifying it.
If an assertion fails, the transaction’s execution body would revert. The transaction would remain in the block with a failed status, and the gas payer would be charged for the gas consumed.
Assertions would need to be enforced
The Foundation noted that EIP-7906 itself would not require every transaction to contain an assertion.
For user transactions, wallets could ensure that the frame transactions they create include the required assertion. The rule could come from a wallet simulation or a standing policy applied to the user’s transactions.
Protocols could take a stricter approach by requiring calls to protected functions to come from frame transactions containing a specific assertion.
Such protocols would need to reject ordinary transactions and frame transactions containing missing or incorrect assertions. The Foundation noted that existing immutable contracts would not be able to add this requirement after deployment.
Potential uses beyond transaction security
The Foundation also described possible uses for transaction assertions in agent-based transactions.
For example, an agent could be limited by the contracts it can interact with, the amount it can spend and the duration of its permissions. The Foundation said assertions could be used to check the outcome of each transaction.
Protocols could similarly define required outcomes while allowing solvers or other participants to choose how to execute the transaction.
These protections would apply to the outcome of a transaction on a single network and would not automatically cover workflows spanning multiple chains.
Assertions could also be used to verify that a workflow reaches a specified final state, such as returning unused tokens to the user or revoking remaining token approvals.
Ethereum Foundation’s earlier security initiatives
In August, the Foundation moved away from Poseidon in its Layer 1 approach to post-quantum cryptography, instead considering conventional hash functions such as SHA and BLAKE. The change followed advances in binary-field SNARKs that made conventional hash functions cheaper to prove.
Earlier in April, the Foundation launched a $1 million audit subsidy program for developers, with more than 20 audit firms participating.
Native transaction assertions remain under development as part of the Trillion Dollar Security initiative.
EIP-7906 is currently at the “Considered for Inclusion” stage and has not been confirmed for an Ethereum network upgrade. EIP-8141 is scheduled for inclusion in Hegotá.
The Foundation is seeking feedback from wallet and protocol teams on the proposed design and its potential applications.
Also Read: Polymarket Introduces Protocol V2 With New Market Infrastructure
