--- robots: noindex, nofollow --- # SmartCustody for Ethereum with Account Abstraction ###### Tags: `article / updated 2025` This proposal offers a methodology for adopting Blockchain Commons' SmartCustody principles to improve the resilience, modularity, and security of Ethereum wallets through the use of **Account Abstraction (ERC-4337)** and other Ethereum-native features. ## Problem Statement Ethereum accounts are traditionally controlled by a single private key. They come in two types: * **EOAs (Externally Owned Accounts)** use key pairs: the address is derived from a public key, and the private key controls access. EOAs are still the most common. * **Contract Accounts** are controlled by smart contracts, which can include logic for authorization, recovery, and delegation. They are indistinguishable in address format from EOAs. The traditional model presents critical security challenges: * A **Single Point of Failure** (loss of the private key). * A **Single Point of Compromise** (if the key is stolen, all assets and access are lost). * Lack of separation between roles: signing into apps, holding NFTs, executing contract logic, and controlling assets often share a single key. These are textbook examples of **Ambient Authority**: where access permissions are overly broad and undifferentiated. While Ethereum has introduced *Account Abstraction* (AA) to move beyond these limitations, most wallets and dApps have not yet embraced meaningful separation of keys or proof purposes. This proposal defines a framework for **partitioned authority and recoverable key management**, enabling modular design, permissioned roles, and robust recovery for Ethereum wallets. It also recognizes the value of **pragmatic interoperability with legacy Ethereum wallets**, proposing an initial survey to identify existing capabilities and adoption blockers. ## Account Abstraction: Enabling Secure Partitioning **ERC-4337** enables users to operate smart contract wallets with customizable logic for verification and execution. This is a foundational shift: * It supports **multiple signers** with different roles. * It allows programmable recovery, rotation, and revocation. * It moves Ethereum away from rigid EOA dependency. SmartCustody builds on these foundations by proposing a structured framework of **Proof Purposes**: 1. **Single Sign-On** (Web3 login auth) 2. **Asset Holding** (ETH & ERC-20 transfers) 3. **NFT Management** (ERC-721/1155 operations) 4. **Smart Contract Control** (deployment and execution) 5. **Social or Emergency Recovery** (optional) Each purpose should be assigned to a distinct key pair or signer slot, with smart contract logic validating their scope. > This creates enforceable separation, better resilience, and more predictable failure modes. ## Wallet Design Modern Ethereum wallets must: * Support **multi-signer ERC-4337 wallets**. * Maintain metadata for each key (e.g., proof purpose, creation date, shard index). * Integrate **key derivation hierarchies**, using `xpub`/`xprv` principles. * Allow **airgapped** seed/key provisioning using QR-encoded Uniform Resources. * Support **offline signing** and **minimal online attack surface**. Where possible, wallets should: * Never store the master seed directly. * Allow provisioning of key material via QR codes using **Blockchain Commons' Uniform Resources**. * Support **SSKR** (Sharded Secret Key Reconstruction) for seed protection. ## WalletConnect Design WalletConnect already separates the app interface from signing logic. This is a perfect channel to: * Introduce **xpub-derived keys** per dApp or per session. * Use **proof-purpose scoped authorization**, enforced by AA wallet logic. * Interface with **recovery flows** managed via CSR (Collaborative Seed Recovery). We propose: * Support for **WalletConnect + ERC-4337 bundler relaying**. * Key registration via airgapped scanning (SeedTool + WalletConnect). * Compatibility testing with WalletConnect 3 for Ethereum-native multi-account UX. ## Development Path We propose the following staged roadmap: 1. **Conduct Ethereum Wallet Survey** * Evaluate legacy and current Ethereum wallets for interoperability potential * Record supported features, signing models, and recovery methods * Identify opportunities for backward-compatible proof purpose integration * Host at least two developer-focused meetings to present findings and collect feedback, following the model of our successful FROST coordination process 2. **Define Proof Purpose Templates** * For SSO, NFTs, Assets, Contracts * Draft JSON/YAML schema with clear role definitions and usage boundaries 3. **Develop a prototype ERC-4337 SmartCustody wallet** * Polygon as testbed * Uses purpose-specific key slots 4. **Enhance SeedTool** * Integrate WalletConnect 2 * Provision xpub/xprv with proof-purpose metadata 5. **Enable NFT support** * Test ERC-721/1155 with purpose-restricted signer slots 6. **Collaborate on WalletConnect 3 integration** * Multi-session, multi-proof-purpose compatibility 7. **Integrate Smart Recovery** * CSR servers store SSKR Envelopes for lost-device recovery * Build WalletConnect-compatible recovery UX ## SmartCustody Recovery Stack **Blockchain Commons tools for Ethereum AA wallets:** * **SSKR**: Secure, resilient sharding of seed material * **Envelope**: Cryptographic document container supporting encryption, elision, and multi-asset bundles * **CSR**: Server-based collaborative seed recovery using encrypted shards * **GSTP**: Secure transport protocol over insecure channels (e.g., QR, BLE) ## Potential Challenges 1. **Backwards Compatibility** * May need a fallback signer (0th child) for legacy contract interaction. 2. **ERC-721/1155 UX** * Require support for separate payment vs. holder addresses. 3. **Key Derivation Standards** * BIP32/BIP44 + SLIP44 support on Ethereum is limited; hardened paths must be used cautiously. 4. **Non-Ethereum Curve Support** * BIP32 methods are incompatible with ed25519; possible limitation for L2s or cross-chain wallets. ## Future Development Ethereum's smart account ecosystem is growing rapidly. With SmartCustody: * Developers gain templates and libraries for safer key management. * Users get structured recovery paths and protection from ambient authority. * Wallet developers get tools for enforceable modular security. **Our next steps:** * Extend Wallet Interchange Format to Ethereum * Publish Proof Purpose schemas * Offer open-source SmartCustody wallet templates * Host Ethereum-focused Silicon Salons for AA wallet builders and signer ecosystem stakeholders ## Conclusion SmartCustody brings years of Bitcoin resilience research to Ethereum's new account paradigm. Through proof-purpose partitioning, enforceable modular authority, robust seed recovery, and coordinated developer adoption, we can help the Ethereum ecosystem build wallets that are resilient, interoperable, and secure by design. ==== # 📚 Key Readings on ERC-4337 Smart Account Adoption & Retention (2024–2025) Below is a curated list of recent reports and analyses that examine the adoption, usage patterns, and infrastructure maturity of ERC-4337 smart accounts. These resources are critical for understanding the systemic challenges Ethereum faces with account abstraction—and for positioning Blockchain Commons’ work within that context. ### 1. Safe & BundleBear – _“Onchain Retention for Smart Accounts”_ (March 2024) https://safe.global/blog/onchain-retention-for-smart-accounts An in-depth analysis showing that ERC-4337 smart accounts suffer from very low retention. Accounts older than five weeks often drop to just 1% weekly activity. Average smart accounts execute only five user operations. Highlights the urgent need for better onboarding and user recovery flows. ### 2. 2077 Research – _“ERC-4337 Two Years After Launch: Expansion and Challenges of Account Abstraction”_ (March 2025) https://www.eblockmedia.com/news/articleView.html?idxno=15617 A comprehensive two-year review of ERC-4337 adoption. Reports 24+ million smart accounts created but low average usage per account. The report flags interoperability issues and the lack of standardized tooling for recovery, backup, and signer management. ### 3. Publish0x – _“ERC-4337 in 2024 Review”_ (January 2025) https://www.publish0x.com/etherspot/erc-4337-in-2024-review-openzk-s-l2-launch-arcana-s-chain-ab-xevwyzp BundleBear’s year-end summary: over 103 million user operations in 2024, but only 4.3 million accounts performed more than one operation. Reinforces the pattern of high churn and low re-engagement for smart account wallets. ### 4. The BlockBeats – _“200 Million Gasless Transactions in One Month, Is Account Abstraction a Success?”_ (April 2025) https://www.theblockbeats.info/en/news/57418 Highlights a surge in gasless transactions via paymasters, hitting 200 million in a month. Despite the volume, user retention remains low. The article questions whether account abstraction’s usability gains translate into long-term ecosystem engagement. ### 5. Bitcoinke – _“State of Wallets 2025”_ (May 2025) https://bitcoinke.io/2025/05/state-of-wallets-2025/ Covers the growing presence of ERC-4337 wallets, which have begun to outpace EOAs monthly. However, it flags that many smart accounts are created for incentives and are quickly abandoned. Points to a pressing need for meaningful recovery and user value post-onboarding. ### 6. Alchemy – _“Smart Accounts Adoption Accelerated in Q4 2023”_ (January 2024) https://www.alchemy.com/blog/smart-accounts-adoption-accelerated-in-q4-2023 Reports nearly one million new ERC-4337 smart accounts created in Q4 2023. Still, the average account sees only five user operations, reinforcing the theme of shallow usage. Highlights bundler challenges and incomplete tooling. ### 7. Cointelegraph – _“New Figures Show Hardly Anyone Is Using ERC-4337 Smart Accounts”_ (November 2023) https://cointelegraph.com/news/hardly-anyone-using-ethereum-smart-accounts A critical early overview of ERC-4337’s rollout. Notes the heavy dominance of EOAs, slow dApp support, and lack of compelling recovery UX as primary blockers to smart account growth. ### 8. Crypto Pulpit – _“The Slow Adoption of ERC-4337 Accounts”_ (November 2023) https://cryptopulpit.com/the-slow-adoption-of-erc-4337-accounts/ Emphasizes low activity across ERC-4337 accounts, bundler profitability concerns, and gaps in recovery models. Useful for understanding the developer-side friction. ### 9. Gelato – _“Gelato’s Guide to Account Abstraction: from ERC-4337 to EIP-7702”_ (April 2025) https://www.gelato.network/blog/gelato-s-guide-to-account-abstraction-from-erc-4337-to-eip-7702 Analyzes the shortcomings of ERC-4337 and introduces EIP-7702 as a potential improvement path. Frames 4337 as a valuable stepping stone but limited by complexity and dApp incompatibility. ### 10. Codezeros – _“Web3 Wallet Development in 2025: Why You Should Consider Account Abstraction”_ (March 2025) https://www.codezeros.com/web3-wallet-development-in-2025-why-you-should-consider-account-abstraction Optimistic outlook on the future of AA wallets. Projects ERC-4337’s successor technologies (like EIP-7702) as catalysts for smart account dominance by 2027. Suggests the need for better UX and recovery tooling now to prepare for broader adoption. === ## Exploratory Brief: Addressing ERC-4337’s Retention Crisis with Resilient Recovery & Signer Infrastructure **From**: Christopher Allen, Principal Architect, Blockchain Commons **To**: Ethereum Foundation / Wallet & Account Abstraction Teams **Date**: July 2025 **Funding Goal**: Pilot collaboration to address critical gaps in Ethereum smart account lifecycle—retention, signer provisioning, and recovery—with open, modular tooling --- ## Introduction ERC-4337 was launched to unlock powerful new wallet capabilities—gas abstraction, programmable permissions, and smart recovery—but after two years, the ecosystem is facing a quiet crisis: 📉 **Retention is dangerously low.** Recent studies show that: - Fewer than **7% of ERC-4337 smart accounts** remain active after five weeks (Safe & BundleBear, 2024–2025) - Most accounts execute only **five user operations**, often during initial dApp onboarding - Airdrop-driven wallet creation results in high churn and **abandoned signer state** This suggests a growing divide between **ERC-4337’s theoretical capabilities** and **real-world wallet lifecycle UX**—particularly around secure provisioning, role management, and recovery. **Blockchain Commons**, a *not-for-profit public benefit organization*, has spent the past five years designing open-source tools and specifications for **resilient key management, signer metadata, and interoperable recovery**—primarily in UTXO-based ecosystems like Bitcoin and Zcash. We now propose to bring that experience into the Ethereum smart account context—*not as a retrofit*, but as a collaborative investigation into the failures ERC-4337 data has surfaced. --- ## What We’re Responding To > “Account abstraction lowers the entry barrier—but doesn’t solve for re-engagement, safety, or long-term control.” > — _ERC-4337 Year 2 Review, 2077 Research_ The problem isn’t just technical. It’s lifecycle-level: - 🔐 **Weak signer provisioning**: Smart accounts are often generated on the fly, with little or no structured metadata, backup instructions, or trust modeling. - đŸš« **No standard recovery format**: Social recovery is theoretically supported, but toolchains for shard distribution, metadata protection, or threshold recovery are largely unimplemented. - 🔄 **No structured signer metadata**: dApps don’t record how or why a smart account was created, and wallets rarely encode roles or scopes for key material. - đŸ’„ **Lifecycle fragmentation**: Most accounts are created, used once, and forgotten—making continuity, reactivation, and recovery extremely difficult. These are the same failure modes we've solved in other contexts—with production-tested formats for **proof-purpose separation**, **airgapped provisioning**, and **multi-party recovery**. --- ## What We Propose to Explore We’re not proposing a new wallet. Instead, we offer a focused collaboration to test and adapt modular tools that may help resolve known lifecycle gaps in Ethereum smart accounts. We propose to explore the following areas with Ethereum-native developers: ### 1. **Signer Metadata with Envelope** Can [Envelope](https://github.com/BlockchainCommons/Envelope)—our structured cryptographic container—help encode: - Signer roles (e.g., login, NFT control, gas delegation)? - Backup instructions? - Derivation paths and audit trails? This would support portable signer context without dictating smart account architecture. ### 2. **Recovery UX with SSKR and CSR** Could [SSKR](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-sskr.md) (Sharded Secret Key Reconstruction) and CSR (Collaborative Seed Recovery) offer: - Threshold-based shard distribution with dApp-controlled UX? - Optional use of decentralized storage (CSR servers)? - A path to Ethereum-native social recovery that avoids trusted custodians? ### 3. **Provisioning via Uniform Resources (UR)** Could [URs](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-ur.md) (animated QRs) support: - Offline signer provisioning via WalletConnect or QR flows? - Shard delivery, xpub transfer, or metadata migration in airgapped flows? - Integration into mobile dApp onboarding? UR is already used in 13+ Bitcoin and Zcash wallets for PSBT signing and seed import/export. ### 4. **Proof Purpose Mapping** Can we test **role-scoped key separation** (proof purposes) within ERC-4337 wallets? - Separate keys for login auth, asset control, smart contract deployment - Better modularity and recovery semantics - UX guardrails against ambient authority This mirrors best practices we’ve deployed in UTXO wallets—and could serve as a foundation for Ethereum-native lifecycle discipline. --- ## Phase 1 Proposal (3–6 Months) ### đŸ§Ș Pilot Collaborations With 1–2 Ethereum wallet teams (e.g., Safe, Zerodev, Biconomy), we’ll prototype: - Envelope-signed signer metadata records - SSKR backup flows for smart account signer material - WalletConnect-compatible UR flows for secure signer provisioning ### 📊 Smart Account Recovery Audit A short report analyzing how Ethereum wallets handle: - Key backup and recovery - Role metadata and signer scope - Failure modes (e.g., deleted app, lost device, stale signer) This will include interviews with wallet developers and user-facing teams. ### đŸ§‘â€đŸ€â€đŸ§‘ Ethereum Silicon Salon We’ll convene a working group to discuss: - Recovery UX fragmentation - Open tooling opportunities - Minimum viable standards for signer metadata, recovery hints, and cross-wallet restoration Blockchain Commons has previously coordinated open standards salons for FROST and cryptographic hardware. ### 📂 Open Source Deliverables - Reference Envelope schemas for signer metadata and backup scope - WalletConnect-compatible UR provisioning stubs - SSKR + CSR demo integrations - Interchange-format draft for smart account signer data - Public findings on ERC-4337 retention and recovery gaps --- ## Why Blockchain Commons? We are not offering a wallet. We’re offering **battle-tested, audited tooling** for decentralized signer safety: | Capability | Our Tool | Production Usage | |----------------------------|-----------------------------------|------------------------------| | Threshold recovery | SSKR | Foundation Devices, SeedTool | | Metadata encoding | Envelope | Zcash Wallet Interchange | | Offline provisioning | UR / QR stack | 13+ wallets across UTXO | | Shard storage (optional) | CSR | In pilot (Zcash) | We’re a **not-for-profit benefit organization**, operating transparently, independently, and focused on public-good tooling for resilient, user-controlled security. All of our tools are open source and MIT-licensed. We’ve convened successful **cross-vendor cryptographic coordination** efforts, and we are well-positioned to support Ethereum’s smart account evolution—not by replacing what's working, but by helping fix what’s silently failing. --- ## Funding Request We are requesting Ethereum Foundation support to: - Fund core engineering for adapting Envelope, SSKR, and UR to Ethereum-specific flows - Facilitate developer pilots and collaborative workshops - Deliver documentation and schemas for Ethereum-native recovery standards - Publish a public-good report mapping signer lifecycle design gaps We’re open to co-creating milestones, co-authoring public outputs, and aligning this work with broader Ethereum security and UX initiatives. --- ## Closing Thought ERC-4337 has proven that modular wallets *can* work. What remains unsolved is how to make them **resilient, recoverable, and user-owned** across their full lifecycle. That’s where we specialize. We welcome the opportunity to collaborate—through code, conversation, and co-design. **Christopher Allen** Principal Architect, Blockchain Commons 📧 christophera@lifewithalacrity.com 🌐 https://www.blockchaincommons.com 📂 https://developer.blockchaincommons.com