Moving Web3 from developer-first to user-first with Account Abstraction

Reaching the platform's core functionality required users to first work through an eight-step setup sequence derived from the Externally Owned Account (EOA) model. Those steps existed at the protocol level, not the product level, which meant they were not addressable through interface refinement alone. No amount of UI iteration would remove a step the underlying account architecture required.

This was not a shortcoming specific to this product. The EOA model underpins every EVM-compatible Web3 wallet, and the requirements it imposes are structurally legitimate at the protocol level. The seed phrase requirement is a direct consequence of non-custodial private key ownership. The user holds the key, and the seed phrase is the only recovery path available. The gas requirement is a network-level transaction cost, not a platform pricing decision. Both are technically justified, and both are completely inaccessible as concepts to a mainstream consumer whose interest is in the application, not the infrastructure beneath it.

The platform's core value proposition was broad consumer accessibility, and activation data indicated that the onboarding funnel was losing users at the credential setup step, before any of the product's functionality had been encountered. The cost of acquisition was not converting into active wallets, and the root cause was not product quality. It was the entry requirement itself. Addressing this was not an optimization exercise. It was a prerequisite for the platform's user growth and engagement targets.

Before any solution architecture was defined, the product team ran structured discovery to identify where the funnel was losing users and what the underlying pattern suggested. Activation metrics and session data pointed consistently to the credential setup phase as the primary exit point. That signal alone did not establish causation, but it provided sufficient directional evidence to investigate whether the problem was addressable at the interaction design layer or required a more fundamental intervention.

Post-activation usage data added a second dimension to the finding. Peer-to-peer transfer volume was notably lower than wallet creation volume would suggest, indicating that users who completed onboarding were not progressing to the product's core social use cases. Mapping the transfer flow surfaced the structural mismatch. The interaction required users to locate a recipient's wallet address, manage asset selection, verify gas availability, and sign the transaction cryptographically. In any conventional payment application, the mental model for a transfer is a contact and an amount. The delta between that expectation and the actual interaction requirements had a measurable effect on feature engagement.

Validating the root cause pointed to the EOA model itself. ERC-4337, the account abstraction standard deployed on the Ethereum mainnet in March 2023, was designed to address this class of problem directly. By integrating smart contract capabilities into the wallet layer, it enabled social login via existing credentials, biometric authentication, social account recovery, and sponsored transactions where the application covers gas costs on behalf of the user. The standard had already seen production adoption from major wallet providers. The discovery phase did not surface a novel solution. It validated that the solution the ecosystem had been building toward was mature enough to implement, and that the timing aligned with the platform's growth targets.

The product discovery phase produced a comprehensive view of what a full account abstraction implementation could address across the product, spanning the onboarding flow, the transfer model, transaction signing, gas management, and the shift from wallet addresses to user-linked identifiers for peer interactions. The initial specification work reflected that full scope. Before it moved forward, a phased delivery structure was established to align sequencing with both delivery capacity and business priorities. The initiative was divided into three sequential phases, with phase one scoped to the onboarding flow. Delivering the highest-impact change to the activation funnel first, while establishing the infrastructure layer the subsequent phases would build on, was the right structure for this stage of the initiative.

The more demanding decision was whether to build the account abstraction layer natively or integrate with a specialized provider. Native development would have given the team full architectural control and eliminated external dependencies. It would also have required an engineering investment difficult to justify when purpose-built infrastructure providers had already reached production maturity. Web3Auth, Privy, Dynamic, Turnkey, and other providers shown in the 'Account Abstraction Landscape' infographic below, offered account abstraction infrastructure already in production use across the market. A critical dimension of the evaluation was the pricing model itself. Account abstraction providers charge on a per-user account basis rather than a flat integration fee, which made the cost structure a variable tied directly to user growth. Finance was brought into the process to model projected LTV per user against each provider's per-user rate across multiple growth scenarios, producing a product P&L that could determine whether the integration remained commercially viable as the platform scaled. The evaluation also covered integration complexity, commercial terms and contractual flexibility, ongoing engineering support capacity and SLA commitments, and security architecture. Security received the most scrutiny, specifically how each provider handled key sharding, the distributed custody model, and the attack surface introduced by the integration. Business development ran this process in parallel with product and engineering, given that the decision carried commercial implications the technical teams alone could not fully assess. Arriving at a recommendation required active coordination across product, engineering, legal, and finance, each contributing a dimension of the evaluation the others could not cover.

The design work began with a task-level audit of the onboarding sequence, identifying which steps served the user directly and which existed solely to satisfy the protocol. Every step in the second category was a candidate for abstraction.

One product decision required deliberate handling alongside the onboarding redesign. Under the EOA model, the user holds a single private key directly, with the seed phrase as the sole recovery mechanism. Account abstraction manages key security through distributed cryptographic methods, where the private key is sharded across multiple parties so that no single party, including the infrastructure provider, holds the complete key. The user retains ownership of the wallet and assets throughout, preserving the non-custodial principle. For a segment of the user base, however, the change is architectural rather than custodial. Moving from holding a single unambiguous private key to participating in a sharded key model is a meaningful shift in how that user relates to their own wallet, and some users in the Web3 community have a strong preference for the former. The product decision was to preserve the advanced manual setup path as a secondary option, accessible to users who required it without being surfaced as the default. The primary onboarding flow was designed for the broad consumer audience the platform was trying to activate. The secondary path maintained coverage for users whose requirements it better served, without shaping a flow the majority of new users would never need.

An initiative of this scope produces decisions that none of the contributing teams can make independently. Product owns the problem definition, the PM owns the specification, the design team owns the interaction model, engineering owns implementation feasibility, and business development owns the commercial framework. Running those workstreams sequentially would have extended the timeline significantly and allowed decisions made in one area to go unexamined by the teams most affected by them. The structure was parallel workstreams with defined dependency gates connecting them.

The product team led discovery and synthesis. Findings were reviewed and discussed across the leadership group before any specification work began, as the scope boundaries and phase structure depended on the combined picture of activation data, technical constraints, and business goals. From that review, the PM drafted the PRD. The initial version covered the full account abstraction implementation. The first revision divided it into three sequenced phases, each specified to a depth appropriate to its delivery timeline, so that engineering engagement could be scoped to phase one without carrying the complexity of the full rollout. Phase one was reviewed with the design team before engineering engagement began, so that the UX implications of the technical decisions were resolved at the specification stage. Working from the PRD and the research synthesis simultaneously, the design team produced mockups for the updated onboarding flow. The approved design was then structured into a JIRA epic with scoped, sequenced requirements for engineering.

Business development ran the vendor evaluation across this entire period. Security served as the primary evaluation axis, specifically the key sharding approach, the distributed custody architecture, and the attack surface each provider introduced, given the platform's non-custodial positioning. Commercial terms, per-user pricing at scale, integration complexity, and ongoing support capacity were assessed in parallel. The goal was to arrive at a partnership recommendation that aligned with the PRD timeline, so that engineering could begin phase one with a confirmed infrastructure layer rather than a provisional one.

The pre-development phase was completed across all workstreams. Deliverables included a structured discovery synthesis covering activation funnel analysis and post-activation usage pattern research, a three-phase PRD with the first phase specified to developer-ready detail, a vendor evaluation across multiple account abstraction infrastructure providers with a recommendation grounded in security, commercial, and integration criteria, and a complete set of onboarding mockups aligned to the updated interaction model. The initiative established the product architecture, the partnership framework, and the design specification required for engineering to begin development.