docs: TIB for evm-simulation intent & effect verification

[Foulks-Plb]

Motivation

evm-simulation today guarantees only "no value retained by bundler3" (assertNoBundlerRetention) plus ERC20/WETH Transfer parsing — which misses signed grants to untrusted spenders, actions nested in batches, side-effect allowances/authorizations (balance delta = 0 but future drain), and value in assets the parser never reads (native, vault shares, debt/LP).

Solution

Adds docs/tibs/TIB-2026-06-15-evm-simulation-intent-effect-verification.md, a Proposed TIB that freezes the design for expanding the package along two verification layers — static decode of declared intent (per-chain spender trust-list, signature/Permit2 interception, recursive batch decode) and dynamic simulation of effective result (multi-asset value diff, realized amounts, state-diff/event inspection for side-effect grants, non-liquidatable invariant) — prioritised vaults first then markets across two milestones. The plan is mirrored in the EVM simulation expansion Linear project (2 milestones, 10 issues). Docs-only change; no package source or changeset.

[0xbulma]

Web3 threat-model review (scoped to intent gaps)

Reviewed as a design doc, focused on web3/EVM gaps in the threat model — grounded in the bundler3 contract (transient initiator, adapter fund-pull, the reenter()/callbackHash callback commitment, "the dispatcher holds no approvals, adapters do") and the current evm-simulation code. Inline comments mark specific gaps. Two cross-cutting points below.

[Low] Name sim-vs-execution divergence as a Constraint/Non-Goal. Every guarantee holds only at the simulated block; slippage tolerance is the sole guard against a bundle that's safe in simulation but sandwiched at inclusion (MEV / state drift). Not a flaw, but it belongs in Non-Goals so "no value loss" isn't read as an execution-time guarantee.

Two strongest additions: (a) make "decode the bundler3 reenter/callbackHash callback sub-bundle" an explicit Layer-A requirement (see comment on the recursive-batch-decode bullet); (b) promote "residual-allowance baseline policy" and "EIP-7702 authorization interception" from implicit to first-class Goals / Open Questions.

Reusability: most Layer-A primitives already exist — Permit2 + EIP-2612 (incl. DAI variant) typed-data in blue-sdk-viem/src/signatures/{permit2,permit}.ts, address registry via getChainAddresses (blue-sdk/src/addresses.ts, exposes generalAdapter1/permit2/bundler3 per chain), ERC-4626 math in blue-sdk/src/vault/VaultUtils.ts, Morpho authorization typed-data in blue-sdk-viem/src/signatures/manager.ts. Only EIP-7702 and the bundler3 callback-bundle decoder are genuinely net-new.

[0xbulma]

[High] Decode bundler3 reenter()/callbackHash callback sub-bundles, not just the outer Call[].

bundler3's sensitive leaves usually don't live in the outer multicall array — they arrive via reenter(Call[]) during a callback (flashloan, Paraswap buy/sell) and are committed in the outer call only as an opaque callbackHash (bytes32). A multicall-array walk sees the hash, not the committed sub-calls, so it declares the bundle clean while the dangerous action hides in the callback — the exact "hidden inside a batch so the outer to looks trusted" threat from the Context section. Layer A should reconstruct the callback sub-bundle and verify it against the committed hash. Also handle skipRevert=true leaves (the intent decoder may assume a call executes when it can silently no-op).

[Foulks-Plb]

Good point, I’ll clarify.

[0xbulma]

[High] Exclude the Bundler3 dispatcher from the approval trust-list — trust only adapters.

Per bundler3's security model: "Bundler3 receives no approvals; it's a dispatcher and could steal funds. Individual adapters are safe to approve." An approve/Permit2 grant whose spender is the bundler3 dispatcher is a red flag; the same grant to GeneralAdapter1 is expected. Reuse risk: the retention trust-set is built from all addresses.bundler3.* values (packages/evm-simulation/src/simulate/pipeline/bundler-retention.ts:44-48), which includes the dispatcher itself. Reusing that set verbatim as the approval trust-list would bless approvals to the one address that must never hold them.

[Foulks-Plb]

Good point. But the model will be based on an allowlist rather than a denylist. The only contracts that will be authorized are the General Adapter and Permit2.

[0xbulma]

[High] Intercept EIP-7702 authorization tuples, not only EIP-2612 / Permit2.

The most complete "zero balance change, future drain" is an EIP-7702 authorization delegating the EOA's code to an attacker contract — it hands over the entire account, dwarfs any single approval, and emits no Transfer/Approval log. 4337 / smart-account flows are explicitly in scope and the repo has zero 7702 handling today (net-new). An intent layer that catches off-chain grants but ignores 7702 has a hole exactly where the stakes are highest.

