Validity Transactions are coming to Base in the upcoming Cobalt upgrade later this month Essentially, they let you specify "predicates" - certain onchain criteria that must be met for your transaction to be included in a block. Transactions whose predicates don't get met just expire instead of reverting and wasting gas fees onchain What will you build? 👀️

Stupid social is an app that gives you the best of online social without the doomscrolling After almost 5 months in TestFlight it’s finally on the App Store!

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.