Read through the thread carefully. Adding a contract-level perspective that maps onto a few of the still-open debates.
Background: we’ve been operating EVVM, a smart-contract-native virtual blockchain framework, since 2023. It runs validation, signature schemes, async nonces, batched execution, and gas sponsorship inside Core.sol. ~200 community deployments across 10+ EVM-compatible chains. Each instance can configure its own rules independently of the others on the same host.
Three observations from the production context that overlap with current discussion:
1. The “what about institutional rules” gap. Most of the thread reasons about a universal frame transaction. Some real users (banks, regulated DeFi, public-sector pilots) need per-environment policy: KYC/AML gates, allowlists, custom delegatecall guards in front of execution. EVVM instances configure those policies through per-deployment contracts. None of that is reachable at protocol level without breaking universality, and 8141 correctly does not try to. Worth being explicit in the spec or rationale that the contract layer remains the place where policy variance lives, because real adopters will land there first.
2. Async-execution compatibility as a contract-level property. @DanielVF and @chunter’s concerns about Monad / Base / Tempo are real for protocol-level validation. EVVM-style validation sidesteps that entire class because it runs inside the contract at execution time, against the post-state of prior transactions in the block. The host chain treats it as a regular contract call. Async execution and contract-level AA can coexist by design: nothing in this model depends on validation being known at mempool time. Not an argument against 8141, an architecture point that may be worth referencing for chains where 8141 cannot ship.
3. Two implementation choices in 8141 that we made differently, observable in EVVM today:
-
Per-operation success tracking in batches, vs the all-or-nothing atomic batching in @derek’s recent PR. EVVM’s
batchPayreturnsbool[] results. The trade-off between application-class needs (e.g. independent dust transfers vs approve-then-swap dependencies) is one we hit early; whether 8141’s atomic-only mode covers both classes cleanly or forces the per-op case into separate transactions is worth checking before lock-in. -
Non-authoritative reservation as the only reservation primitive (covered in the EIP-8250 thread). We deliberately did not ship authoritative locks because of DoS-by-lock-grabbing and bad-UI lockup vectors; this likely matters at protocol level too if keyed nonces ship.
References:
-
Signature constructor: https://www.evvm.dev
Best,
German Abal / @ariutokintumi
Co-Founder, Architect & Security of EVVM