Wallets Should Sign Outcomes, Not Just Instructions

Opinion — October 9, 2026. A crypto wallet can prove that you approved a transaction without proving that the transaction produced the result you intended. That gap is more than a user-interface problem. It is a weakness in what the network actually enforces.

My view is that the next important wallet standard should let users sign outcomes, not just instructions. Clearer transaction screens still matter, but a decoded request and a predicted simulation are not the same as an enforceable limit on the final state. If a wallet promises a safer experience, the protection should survive the moment between signing and execution.

A valid signature can still authorize a bad result

On October 5, the Ethereum Foundation’s Access Cluster published an R&D proposal on native transaction assertions. Its central distinction is useful: an intent mismatch occurs when the user signs something different from what they thought they were approving, while an outcome mismatch occurs when the signed request is accurate but produces an unacceptable result against the code and state present at execution.

Ethereum executes the authorized call without deciding whether its balance changes, approvals or contract configuration match the signer’s economic goal. Code can be upgraded and transaction ordering can change market state. A signature authenticates the request; it does not certify the result.

Clear signing helps by translating calldata into something a person can understand. Simulation helps by estimating effects against a selected chain state. Both are valuable. But the Foundation notes that state may change before inclusion, and the transaction that reaches the signer can differ from what was simulated. These tools inform a decision before execution; they do not necessarily constrain what may be true afterward.

Turn expectations into executable limits

A transaction assertion would add a rule that runs after the transaction’s actions but before their effects become final. The rule could require a minimum amount received, cap spending, prevent an unexpected token approval, preserve a wallet’s control logic or permit only a defined set of state changes. If the rule fails, the actions revert.

That changes the safety model. Instead of asking a user to trust a preview, the wallet can attach a machine-enforced condition to the same signed package. The important product question becomes: what outcome will this wallet refuse to accept?

For ordinary users, the answer should not be a screen full of storage slots. Wallets could translate common goals into narrow policies:

• Swaps: receive at least a stated amount and create no unrelated approvals.
• Account changes: preserve the approved implementation and signer set.
• Delegated activity: constrain the contracts, assets, value and expiry available to an agent.
• Multi-step workflows: return unused assets and revoke temporary permissions before completion.

These are design examples, not claims that EIP-7906 already protects live wallets. The proposal is still a draft.

The policy must not come from the compromised component

The most important detail is easy to miss: a weak assertion can approve a harmful outcome. If the same compromised interface builds both the transaction and its safety rule, the rule may merely bless the attack.

Useful assertions therefore need an independent source of policy. That could be a standing wallet rule, an account-level limit, a separately approved template or protocol logic that rejects transactions without the exact required assertion. The assertion is not a magic shield. It is an enforcement mechanism whose value depends on who defines the boundary.

This is also why outcome enforcement belongs in the infrastructure layer. I have previously argued that wallets will become less visible to users. Less visible cannot mean less accountable. As interfaces abstract keys, networks and transaction construction, they should make the user’s intended result more explicit inside the transaction—not leave it as a hopeful interpretation of the interface.

What EIP-7906 would actually add

EIP-7906 proposes three EVM instructions—TXTRACE, TXDIFF and EVENTDATACOPY—plus a read-only POST_TX frame. Together, they would let assertion code inspect net balance, storage and code changes, newly deployed contracts and emitted events. If a check fails, the execution body reverts, while the transaction remains included and the gas payer still pays for work performed.

Failed assertions are not free simulations: users can still pay gas when a safety condition blocks the outcome.

The proposal also depends on EIP-8141 frame transactions. The Foundation says EIP-7906 has advanced to “Considered for Inclusion” for Hegotá but is not confirmed. It would not force every transaction to carry an assertion. Existing immutable contracts could not simply be retrofitted to require one, and a rule covering one transaction on one network would not protect a route spanning multiple chains.

What builders should do before protocol support exists

Teams should not wait for a core-protocol decision. Wallet and dApp builders can inventory which outcomes they claim to protect, separate transaction decoding from independent simulation, and document where a last-minute state change can invalidate a preview.

Teams can also design a small set of user-readable guarantees that could later compile into native assertions, then test them against adversarial state changes. A “safe swap” should have a precise failure condition, not just a warning colour.

Limits and what would change my view

Native assertions add complexity, gas cost and new failure modes. Overly broad rules create false confidence; overly strict rules can make valid transactions fail. Enumerating state changes may also create integration and performance costs that only real implementations can reveal.

I would change my assessment if wallet trials showed that equivalent protection can be delivered more reliably through independent simulation, contract-level checks and account policies without protocol changes. I would also be less enthusiastic if assertion templates become another opaque permission layer users cannot verify, or if the cost and compatibility burden excludes ordinary transactions. The case becomes stronger with interoperable templates, adversarial testing and evidence that wallets can present meaningful guarantees without exposing protocol complexity.

A signature should remain proof of authorization. It should not be mistaken for proof of satisfaction. Crypto UX will improve when wallets can enforce the difference.

Disclosure: Jason Ansell is a co-founder of Vector Smart Chain and writes books about blockchain and cryptocurrency. Those interests inform the subject area. This opinion is not a claim of participation in Ethereum’s proposal process, not a report of firsthand wallet testing, and not investment advice.

Sources

• Ethereum Foundation Access Cluster: How native transaction assertions could enforce a transaction’s final outcome (October 5, 2026)
• EIP-7906: Transaction Assertions via State Diff Opcode (draft; accessed October 9, 2026)