Calldata Pipeline

Simulation

Every x0x1 transaction runs on a Foundry Anvil fork before signing. Full state diff shows balance changes, events, and gas cost. Post-sign verification replays the signed TX to catch tampering.

Why simulate How it works State diff

The Recipe System builds transaction calldata. Before that calldata touches mainnet, it runs here — on a simulated copy of the blockchain.

Why simulate everything

A wrong parameter or stale approval can drain a position. Simulation catches these failures before real funds are at risk. Anvil (from Foundry) forks mainnet state at a specific block — all contract code and balances cloned into a local sandbox.

TX simulated

No TX ever hits mainnet without a dry run first

Verify

Once before signing, once after -- catches signing malware

Fork

Real chain state

Latest block, your exact balances -- not a mock

How simulation works

# Anvil fork with 60s timeout for slow RPC
cast send --rpc-url http://127.0.0.1:8545 \
  --from $WALLET_ADDRESS \
  --unlocked \
  $CONTRACT_ADDRESS \
  "deposit(uint256,address)" \
  $AMOUNT $RECEIVER

Reading the state diff

The state diff shows exactly what will change on-chain:

State changes:
  USDC balance:  10,000.00 → 0.00        (-10,000.00)
  eUSDC balance: 0.00      → 9,847.32    (+9,847.32)
  Approval:      0         → 10,000      (exact amount, not infinite)

Events:
  Transfer(from=user, to=vault, amount=10000000000)
  Deposit(user=user, assets=10000000000, shares=9847320000)

Gas used: 187,432
Estimated cost: $0.42

Post-sign verification: After the user signs the transaction on their device, the pipeline replays the signed TX on a fresh Anvil fork to confirm the signature changed nothing. Only after this second pass does it broadcast.

Simulation proves the transaction is safe. Next, the Threat Model explains why signing happens on a separate, air-gapped device — and what that protects against.