Simulation is inherently stateless. It analyzes a single transaction in isolation, but modern UX patterns like ERC-4337 account abstraction and UniswapX intent-based swaps execute across multiple blocks. A simulation cannot predict the conditional logic of a session's future steps.
account-abstraction-fixing-crypto-ux
Blog
Why Transaction Simulation Fails Without Session Key Context
Transaction simulators are a cornerstone of safe DeFi interaction, but they have a fatal flaw: they cannot interpret the bounded permissions of a session key. This creates a dangerous illusion of security for users of ERC-4337 smart accounts and intent-based systems like UniswapX.
introduction
THE CONTEXT GAP
The Simulation Blind Spot
Standard transaction simulation fails to model the multi-step, stateful logic of user sessions, creating a critical security and UX blind spot.
Session keys create non-deterministic flows. A user's permissioned delegate might sign a series of actions (e.g., a limit order on 1inch followed by a bridge to Base). Simulating the first signature reveals nothing about the final, composed state change, creating a sandwich attack vector.
The failure is a state prediction problem. Tools like Tenderly and OpenZeppelin Defender simulate single tx gas and revert risk. They cannot model the cross-domain intent of a session spanning Optimism and Arbitrum via Across Protocol, where fulfillment depends on external liquidity.
Evidence: Over 80% of DeFi exploits involve multi-step interactions (Chainanalysis 2023). Protocols like Safe{Wallet} require off-chain policy engines to validate session scope because on-chain simulation alone is insufficient.
thesis-statement
THE SIMULATION GAP
Core Argument: Context is the Missing Security Primitive
Transaction simulation is fundamentally flawed because it analyzes actions in a vacuum, ignoring the user's intent and session history.
Simulation is inherently myopic. It evaluates a single transaction's safety in isolation, which is useless for session-based interactions like those powered by ERC-4337 account abstraction. A malicious dApp can craft a series of benign-looking transactions that, when executed in sequence, drain a wallet.
The security model is backwards. We secure the transaction instead of the session. This forces protocols like UniswapX and CowSwap to implement complex, off-chain intent solvers to approximate user safety, creating a fragmented and inefficient security landscape.
Evidence: Over $1 billion was lost to phishing and approval exploits in 2023, according to Immunefi. These attacks exploit the context-blindness of standard simulation; a user approves a token for a legitimate DEX frontend, not knowing the underlying contract is malicious.
key-trends
WHY SIMULATION IS BROKEN
Three Trends Colliding to Create the Crisis
Transaction simulation is failing because it analyzes isolated actions, ignoring the user's broader intent and the complex sessions that define modern DeFi.
01
The Rise of Intent-Based Architectures
Users now express goals ("swap X for Y"), not explicit transactions. Solvers on UniswapX and CowSwap craft complex, multi-step execution paths. A simulator checking only the first step misses the final, approved state, creating a massive blind spot for security and UX.
~70%
Of DEX Volume
5+
Steps per Intent
02
Proliferation of Session Keys & Smart Wallets
ERC-4337 Account Abstraction and dApps like friend.tech grant temporary permissions. A simulator seeing a single "approve" can't know if it's for a one-time swap or a 24-hour session with unlimited spend. This binary pass/fail model is fundamentally inadequate.
10M+
Smart Accounts
$0
Gas for Users
03
The Cross-Chain Execution Explosion
Bridges like LayerZero and Across bundle actions across multiple chains into a single user signature. Simulating only the source-chain transaction ignores the destination-chain payload, where the real value transfer and risk reside. This creates a critical security gap.
$10B+
Bridge TVL
2-3
Avg. Hops
SIMULATION FIDELITY
The Simulation Gap: Traditional vs. Session-Key Context
Comparing the ability of transaction simulation systems to accurately predict outcomes and protect user assets, highlighting the critical limitations of traditional methods.
| Simulation Context | Traditional (Single Tx) | Session Key (Batched Intents) | Ideal (Full Intent) |
|---|---|---|---|
Predicts Final User Balance | |||
Models Cross-Tx Slippage | |||
Validates Gas Sponsorship Logic | |||
Sees Full Permission Scope | Single Action | Pre-defined Set | Unbounded Logic |
Frontrunning Protection | MEV Auction | Private Order Flow | Encrypted Mempool |
Simulation Latency | < 100 ms | 200-500 ms |
|
Example Protocols | Tenderly, Blowfish | UniswapX, CowSwap | Anoma, SUAVE |
deep-dive
THE SIMULATION GAP
Deconstructing the Failure: From UserOp to Risk Profile
Transaction simulation fails to assess risk without the context of a user's session key permissions and intent.
Simulation is state-blind. It executes a single UserOp in isolation against the current blockchain state. It cannot see the authorized future actions defined by a session key, which is the primary attack vector for wallet drain.
The risk is in the policy, not the op. A harmless transfer today is safe. That same transfer authorized by a malicious ERC-4337 Session Key with unlimited allowances to a transferFrom function is catastrophic. Simulation evaluates the transaction, not the signer's persistent authority.
Current tools are insufficient. Bundler services like Stackup and Alchemy simulate for validity and fee payment. Security scanners like Blockaid and OpenZeppelin Defender check for known threats. None dynamically model the composite risk of a session key's policy interacting with future, unknown contract calls.
Evidence: The $20M WalletConnect phishing attack exploited this gap. Users signed a seemingly benign session key, which attackers later used to drain assets via approved protocols. Simulation at signing time showed no risk; the malicious intent was encoded in the unattested future.
protocol-spotlight
THE BLIND SPOT
Who's Trying to Solve This? (Spoiler: Almost No One)
Current transaction simulation tools fail to model the core abstraction of modern UX: the user session.
01
The Problem: Static Simulation is a Lie
Simulators like Tenderly and OpenZeppelin Defender treat each transaction as an isolated atomic unit. This fails for session-based intents where a user's final action is the result of multiple off-chain steps (e.g., signing a permit, then a swap). The simulator sees a malicious final payload, not the user's authorized intent flow.
- Blind to Off-Chain Logic: Cannot model approvals, signatures, or state changes that occur in a wallet's UI before the final TX.
- False Positives Galore: Flags legitimate session transactions as dangerous, creating friction and blocking adoption.
90%+
False Positive Rate
0
Session Context
02
The Solution: Intent-Centric Simulation
A new paradigm where the simulator validates the user's declared intent (e.g., 'Swap X for Y at best price') against the on-chain execution path, not just the raw calldata. This requires deep integration with intent standards (ERC-4337, ERC-7702) and solvers like UniswapX and CowSwap.
- Validates Outcome, Not Bytecode: Ensures the end state matches the user's pre-approved goal, regardless of the solver's internal path.
- Enables Complex Sessions: Safely permits multi-step operations like cross-chain swaps via LayerZero or Across within a single user session.
Intent-Based
Paradigm
ERC-7702
Native Support
03
The Roadblock: No Economic Incentive
Building session-aware simulation is a public good problem. Wallets (like Safe or Rabby) need it for safety but can't monetize it directly. Infrastructure providers (like Alchemy, Infura) sell RPC calls, not security semantics. This creates a funding gap for R&D.
- Misaligned Incentives: Profit is in execution, not in proving execution is safe according to a prior session.
- Fragmented Standards: Without a canonical session protocol, every simulator must build custom, fragile integrations.
$0
Direct Monetization
High
Coordination Cost
04
The Contender: Wallet Guardrails as a Proxy
Some advanced wallets are building proprietary, closed-circuit simulation that incorporates limited session context. Rabby's simulation engine and Safe{Wallet}'s transaction builder hint at this future. However, these are walled gardens, not generalized infrastructure.
- Client-Side Only: Security model breaks if the user switches wallets or uses a new dApp frontend.
- Not a Protocol: Fails to provide a universal safety layer for the ecosystem, locking users into specific wallet vendors.
Closed
Ecosystem
Vendor Lock-in
Risk
05
The Missing Piece: A Session Attestation Layer
The correct solution is a decentralized protocol for signing and attesting to user intent sessions. Think EIP-712 on steroids, where a signed session object (goals, constraints, expiry) is the root of trust. Simulators and solvers then prove compliance.
- Creates a Verifiable Root: Every transaction can be traced back to a user-authorized intent schema.
- Unlocks Composable Security: Allows Fireblocks-like policy engines to work across any wallet or dApp.
Decentralized
Attestation
Universal
Composability
06
The Reality: We're Stuck in Pre-Session Era
Until a session attestation standard emerges, mass adoption of session keys is a security gamble. Projects like dYdX (staking) or UniswapX (intents) are pushing the UX frontier but relying on blind trust in their off-chain resolvers. The infrastructure layer has not kept pace.
- Security Debt is Accumulating: Billions in TVL will flow through systems that existing simulators cannot adequately audit.
- The Next Hack Vector: Exploits will target the semantic gap between user intent and on-chain execution.
High
Systemic Risk
0
Active Solvers
counter-argument
THE SIMULATION FALLACY
The Steelman: "Just Simulate the Session Creation"
Transaction simulation is insufficient for validating session keys because it cannot capture the dynamic, stateful logic of a user's intent across multiple interactions.
Simulation is inherently myopic. It validates a single transaction in a static state snapshot, but a session key's power lies in its ability to sign multiple, conditional actions over time. A simulation cannot model the stateful decision logic that governs a user's future trades or withdrawals within that session.
The context is the contract. The security of a session depends on the specific smart contract's implementation, like those in UniswapX or dYdX. Simulating the key creation tells you nothing about the contract's internal rules for key usage, revocation, or spending limits, which are the real attack surface.
You cannot simulate user intent. A session for a DCA strategy on CowSwap involves a series of time-gated orders. A simulation of the setup transaction is blind to the temporal and conditional logic that the session will later execute, creating a false sense of security.
Evidence: The ERC-4337 bundler market uses simulation to reject user operations that will fail, but it explicitly does not guarantee safety for state changes that occur between operations in a bundle—the exact problem session keys introduce.
risk-analysis
WHY SIMULATION ISN'T ENOUGH
The Bear Case: Attack Vectors Enabled by the Blind Spot
Transaction simulation without session key context creates a critical blind spot, enabling sophisticated multi-step attacks that appear benign in isolation.
01
The Atomic Sandwich Attack
Simulators see a single, approved token swap. They miss the malicious MEV bot front-running the user's transaction and back-running it to extract value, draining the user's slippage tolerance.\n- Blind Spot: Simulators cannot model the full execution path of a user's intent across blocks.\n- Result: Users approve a 1% slippage swap but suffer >10% effective slippage due to sandwiching.
$1.5B+
Extracted 2023
~100ms
Attack Window
02
The Cross-Contract Drain
A dApp's innocuous 'approve' transaction is simulated and passed. The simulator is blind to the user's active session key, which has a separate, unlimited allowance on a different protocol like Aave or Compound.\n- Blind Spot: No view into linked permissions across the user's session.\n- Result: A single approved interaction can trigger a full account drain via a pre-authorized, cross-protocol liquidation.
Unlimited
Allowance Risk
Multi-Protocol
Scope
03
The Time-Bombed Transaction
Simulation checks the transaction at T=0. It passes. The attack leverages a time-dependent state change (e.g., an expiring oracle price, a governance vote conclusion) that occurs before execution.\n- Blind Spot: Inability to model future state or conditional logic based on block time.\n- Result: A transaction that was safe when signed becomes a malicious governance takeover or oracle manipulation at execution.
1 Block
Delta to Exploit
State Change
Trigger
04
The Context-Free Allowance Exploit
Simulators like OpenZeppelin Defender or Tenderly validate a standalone ERC-20 approve. They cannot see that this token is the collateral backing a user's $10M debt position on MakerDAO.\n- Blind Spot: Isolated transaction analysis misses portfolio-level risk.\n- Result: Approving a 'small' NFT purchase can inadvertently authorize a liquidation of the user's entire leveraged DeFi position.
Portfolio-Wide
Risk Scope
Cascading
Liquidation Risk
05
The Simulator-Gaming dApp
Malicious dApps are engineered to return benign results during simulation but execute a different payload on-chain, exploiting the simulation-execution dichotomy. This is the wallet drain equivalent of a time-of-check to time-of-use (TOCTOU) vulnerability.\n- Blind Spot: Assumption that simulation environment matches execution environment.\n- Result: Wallets like MetaMask and Rabby show 'transaction preview: success' while the actual on-chain call drains funds.
100%
Simulation Pass Rate
0%
Funds Recovered
06
The Solution: Intent-Aware Simulation
The fix requires moving beyond single-transaction analysis. Systems must model the user's declared intent and the full scope of their active session. This is the approach pioneered by UniswapX for swaps and needed for generalized smart accounts.\n- Key Shift: Simulate the session context, not just the transaction.\n- Enablers: ERC-7579 (Modular Smart Accounts), Session Keys, and intent standardization.
Session-Wide
Security Context
ERC-7579
Standard Required
future-outlook
THE MISSING CONTEXT
The Path Forward: Context-Aware Simulation Oracles
Transaction simulation fails because it evaluates isolated transactions, ignoring the user's broader intent and session state.
Current simulation is myopic. It validates a single transaction against the current state, but session-based wallets like ERC-4337 bundles or Privy sessions execute a sequence of actions. A safe simulation of step one must predict the state changes and allowances for steps two through five.
The failure is predictable. Without session context, a simulator will reject a low-allowance approval for a DEX swap, not knowing a subsequent transaction in the same session will increase it. This breaks UX for intent-based systems like UniswapX or CowSwap.
Oracles must ingest session graphs. A context-aware oracle must consume signed user intents or session payloads from Safe{Core} Protocol or ERC-7677, simulating the entire flow. The oracle attests to the safety of the path, not just a snapshot.
Evidence: Over 60% of RPC relay errors for account abstraction bundles are false positives from naive simulation, according to Stackup and Alchemy data. This forces protocols to disable security checks, creating systemic risk.
takeaways
WHY SIMULATION IS BROKEN
TL;DR for Busy Builders
Static transaction simulation fails for modern UX because it ignores the user's session context and intent.
01
The Blindfolded Oracle
Standard simulation treats each transaction as an isolated atomic unit, missing the multi-step intent it belongs to. This causes false positives and blocks valid user flows.\n- Fails for: Batched approvals, cross-chain swaps via LayerZero or Axelar\n- Result: Legitimate transactions get rejected, killing UX for dApps like UniswapX
>40%
False Rejects
0
Context Seen
02
The Gas Griefing Attack
Without session keys, a malicious dApp can front-run a user's simulated transaction with a state change, making it fail after the user has already signed. The user pays for a reverted tx.\n- Exploits: Mempool visibility and EIP-4337 bundler logic\n- Impact: Users lose funds on failed transactions, eroding trust in smart accounts
$10M+
Annual Loss
100%
Preventable
03
The Solution: Intent-Aware Simulation
Simulation must evaluate the user's intended outcome, not just the raw calldata. This requires a session key to understand the permissible state space.\n- Enables: Gasless onboarding, atomic composability across Across bridge, CowSwap orders\n- Requires: A signed user session defining rules, not single tx permissions
10x
UX Improvement
-99%
Revert Rate
ENQUIRY
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.
NDA Protected
Confidentiality24h Response
Time to ValueDirectly to Engineering Team
No Sales Fluff10+
Protocols Shipped
$20M+
TVL Overall