Fixing frames:
The frames account model is that the account itself should be the authority, an "internally owned account".
This model gives the protocol a black box that it can send data at and see if opcodes come out. Tracing and other mitigations are added to try and peek into the box.
8130 can express that model. It can also express externally owned accounts, and authorization more granular than full ownership. Use an external authenticator and the frame problems do not appear. Use the frame model inside 8130 and you get the same problems.
Frames force that broken account model onto the user and they try to enshrine it.
So how do we fix 8141?
We need to use the 8130 keystore to bring authority back out of the account. Internally owned accounts are still expressible via the keystore, so 8130 is strictly more general.
Once authority is correctly external, we can start cutting complexities and mitigations in 8141.
Signature list - no longer needed, authenticators are external and aggregation is simple
Opcodes - no longer needed, we are speaking to authenticators now that aren't coupled with wallet execution and authority code
Tracing infrastructure - optional! May be needed if the chain wants to support some specific use cases
So what's left is frames themselves, which we can cut as well. The remaining argument is that the arbitrary ordering means you can pay for a transaction at the end of execution. If a chain wants it then just add a payer mode. 8130 already has self and external, so add a tag for self-pay at end of transaction.
Fixing frames means dropping frames.
Minimal keystore if chains (like L1) don't want all the feature set (policy gate, actor change lock).
gist.github.com/chunter-cb/6…
CH retweeted
=== @Offchain’s stance on Native AA: EIP-8141 vs EIP-8130 ===
We are very happy that ACD is considering Native AA as a Hegota headliner, and think it is essential for L1 to adopt it.
For @Arbitrum, we evaluate Native AA designs based on throughput, DoS risk, DevEx, and wallet UX/security.
TLDR ->
• To support 8141 in Arbitrum Nitro, we need pure verification frames to become the default validation path. We are working with @ethereumfndn, @ethlabs_org, @base, & @WalletConnect on this direction.
• We also support an optional Guarantor mechanism, where another account can safely pay for the transaction. We will propose this separately.
• Offchain is reviewing the prospect of proposing that the Arbitrum DAO adopt 8130 first. It provides the guarantees needed today, covers the main user flows & does not prevent adding 8141 later.
• We think 8130 deserves genuine consideration in this headliner process, but we are not explicitly asking ACD to adopt it.
• If ACD converges on a modified 8141 for L1, we will support this effort and reconsider implementing it alongside 8130.
What matters most to us: Native AA standards designed with L2s in mind, in compatible ways, so wallets and infra can support them.
Full statement below 👇
The fundamental problem with previous AA attempts is the account model!
Coupling account execution, authentication and authority in one place means that the protocol loses visibility, dependencies must be discovered (via simulation/tracing), layers of mitigations are added.
8141 enshrines that.
The original account model that ethereum shipped with was a decoupled one! The authority was protocol managed and a single intrinsic mapping of secp256k1 to an account. 7702 let accounts set their execution code, which was a good addition.
Execution code in one place (wallet bytecode), authentication in another (secp256k1), authority in another (protocol managed mapping).
8130 just generalizes this mapping system so that its updatable to any contract defined authentication scheme and no longer singular.
Because the model stays decoupled, the transaction type can be declarative. Dependencies can be recognized in the transaction itself.
Mitigations fall away. Customizations can be added on cleanly. Every chain can build what it needs.
8130 enshrines exactly one thing, the authority mapping system, and all of AA falls out.
CH retweeted
After spending months on EIP-8141... I’m convinced EIP-8130 is the better path for native account abstraction
It’s simpler, more portable, and focused on what wallets actually need!
One last post then it's time for the weekend.
A good way to think about 8130 is to go back to pre-AA Ethereum.
A secp256k1 key controlled an account, and that mapping was an intrinsic, unchangeable property of the address.
EIP-8130 simply makes that mapping updatable, to any contract defined authentication scheme and you update those with a signed payload, similar to a transaction. Those mappings need to live somewhere and thats the keystore.
ERC-4337 + ERC-1271 went a different direction, fusing authentication and authorization in one codebase per implementation.
8130 shares a lot of DNA with 7702. Authorization is external to wallet bytecode, execution code lives in the account address(batch calls etc), but now that external authorization can be managed!
I want Ethereum and the EVM to win. A strong EVM flows back to everything built on it. Every decision in 8130 considers the goals of the various EVM chains, the wallet, the app and the user. The goals of each are different but they don't have to be in conflict.
One simple test for a native AA standard: does it serve everyone's needs? Any standard can be enshrined on one chain. Only one that serves every constituency (the chain, the wallet, the app, the user) gets adopted everywhere. So that's what 8130 was designed for, from the ground up.
All chains want performance, but differ on which features they need or want to support. Features and performance can typically compete for the same resources, so 8130 put a lot of work into decoupling pieces that are normally conflated and allowing each chain to make the right choice for itself. The foundation of 8130 is performant, feature rich and easily extensible. That's why one standard serves high-performance L2s and alt-L1s (with goals for scale, short block times and custom feature sets) and extends to everything L1 needs: privacy flows, maximum decentralization and censorship resistance. And of course a post-quantum path for all.
Wallets want great UX with minimal overhead. Familiar systems and not a custom implementation per chain (though that's the way it's been going). Ideally one standard that works everywhere and in the same way. 8130 treats portability as paramount. Build once and it's always one transaction to deploy, sync, and act on a new chain with the same address everywhere.
Apps want the same thing one layer up. Build for one account model without reasoning about wallet compatibility. Standardized session keys, subscriptions, and permission grants remove an entire class of problems. Native AA means one-click passkey onboarding and sponsored transactions out of the box.
The end user gets what all of this was for: accounts that work everywhere, gas they never think about, one click instead of five signatures, keys they can rotate and recover without moving funds. Apps that just work.
Now do the same test for the alternative AA proposal. With frames, chains must choose between features and performance. One example is 8141's default-account fast path as it doesn't natively provide passkeys, session keys, sub-accounts, or key rotation. Those require custom authorization code, which requires tracing and forfeits the fast path's direct evaluation. Chains that can't afford that, or other inherent tradeoffs in the spec, may not adopt it, or if they do, they may have to adjust their goals. Wallet fragmentation persists, apps keep building for multiple targets, and overall UX suffers.
L1 enshrining one standard that can't satisfy the needs of the wider EVM ecosystem results in divergence. I believe this is avoidable. 8130 can be a unifying account standard for the EVM, and we can continue toward the world-class UX that crypto deserves.
8130 is already the strong choice for native AA for validation only partial statelessness (VOPS). Validating an 8130 transaction reads only the Keystore (+world state).
In contrast frames execute against the account storage (+world state) and require add on EIPs like 8369 to help manage. That gap matters for FOCIL + zkEVM verifier nodes + validation performance.
8130 goes further with fully stateless accounts! A transaction-scoped account combined with 8130's nonceless transactions means no storage writes outside of its interactions.
Stateless, ephemeral accounts are an essential building block for private, uncensorable, no intermediary transactions on L1!
ethereum-magicians.org/t/eip…
EIP-8130 was designed from the ground up for native AA across the EVM: pragmatic, performant, and built to fix wallet UX and serve scaling at the same time. As L1 decides which native AA proposal to enshrine, I'll be publishing the full case for 8130 starting today, through next week!
Stay tuned!
Excited to be working with @Optimism and @WalletConnect on this! Native AA this year.
Updated EIP - 8130 for native account abstraction!
Now has fully permissionless expression of authentication types for wallet signature verification! Fully extensible without hard fork and can optimize at protocol level when needed.
No tracing, no reputation or staking mechanisms. No new opcodes, no new frame system.
Performant, deterministic validation, ready for the PQ + ZK future.
Key rotation, gas abstraction, programable accounts, batching, … it’s all there.
Check it out github.com/ethereum/EIPs/pul…
Check out EIP-8130 — account abstraction by account configuration
The idea: enshrine auth types in a system contract. Protocol reads known storage slots to validate.
Built for all the standard AA use cases (programmable accounts/gas sponsorship/key rotation/...). Backwards compatible with all account types. Made to be extensible and support future quantum migration.
Would love any feedback! ethereum-magicians.org/t/eip…
