Ethereum’s Vitalik Buterin Urges Pre-Signing Transaction Simulations to Reduce Exploits and Improve Onchain Security

Vitalik Buterin has lobbed a simple idea back into Ethereum$1,686.33's security conversation: don't just show users a scary wall of hex before they sign, show them what will actually happen. The catalyst was a fresh X post arguing that wallet UX and security are basically the same problem, both are about matching onchain outcomes to user intent. ^[1]

Vitalik Buterin Moves 3,500 ETH From Aave, Sells $7M as Ethereum Plunges 30% Below $2,000

At the time of writing, Ethereum$1,686.33 was trading around $1,878 (per Cointelegraph's price widget), up on the day, but Buterin's focus was not price action. It was the boring, expensive stuff: approvals, signatures, and users clicking "confirm" on transactions they do not properly understand.

Enjoy articles without ads?

"Security" is just "did the chain do what the user meant?"

Buterin's framing is straightforward and hard to disagree with: wallets and protocols should be judged by whether they execute the action the user intended. If the UI says "claim an airdrop" but the signature actually grants a malicious contract permission to drain tokens, that is not a niche UX issue, it is a security failure.

His proposed fix leans on transaction simulations. The wallet experience he sketches is closer to an "intent" prompt: ^[2]

user specifies the action they want to take (swap, mint, bridge, claim),
the wallet runs a pre-execution simulation of the exact call data,
the user sees a clear outcome preview,
the user then clicks "OK" or "Cancel".

This is a subtle shift. Today's default flow often pushes users into signing opaque messages, especially when dapps get creative with custom calldata, proxy contracts, and signature schemes that look legitimate to the UI layer but are lethal to a hot wallet.

BlackRock's Ethereum Staking ETF Would Pass 82% of Staking Rewards to Investors, With Coinbase Taking 18%

What a proper pre-sign simulation should show (not vibes)

If you want simulations to actually reduce exploits, they need to be opinionated about what matters. Not a "gas estimate" and a shrug, but a concrete before-and-after of wallet state.

At minimum, a wallet-grade simulation should surface:

Net token deltas: what leaves the wallet, what comes back, and to which addresses.
Approvals and permissions: ERC-20 allowance changes, ERC-721 and ERC-1155 operator approvals, permit signatures, and any "setApprovalForAll" calls.
Ethereum$1,686.33 and wrapped Ethereum flows: raw Ethereum transfers often get missed in UI summaries, and they are the quickest way to get rinsed.
Contract creation or delegatecalls: anything that changes execution context or deploys fresh bytecode deserves a red flag.
Downstream calls: if a user thinks they are interacting with a router but the transaction fans out into unknown contracts, the simulation should make that obvious.

A decent simulation summary is basically an explainer of state transitions. That is the only language the chain speaks.

Why this matters right now: drainers, approvals, and signature trickery

Most retail losses on Ethereum are not from exotic cryptography breaks. They are from users signing the wrong thing. The usual suspects:

Approval phishing: users grant unlimited allowances to a malicious spender, then the actual drain happens later. The initial transaction can look harmless because nothing "moves" immediately.
Malicious "claim" contracts: airdrop lures that ask for broad approvals or invoke transfer hooks.
Blind signing: users sign messages that are not human-readable, sometimes not even a transaction, then the attacker uses that signature elsewhere.

This is where Buterin's "user intent" lens lands. People do not wake up wanting to approve a random contract for infinite USDC$1.0005. They want to do a specific action and keep custody. If the wallet cannot explain that the action results in a permanent permission change, the wallet is part of the failure chain.

Wallets already simulate, but the current approach is patchy

To be clear, simulation is not new. Power users already rely on tooling that previews transactions, and some wallets provide warnings. The issue is consistency and trust.

Today's landscape looks like this:

Many wallets show a basic decoded view (method name, parameters) that still requires expert interpretation.
Some wallets and extensions integrate simulation providers, but coverage varies by chain, by contract pattern, and by RPC quality.
"Warnings" are often heuristic: they catch obvious scams, but attackers adapt quickly.

Buterin's push reads like a call to make simulation a default primitive, not an optional add-on for paranoid users. If the safest wallet experience is only available to people who install five browser extensions and cross-check on a block explorer, the average user is still going to get clipped.

IoTeX Confirms Token Safe Security Incident After Suspected Private Key Compromise, Says Losses Are Contained

The hard parts: simulations can lie, and attackers will try to make them lie

A simulation is only as good as the environment it runs in. That is where the degen in me starts getting sceptical.

Key failure modes include:

1) Untrusted RPCs and manipulated results

If a wallet relies on an RPC endpoint that is compromised or incentivised to mislead, the "preview" can be faked. This is not theoretical. Anything offchain is a potential point of corruption. ^[3]

Mitigation: multi-RPC verification, signed simulation results, reputation systems for RPC providers, and local verification where feasible.

2) State changes between simulation and execution

MEV, reordering, and changing pool reserves can all cause the real execution to diverge from the preview. A simulation might show a swap output that looks fine, then execution hits a different price and routes through a different path.

Mitigation: explicit slippage bounds, clearer "worst-case" outcome displays, and warnings when the result is highly state-dependent.

3) Proxy patterns and dynamic logic

Upgradeable proxies, metamorphic contracts, and contracts that change behaviour based on block variables can produce simulations that look safe but execute differently under real conditions.

Mitigation: surface proxy relationships, highlight dynamic code paths, and treat "unknown delegatecall targets" as high risk by default.

4) The "approval trap"

Some scams do not drain in the same transaction. They set the hook for later. If the simulation UI only emphasises immediate token movement, users still get rugged (rug, meaning a sudden, often malicious wipeout of value or funds).

Mitigation: treat permission changes as first-class outcomes, with severity scoring and clear language.

What to watch: the path from idea to ecosystem standard

For this to become real, it needs adoption across wallets, not just another blog-post cycle on CT (Crypto Twitter). The likely routes:

Wallet UX upgrades: more structured confirmation screens, intent-based flows, and "permission dashboards" that persist beyond a single transaction.
Account abstraction (ERC-4337) style flows: bundlers and smart accounts can make it easier to simulate the exact user operation, including paymasters and batched calls, then present a single "this is what happens" view.
Common simulation schemas: if every wallet invents its own outcome format, the ecosystem stays fragmented. A standard for representing deltas, approvals, and risk flags would help.

The punchline is not "simulation fixes everything." It is that simulation, done properly, forces the ecosystem to stop normalising blind signing as acceptable UX. ^[4]

Risk box: what would invalidate the security win?

Simulations only reduce exploits if users can trust the preview and understand it. Watch out for:

simulation providers becoming a centralised chokepoint,
wallets displaying "green" previews without highlighting approvals and operator permissions,
attackers shifting to scams that look benign under simplistic delta views,
poor RPC hygiene that allows manipulated previews.

If the preview cannot reliably answer "what changes in my wallet after I sign," then the feature becomes security theatre. The chain will still do what the calldata says, not what the UI implies.