Account abstraction and better Web3 wallets

By Marco Lopes · November 23, 2023 · Blockchain & Web3

We have spent years asking people to adapt to blockchain wallets: write down a seed phrase, buy the right network token, switch chains, approve a contract, and sign something that may be difficult to understand. Each step makes sense somewhere in the infrastructure. Together, they make a poor introduction to a product.

At Kordspace, we approach this as both an engineering and a design problem. As a remote studio working across software, AI, Web3, hardware, and design, we want the underlying technology to support the experience, not dictate every screen.

Account abstraction gives us a useful foundation for that work. It does not remove blockchain complexity or guarantee safety. It lets us move more account behavior into programmable contracts, where we can build better authorization, recovery, and transaction flows.

What account abstraction actually changes

On Ethereum, the familiar externally owned account, or EOA, is controlled by a private key. That key authorizes transactions, and the account generally needs ETH to pay transaction fees. Losing the key can mean losing access; exposing it can mean losing assets.

A smart contract account can define more flexible rules. Instead of treating one signature from one key as the entire authorization model, we can require multiple signers, introduce recovery procedures, or grant narrowly scoped permissions.

Smart contract wallets already exist. Account abstraction is not their invention, and it is not one single feature. It is the broader effort to make programmable accounts work more naturally as user accounts.

For product teams, we find the clearest framing is this: account abstraction lets us design how an account behaves, rather than accepting the limitations of a single-key wallet as fixed requirements.

Why ERC-4337 matters in November 2023

ERC-4337 provides a practical route to account abstraction without requiring changes to Ethereum's consensus rules. Its supporting infrastructure is live, but we still treat tooling, interoperability, and provider coverage as evolving.

The central pieces are:

• UserOperation: a structured request describing an action the smart account wants to perform.
• Bundler: infrastructure that receives operations, checks them, and submits them through an ordinary blockchain transaction.
• EntryPoint: the contract that coordinates operation validation and execution.
• Paymaster: an optional contract that can sponsor an operation's gas under defined conditions.

The account contract decides whether an operation is authorized. A bundler submits it to the EntryPoint, which handles validation, execution, and gas accounting. The required funds come from the account or an accepted paymaster arrangement.

This does not make transactions free. It changes how they are authorized and how their costs can be funded.

Start with a user problem, not a wallet feature

We would not adopt account abstraction simply to put “smart wallet” on a roadmap. We would identify the friction that prevents someone from completing a useful action.

For a membership product, that might be requiring a new member to acquire a network token before claiming access. For a collaborative application, it might be repeatedly requesting wallet signatures for low-risk interactions. For a team treasury, it might be relying on one person's key.

Those are different problems and deserve different account policies.

We usually begin by mapping onboarding, first value, repeat use, device loss, and account exit. We then ask which steps genuinely need an on-chain action, which can remain ordinary application behavior, and which permissions the wallet requires.

The best improvement may be fewer blockchain interactions, not a more elaborate wallet.

Build onboarding around access and recovery

Account abstraction can support an experience where people create an account before dealing directly with gas or deployment. With an appropriate factory and deterministic deployment scheme, we can calculate a smart account address before deploying its contract, then deploy it when needed.

We must still explain what controls that account. An email login does not automatically mean self-custody, and a familiar interface does not tell us who can replace a signer or recover access.

We document the complete control model: device-held keys, service-held permissions, recovery contacts, upgrade authorities, and any third-party dependencies.

Recovery deserves its own product flow. Guardian approval, a second device, or a delayed signer change can help, but each introduces trade-offs. We favor visible notifications, cancellation opportunities, and clear waiting periods where the account design supports them.

We also test the uncomfortable case: can someone recover or move assets if our application is unavailable?

Treat passkeys as an implementation choice

Passkeys are attractive because they can replace unfamiliar key handling with authentication people recognize from their devices. But we should not confuse a pleasant authentication gesture with a complete wallet security architecture.

Common WebAuthn credentials use the P-256 curve, while Ethereum's familiar signature recovery path uses secp256k1. As of this date, efficient P-256 verification is not something we can assume across EVM networks. We need to examine the target chain, contract verifier, gas cost, and any intermediary signing arrangement.

We also distinguish a passkey that directly authorizes a smart account from one that unlocks a service which signs elsewhere. These create different trust assumptions.

Before selecting an implementation, we test device replacement, credential synchronization, unsupported browsers, and recovery. “No seed phrase” is a user-interface outcome, not proof that key management has disappeared.

Use sponsorship to remove friction, not hide economics

A paymaster can let a new user perform an action without first acquiring the network's native token. That is useful when the action has clear product value and a predictable sponsorship policy.

