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.
- 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.
Love the post. I think 8130 is an amazing standard, but fear it'll be hard to implement on the L1 due to the amount of work that went into getting the clients organized around Frames. However, I am thinking that this might be a problem to solve on another layer, specifically
I like the default account fast path - it makes Frame transactions out of the box no worse a user/dev experience than using regular transactions. Then you can start using the more powerful things from a start of "works like the old way". That's likely to help adoption a lot.
