HostNexFlow › Guides › Transaction simulation explained
Transaction simulation, explained
The preview screen before you sign is a dry-run of that one transaction — no more, no less. Reading it correctly is a skill; trusting it completely is a habit that drains wallets.
Modern wallets simulate your transaction before you sign it: they execute a throwaway copy against current chain state and show you the projected result — token balances in and out, approvals granted, programs touched. It is the single most useful safety feature wallets have shipped in years, and it is also routinely misunderstood. A simulation answers "what happens if this exact transaction executes right now?" — nothing more. Every blind spot below lives in the gap between that question and the one users actually want answered: "is this safe?"
What the simulation actually is
On Solana the wallet calls simulateTransaction against an RPC node; on EVM it runs an eth_call-style dry run or a trace-level emulation. Either way, the chain runs your transaction without committing it and reports what state would have changed: which accounts gain, which lose, which programs were invoked, what would have reverted. The wallet then renders that as the preview — "you will receive X, you will send Y, this site will gain approval over Z."
That preview catches entire attack classes beautifully: the swap that quietly adds an approval for your whole balance, the "claim" transaction that shows your tokens leaving, the mint button whose simulation reveals a transfer to an unknown address. When the preview shows your assets moving in a direction you didn't expect, believe it — that warning is the feature working.
Blind spot 1 — it simulates this transaction, not this contract
A simulation tells you what this call does today — not what the contract is capable of tomorrow. A token whose transfer function simulates as a clean buy can still carry sell-side logic that activates by condition: a blacklist flag, a trading-switch the owner flips after the pump, a tax that kicks in above a threshold. The sim ran the code as it stands at this second, against this input. Honeypots specifically exploit the gap: the buy simulates perfectly because the sell path was never simulated. The sell-path variants this misses →
Blind spot 2 — it can't see the next transaction
Simulation is scoped to a single signature. A drainer that needs two signatures — "verify" then "claim" — simulates each one as a harmless-looking step: the first previews as a trivial message-sign or a tiny approve, the second does the taking, and you consented to each preview in isolation. The attack is the sequence; the tool only ever sees one frame of it.
Blind spot 3 — the preview is only as honest as its source
Simulation runs on an RPC node, and the wallet trusts what that node returns. A compromised or hostile RPC — or a dApp that supplies its own "simulation" readout, rendered in the page rather than by your wallet — can show a rehearsed result. The rule: trust previews rendered by your wallet's own confirmation screen, never numbers printed inside a webpage, a bot message, or a popup the site itself drew. If the "preview" lives in the site's UI, it's marketing.
Blind spot 4 — humans read it as a green light
The deepest blind spot is cognitive. A clean simulation feels like approval from the infrastructure, so people skim the one line that mattered — the approval scope, the recipient, the "balance change" that goes negative. Drainers rely on preview fatigue: after fifty harmless confirms, the fifty-first carries the payload. The simulation did its job; the reader didn't do theirs.
How to actually read a preview: three lines matter every time — what leaves your wallet (should match what you meant to send), what approvals are granted (to whom, over which token, capped how), and who receives. If any of those is a surprise, cancel — not "proceed carefully," cancel. The preview is cheap; the signature is not.
Simulation plus the token check, not instead of it
The preview audits this transaction; the token scan audits the thing you're buying. They're complementary layers: a clean swap simulation into a honeypot still ends in an unsellable token, and a fair token behind a malicious site still drains through the approval the sim flagged and you skipped. Run the token check before you ever reach the sign screen, then read the sign screen like it's the only thing standing between you and the loss — because it is.
The check that happens before the preview
Simulation shows the transaction; the scan shows the token — authorities, liquidity, holder spread — so a clean preview never walks you into a rigged asset.
What the preview can't do for you
Simulation can't read intent, can't see the second signature coming, can't guarantee the code won't change after yours executes, and can't force you to look at the approval line. It's a seatbelt, not an autopilot. The wallets that simulate deserve credit for moving the checkpoint to the last moment before consent — the finish line is a user who treats that screen as a read-the-room exercise, not a formality to tap through.
Frequently asked
What does wallet simulation actually do?
Runs a throwaway copy against current chain state and shows projected balance changes, approvals, and program calls before you sign — 'what happens if this runs now,' not 'is this safe.'
Can a honeypot pass simulation?
Yes — it simulates this transaction under current conditions. A clean buy preview coexists with a blocked sell path the buy never exercises.
Why do drainers split signatures?
Each previews harmlessly in isolation — the theft is the sequence, and the simulator only sees one frame.
Trust a simulation inside the website?
No — only your wallet's own confirmation screen. Site-rendered 'previews' are supplied by the counterparty.
What to look at in every preview?
What leaves, what approvals are granted and to whom, and who receives. A surprise on any line means cancel.