One very common pattern with discourse around chain features is "our chain has X, Ethereum doesn't have X". Most of the time it's true in some ways, but also wrong in other, important ways. Ethereum is built to the core for permissionless innovation. It's a Turing-complete virtual machine for its execution, with very few opinionated choices for its consensus. That means it *can* support anything. But it doesn't always mean that it *does* feature everything. Take the Ethereum L1 account abstraction proposal "Frames", that is slotted in for the Q2-Q3 2027 upgrade Hegotá. It supports keystores, it supports passkeys, it supports post-quantum leanSPHINCS signature, and yes it also supports lattices. It supports, to put a spin on the New York Times's motto, all the features that's fit to run. Does it mean that all of these functions will feel like first-class citizens on day one? Choosing optionality means that you need to go the extra mile sometimes and maybe also build most or all of the things, in order to make the cost of that optionality bearable for applications and tooling, and to align with standards that improve the life of users. Same story with MEV-resistance, same thing with delegated proof-of-stake, same thing with interop, same thing with compliance.. much of it can be built on top of the fairly open Ethereum core, either as apps or infra or L2s (tbqh the three sometimes blur in productive ways, if they're really working hard to extend what Ethereum the protocol can do). I'm happy that we're trending as an ecosystem towards being more intentional with this, and hope @ethlabs_org continues to play a role here. Mislav @ox_shaman is hard at work kicking off an effort for Frames, to prevent the fragmentation and lost opportunity that lessened 7702's impact when it launched, collaborating with EF and more key teams in the ecosystem. You should reach out to him if you haven't yet.