Vitalik Buterin outlined a proposal for client-side transaction simulations that would show a verifiable preview of state changes before a user signs. The goal is to align user intent with on-chain execution and reduce blind-signing, phishing, and front-end compromise losses that are hard to reverse once confirmed.
The idea frames simulation as a final, human-readable validation step inside wallets and dApps, and as a building block for an “intent-based layer” that converts desired outcomes into safe execution plans. In practice, it aims to make “what you think you’re signing” match “what will actually happen” before any gas is spent.
How I think about "security":
The goal is to minimize the divergence between the user's intent, and the actual behavior of the system.
"User experience" can also be defined in this way. Thus, "user experience" and "security" are thus not separate fields. However, "security"…
— vitalik.eth (@VitalikButerin) February 22, 2026
How the simulation would work
Buterin described a client-side rehearsal that executes the transaction against a simulated state and produces a compact, verifiable “receipt” of resulting state changes, token movements, and contract calls. The simulation would be displayed prior to signing so mismatches between intended and actual effects become visible and actionable.
Architecturally, the heavy work stays off-chain: wallets or relayers run the execution in a sandbox and then present deterministic outputs that map back to on-chain operations. The output is meant to be machine-readable for automated checks and human-readable for final approval while preserving EVM equivalence.
Security and UX impact areas
A key security benefit is making approvals and transfers explicit at signing time, which helps prevent hidden unlimited token allowances and other stealth actions. This directly targets blind-signing risk by showing the exact approvals and transfers the transaction would perform.
The same flow is positioned to expose compromised front ends, because altered recipient addresses or parameters would show up as a divergence in the simulation preview. If a UI is tampered with, the mismatch can be caught before execution rather than discovered after funds move.
Simulations are also framed as a way to blunt phishing, since they would surface interacting contract addresses and outputs and highlight suspicious or unfamiliar elements at approval time. The aim is to turn subtle red flags into explicit pre-sign prompts instead of post-loss forensic clues.
For complex DeFi interactions, the preview would surface resulting position changes and collateral impacts across multi-step operations like lending or liquidity provision. That reduces inadvertent losses and avoids failed or unintended operations that currently cost users gas and time.
A secondary benefit is cost control and developer determinism, since catching errors pre-execution prevents wasted gas from failed calls and can provide a checkpoint for batching strategies in Layer-2 rollups. This makes the simulation a UX feature and a systems tool at the same time.
Adoption constraints and timeline
The proposal was presented as part of a broader intent-based framework where users specify outcomes and the system composes the transactions, with simulation acting as the translation-and-verification gate. The key design principle is abstraction without losing transparency at the final signing step.
Implementation timing was described as fluid, and while some wallet primitives already reflect similar ideas—such as Ledger Live’s “Clear Signing”—a cross-ecosystem standard for full rehearsals remains under discussion. The challenge is moving from isolated features to an interoperable, widely adopted simulation standard.
The adoption trade-offs include added latency and the need to keep simulation outputs compact enough to fit existing batching and settlement patterns without creating prohibitive overhead. For end users, the upside is straightforward: fewer irreversible losses caused by social engineering or compromised interfaces.