We recommend starting narrowly: sponsor a specific onboarding action, on a specific chain, with explicit per-account and overall spending limits.

An unrestricted sponsor is an invitation to abuse. Our policy service should evaluate eligible contracts and methods, request freshness, budget availability, and relevant abuse signals. Any signed authorization should be constrained so it cannot be reused outside its intended context.

We account for failed execution and adversarial behavior in the budget model. Simulation helps, but it cannot guarantee the final outcome when chain state changes.

If users pay through an ERC-20-based arrangement, we explain conversion, approval, and pricing assumptions. The underlying network fee still exists; someone has to fund it.

Batch actions and limit repeat permissions

Batching can turn a multi-step interaction into one account operation. For example, a wallet might approve a token allowance and call an application contract within the same execution flow.

We still review the allowance amount and the account's failure behavior. Atomic rollback depends on how the batch is implemented; we do not assume every wallet handles failures identically.

Session keys can reduce repeated signing by giving another key restricted authority. We might allow calls to one game contract for a limited period, while prohibiting transfers to arbitrary recipients.

These restrictions must be enforced by the account's validation or permission logic, not just by the interface. We define allowed targets, methods, expiry, spending constraints, and revocation behavior.

A session key is delegated authority. We display it as an active permission users can inspect and revoke, rather than concealing it as a convenience setting.

Design infrastructure with explicit trust boundaries

Our preferred cloud foundation is Google Cloud, although AWS or Azure can support the same architecture. Provider choice matters less than separating responsibilities and understanding failure modes.

A practical starting point includes a client application, an RPC provider, a bundler service, a sponsorship policy API, and a transaction-status indexer. We can use Cloud Run for stateless policy endpoints, Secret Manager for service credentials, and Cloud Monitoring for operational visibility.

Those services do not automatically make user-key custody safe. If the backend can authorize account activity, we treat it as part of the custody and security model.

We keep sponsorship decisions separate from account ownership. We also avoid putting personal information in on-chain data or unnecessary identity details in logs.

For production, we assess RPC and bundler fallback options, rate limits, supported EntryPoint versions, and deployment addresses on each chain. Switching providers should not require redesigning the wallet.

Make transaction status understandable

A submitted UserOperation is not yet a completed blockchain action. It may be rejected, remain pending, be included, or fail during execution. Its hash is also distinct from the hash of the bundler's transaction.

We design a status model that preserves those distinctions without exposing every infrastructure detail. Useful states include awaiting authorization, checking sponsorship, submitted, included, and failed, with a specific next action wherever possible.

We use simulation to surface likely errors before signing, but avoid promising success. Balances, contract state, and gas conditions can change.

The confirmation screen should explain the action, assets involved, destination, permissions granted, and expected fee responsibility. If we introduce AI-generated explanations, we keep them supplementary: an interpretation must never substitute for verified transaction data or deterministic permission checks.

Clear language is part of the security boundary, not decoration.

Review the account as a security-critical product

Account abstraction moves complexity; it does not remove it. We assess account contracts, factories, paymasters, signature validation, recovery modules, and upgrade mechanisms together.

We prefer established, independently reviewed implementations over custom account logic unless the requirements justify the additional risk. Even then, an audit is not a permanent guarantee, especially after changing modules or deployment configuration.

Our testing covers replay protection, nonce handling, authorization boundaries, expired permissions, malicious inputs, and recovery conflicts. We test signatures with applications that expect contract-wallet support, including ERC-1271 where applicable.

We also verify practical compatibility. Some applications assume every wallet is an EOA, and a matching address across networks does not imply matching account state or permissions.

Finally, we document administrative powers. If an upgrade authority can change the account's rules, users should not discover that only by reading the contract.

A short launch checklist

Before a first production release, we check that:

• [ ] Ownership, recovery, and upgrade powers are documented clearly.
• [ ] The chosen account implementation and deployment configuration have been reviewed.
• [ ] Sponsorship has scoped permissions, spending limits, and an emergency stop.
• [ ] Session permissions expire and can be revoked through a tested flow.
• [ ] Pending, rejected, and failed operations have understandable recovery paths.
• [ ] Target applications, devices, and chains have been tested for compatibility.
• [ ] Users have a documented route to access or move assets without our frontend.

We would launch with one chain and a small set of account capabilities before expanding. We measure onboarding completion, failure reasons, support requests, and sponsorship costs to guide the next iteration.

Account abstraction gives us room to build wallets around people's needs instead of asking people to become infrastructure specialists. The strongest results combine conservative contract engineering, explicit trust boundaries, reliable operations, and thoughtful design. If we can help turn those principles into a product, start a project with Kordspace, or explore our related services to see how we approach Web3, software, cloud infrastructure, and design.