ERC draft: Independent Simulation Result for (STVA)

What it is

An Ethereum Magicians draft ERC (STVA) that standardizes a SimulationResult so independent parties can recompute it from the same inputs and get an identical hash. The page is an early forum post that asks for feedback. It gives no author, ERC number, or reference implementation.

How it works

Inputs are the full preimage of the transaction (UserOperation or SafeTx, including every field that enters the hash), a block/state root or Merkle proofs of the relevant state, and optional overrides.

The prose lists these output fields: success, gasUsed, return data and logs in canonical encoding, stateDiff (or its hash), structured balanceChanges and tokenTransfers, optional semanticEffects, snapshotId (block number plus state root), and simulatorId/version. semanticEffects should preferably be recomputed using ERC-7730-style descriptors.

The reference struct is smaller: success, gasUsed, returnData, stateDiffHash, logsHash, snapshotId, resultHash and an optional derivedSummary. Balance changes, token transfers and simulator ID appear only in the prose list. The struct also contains resultHash itself, described as the self-describing canonical hash. The page does not say how that field is excluded from the hash input.

The hash is either keccak256(abi.encode(SimulationResult)) or a domain-separated EIP-712 hash. The draft leaves the choice open.

The result hash is meant to be bound into signatures and Scoped Capability Tokens. The draft also says simulation should be required before high-privilege authority transitions.

Preconditions / Affected

The draft targets wallets, hardware signers and verifiers that currently trust a frontend's simulation. It states one hard requirement: a hardware offline verifier MUST be able to re-execute, or re-verify proofs, and reject on mismatch.

What to do

Nothing is deployable yet. Reviewers can comment on the three open points the author lists:

• Whether stateDiff is encoded in full or as a hash only, trading size against checkability.
• Whether prestate proofs are required, or a trusted RPC with multi-node consensus is enough.
• How tightly the result binds into the VerificationPayload and capabilities.

Caveats

The compliance tiers are loosely defined. Basic accepts any simulator, Standard needs multi-node consensus on the state root, and Strict needs local revm/EVM execution plus Merkle proofs of prestate. Only Strict rules out a lying RPC. The page does not say how Standard handles nodes that disagree. The draft depends on other drafts (capability tokens, authority lifecycle) that it does not link.