[Foulks-Plb]

This operates at the wallet/account level rather than the application level. I’m not sure this is something we can reliably verify at the app layer.

[0xbulma]

[Medium] Permit2 coverage omits AllowanceTransfer (standing) mode and any amount/deadline policy.

Listed: SignatureTransfer/PermitTransferFrom/PermitBatchTransferFrom (one-shot). Missing: Permit2 IAllowanceTransfer.permit/permitBatch (approve2) — the standing allowance with amount+expiration+nonce, the more dangerous future-drain vector, and one bundler3 supports. Also nothing checks unlimited (type(uint256).max) amounts or far-future deadlines even to a trusted spender. Trust-list membership ≠ safe amount/duration. Reuse getPermit2PermitTypedData from blue-sdk-viem/src/signatures/permit2.ts.

[Foulks-Plb]

Thinking about it more, I don’t think amount and expiration are part of our security model. GeneralAdapter is a static and trusted component, so the critical property is who receives the allowance, not its amount or duration.

[0xbulma]

[High] Define the residual-allowance baseline — this check's correctness hinges on it.

bundler3 flows legitimately rely on a standing Permit2 allowance to GeneralAdapter1 (approve2/AllowanceTransfer) that persists across bundles by design. "No allowance/authorization granted as a side effect beyond what the declared intent required" needs an explicit policy separating expected residual adapter allowances from malicious side-effect grants — otherwise the check is either noisy (flags every legit standing allowance) or toothless. This is the single most important unspecified decision in the design; promote it to Open Questions.

[Foulks-Plb]

True, I’ll clarify the Permit2 case.

[0xbulma]

[Medium] "No net value loss across asset types" has no price basis — it can only check against the caller's declared expectation.

For any asset-crossing flow (Paraswap swap, supplyCollateral A → borrow B), "net diff ≥ expected across all asset types" isn't computable without an exchange rate, but USD/oracle valuation is a Non-Goal. So the guarantee reduces to "matches the integrator-supplied expected amounts" — a malicious or buggy declared expectation passes. State plainly that Layer B verifies conformance to declared intent, not fairness, so integrators don't over-trust it.

[Foulks-Plb]

Good point. Net diffs across asset types are too complex to handle properly at the moment. Let’s avoid introducing this notion for now and focus on verifying conformance to the declared expectations.

[0xbulma]

[Medium] "Realized amount / every asset type" breaks on hostile ERC20s beyond fee-on-transfer/rebasing.

Also in scope: ERC-777 tokensReceived/tokensToSend hooks (a reentrancy vector that also double-counts Transfer logs); double-entry-point tokens (one balance, two proxy addresses — the Compound/TUSD class) that defeat per-address balance/Transfer accounting; and return-false-not-revert tokens. A value-diff built on Transfer logs + balance diff inherits all of these. Scope which token classes are in/out, and degrade-to-warning on detected hooks (same discipline as the native-trace gap).

[Foulks-Plb]

Hmm, maybe that’s out of scope for now. I’ve never seen any tokens other than standard ERC-20s on Morpho.

[0xbulma]

[Low] Allow-list the resolved callback target, not the callback role.

Treating "callback adapters" as a permitted non-from recipient role is a hole if the target is attacker-chosen. The resolved callback target (flashloan provider, Paraswap augustus) routes value and must itself be trust-listed — tie the allowance to the resolved target address, not the role.

[0xbulma]

[Medium] Native-ETH no-loss degrades to a warning on eth_simulateV1 — for the highest-value asset.

Internal native transfers (call-value, selfdestruct refunds) are invisible to eth_simulateV1 and a prime exfil path through callback adapters. "Degrade to warning, never silent pass" is the right rule, but consider requiring Tenderly for native-bearing bundles rather than letting a user click through a warning on the most fungible, highest-value asset.

[Foulks-Plb]

I just found a solution that eliminates the blind spot around native ETH utilization. We’ll be able to remove this limitation from the TIB.

[Foulks-Plb]

#803

[0xbulma]

[Low] Open Question 2 has a security edge. convertToAssets at the simulated post-state can be skewed by an intra-bundle donation/inflation move, so the vault value-diff should be robust to in-bundle share-price manipulation, not just read the post-state conversion (the root invariant set already calls out an inflation-attack guard). Reuse VaultUtils.toAssets/toShares from blue-sdk/src/vault/VaultUtils.ts.

[Foulks-Plb]

Maybe we shouldn’t implement inflation attack protection, it seems quite difficult to do properly. Unless someone has a quick and simple idea for how to implement it?

[Rubilmax]

Great!