The Future of Self-Custody Wallets: Moving Trust Beyond the UI

Building self-custodial wallets has historically forced developers to make painful trade-offs between security, convenience, and decentralization. These compromises become especially acute when moving beyond single private key implementations. At Safe Research, we believe these trade-offs can be eliminated through a fundamental architectural shift. Traditional wallet designs center around a centralized UI layer. Our new paradigm places the transaction queue at the core of the wallet stack, enabling a modular architecture that maintains privacy, supports complex authorization schemes, and preserves decentralization.

The Problem

Today’s wallet landscape splits along two imperfect lines. Standard Externally Owned Accounts (EOAs) are simple to grasp but inflexible, because everything depends on one private key. Smart accounts unlock richer access control, yet most existing wallets hide that power behind centralized UIs and ad‑hoc infrastructure due to slow adoption of smart account standards and lagging smart account support in many onchain protocols. The result is a user experience in which convenience always subtracts from either security or decentralization. As the Safe Research Manifesto argues, self‑custody should not be a zero-sum game, but a continuum: configurable, secure, and interoperable.

A Component‑Based View of Wallets

A modern wallet is best understood as a set of cooperating roles rather than one monolithic app. Here is a conceptual overview. Some of these components can be implemented as part of each other, as shown further down below.

Wallet UI

The interface is what users see and trust. It displays balances, pending and past transactions, and usually initiates signing. A large share of perceived security and trust still lives in Wallet UIs such such as Safe Wallet. The reason is that users naturally don’t consider the different underlying components of a system’s architecture but rather assume that there is only a single component, namely the one they are directly interacting with.

Signers

Signers produce cryptographic signatures. They can be hardware devices such as Trezor or Ledger, passkeys, software signers typically implemented as browser extension or mobile app, and even other smart accounts such as Safe. Every signer ultimately needs its own user interface. This can be on‑device, integrated into the main wallet, or delivered via a companion app. It is important to note that browser extensions like MetaMask or Rabby fit both into the category of a Wallet UI as well as a signer due to their built-in software signer.

Cosigners

Beyond the primary signer, additional parties may be required to authorize a transaction in multisig or threshold setups. These cosigners are often people or services with higher technical sophistication. They provide another line of defense by detecting mistakes before they reach the chain. The term cosigner only fits when actual approving/signing happens. In case no onchain signing is happening, a name such as security alert is more suitable.

Transaction Queue

We treat the queue as the wallet’s message bus: a private, standardized log of proposed transactions awaiting signatures and execution. In software wallets focused on EOAs such as MetaMask this function lives inside the Wallet UI. The same is true for companion apps for hardware wallets such as Ledger Live. Smart accounts enable the queue to live truly outside Wallet UI. In today’s Safe infrastructure this function lives inside the transaction service. In other smart account frameworks such as Coinbase’s Smart Wallet the function of a queue is provided by the mempool of a ERC-4337 bundler.

Transaction History

Executed transactions must be displayed and verified, but the transaction history does not need strict coupling to the queue. Safe again relies on its transaction service.

Dapps

While wallets represent the actual sovereign identities of users and hold assets, dapps are applications users intend to use. There are various types of dapps including decentralized finance (defi), collectible marketplaces, gaming, social media, and governance. Dapps initiate transactions triggered by users. They typically connect through injected providers or via WalletConnect.

Relayers

Relayers take pre‑authorized transactions, which are ready to be executed and push them onchain, abstracting gas, batching calls, or scheduling future execution.

EOAs: Where We Stand

An EOA‑based wallet revolves around its UI. Every action funnels through the interface and the single private key it controls. This excludes EOAs that have been extended via EIP-7702.

UI as the center-piece of a typical EOA wallets.

The notion of transaction queue and cosigners can exist as well, however, not independent of the Wallet UI. Before signing a transaction, it is merely raw transaction data that needs to be carefully examined. After signing, it can be executed right away without the need to wait for further authorization. There is no need for an EOA wallet to employ a separate queue component outside of the UI. Most EOAs send the signed transaction to the mempool directly via a RPC request, circumventing any relayer. With the single private key of most EOAs, real signing via a cryptographic confirmation is impossible. Hence the term “cosigner” is not ideal and security alerts is a more suitable term. These are typically implemented via offchain services such as Blockaid or Hypernative which examine transaction data before signing and alert users of potential risks.

Here it is worth mentioning the concept of threshold signatures which falls into the category of EOAs. In threshold signature schemes, there is typically no single private key but multiple ones. Notable examples are Shamir’s secret sharing and multi-party computation (MPC). While the former has not gained widespread adoption in wallets, there are a number of MPC-based wallet providers such as Fireblocks. The latter typically employs proprietary encryption technology.

In EOA wallets, the Transaction Queue is deeply integrated into the Wallet UI. Transaction checks are possible via Security alerts, but not via actual Cosigners.

From a decentralization perspective, most EOA wallets pass the “walkaway test”: if your team and servers disappear tomorrow, will your application still be usable? Standards such as BIP-39 and BIP-44 allow users to migrate to different EOA wallet providers. Proprietary tech such as closed-source MPC wallets do not pass this test.

Smart Accounts: Status Quo and the Road Ahead

Smart Accounts already support modular extensions, transaction batching, transaction sponsoring, and various access control schemes such as daily limit or multisig. Examples include Ambire, Avocado, Biconomy Smart Account, Coinbase Smart Wallet, Ready (formerly Argent), ZeroDev Smart Account, and Safe. Most wallet implementations however still keep the Wallet UI at the center. Safe Wallet for instance is no exception to this approach. Alternative UIs are possible, but have not been adopted yet due to the Wallet UI being the center piece of most architectures and the dependency on bespoke coordination which adds complexity.

One reason for this is that many protocols are still designed with primarily EOAs is mind since they represent the biggest share in terms of number of users. The lack of standardization for newer primitives results in bigger UX challenges for smart account wallets such as message signing, cross chain interactions, and bridging.

In terms of decentralization, many smart accounts do not pass the walkaway test. And those that pass, only do so for tech-savvy users at the moment. This has to change in order to build an actual self-custodial wallet.

As one key advantage of SAs, components such as the transaction queue, history, relayers and cosigners can be built truly separate from the Wallet UI. For instance in a multisig setup there are separate signers which could use separate signer UIs. Transactions await further confirmations in the transaction queue. Actual cosigning is possible, ie. cosigners can cryptographically confirm transactions onchain instead of just relying on offchain signaling.

All of the above includes smart accounts but also EOAs that have been extended via EIP-7702.

Wallet UI as coordinating piece between other components.

Future Vision: A Queue‑Centric Design

Our vision leverages the advantages and rearranges dependencies. The transaction queue becomes the hub; signers, cosigners, relayers, and other modularized components talk to the queue directly, while the Wallet UI becomes more interchangeable. By shifting gravity away from the interface we unlock richer authorization flows and enable work on stronger privacy without adding central points of failure.

Transaction queue as central component of a better smart account architecture

Signing threshold and relation to ERC-4337: Smart account wallets support a wide range of access control schemes. A popular one is the m-out-of-n scheme where n is the total number of existing signers and m the number of signers that need to approve a transactions before it can get executed (”threshold”). For m>1, a transaction queue is the natural place to collect and record transaction data as well as signatures. For m=1, the transaction queue could only be a place to collect transaction data for inspection which is not a strong advantage. For signed transactions, it would be very similar to the mempools of ERC-4337. Similar to our notion of a queue, ERC-4337 bundlers employ a mempool of UserOperations. These UserOperations are transactions fully ready to relay and execute. The ERC-4337 architecture is not designed to capture more complex transaction lifecycles natively. Examples for this are more complex access control schemes such as multisig with m>1 or advanced cosigner setups where there is no direct communication upfront before submitting the transaction. For smart accounts with m=1 that focus more on features such as transaction batching and sponsoring, the ERC-4337 mempool is a suitable solution and a more advanced transaction queue would only add small advantages. While prevalent today, we see a likelihood that in the future a threshold of 1 will only be used for session keys or low risk transactions. Anything beyond that will rely on the reassurance of cosigners.

Independent of access control schema or threshold, a true self-custody wallet needs to allow for user privacy. Thus a well‑designed transaction queue allows to choose between private and public modes. It is not wise to force encryption and privacy on everyone since that would force users to provide privacy also for bad actors. A public transaction queue allows for public inspection. On the flipside, not all transactions should be public though due to downsides such as exposing your entire onchain life and exposure to Maximal Extractable Value (MEV). Desired privacy is a spectrum though. When looking at the trade offs, there are several similarities to Ethereum mempools. By default they are public, however private mempools have emerged. There is also work on encrypted mempools. Similarly, we also envision a wide range of different transaction queue types depending on user needs. There needs to be a standard interface so any signer or cosigner can participate. It remains lightweight, replaceable, and may even be ephemeral, yet it guarantees consistency for each transaction’s life‑cycle. Access control, i.e. who may add new transactions and whether they can be trusted, relies on the already existing authentication infrastructure of the respective SA.

Safe Research’s Harbour project is an early step toward that specification. It currently only supports a public transaction queue.

The queue is the natural place to decentralize and modularize wallet interactions - more so than Wallet UI or signing infrastructure.

Impact on other Wallet Components

Transaction history can be replicated across multiple indexers for resilience and verifiability, independent of the queue. Privacy is less of a challenge since indexers typically index public data from the blockchain.

Dapps can communicate directly with the transaction queue to propose transactions to sign. There is no need to communicate via the Wallet UI anymore. This makes it valuable also for other smart account setups such as those with threshold 1. It also enables privacy preserving communication between dapp and wallet. Dapp connections can slowly move from injected providers towards wallet‑agnostic protocols. The challenge is to keep them permissionless. We will be exploring one‑way, privacy‑preserving links such as the proposed ERC‑1043 “UWULink”.

Relayers decouple gas management from key custody, but we still need open marketplaces so users can choose or switch providers, independent of the Wallet UI used. ERC-4337 and related ERCs such as ERC-7677 have laid a great foundation for relayers to join a network that separates accounts from execution, such as there is almost no coupling. This is superior to other bespoke relaying systems which rely on specific properties of the transactions they are relaying, or some amount of trust in the relayer. Developing this further, public decentralized queues could be built where wallets push transactions to. Bundlers pull for it and compete on execution.

Cosigners benefit from running outside the user’s device, adding objective checks without compromising keys. Users benefit from knowledgeable, sophisticated, and automated transaction checking systems. Users can still overwrite if they have to. For temporary sessions or low risk transactions, cosigner requirements could be lifted. The best configuration depends on the exact use case.

Wallet UIs can become much simpler and lightweight. Most of the users perceived trust will likely still be on the UI. However once the queue orchestrates state, replacing the UI becomes a UI/UX choice, not a security risk. UIs on IPFS or other content‑addressed networks become more likely.

Transaction Flow (End-to-End)

There are several steps required to execute a transaction. Each of these steps requires a subset of the components above. Each step has their own usability, security, and privacy challenges.

Simplified overview of steps required to execute transaction via Smart Accounts.

1. User opens Wallet UI to view balances, transaction history, and pending transactions in order to get an overview of the current state of their Wallet. Information needs to be up to date in order to built up trust.

2. User opens dapp to send assets, use defi, etc.

3. Dapp proposes a transaction, which gets pushed to the transaction queue directly from the dapp or via the Wallet UI.

4. Signing

   1. User signs transaction with all required signers and signatures end up in the transaction queue.

   2. Cosigners sign transactions independent from the user after in-depth inspection.

5. Relayer executes the finalized transaction.

6. Wallet UI and DApp reflect the state update from the blockchain.

Conclusion

True self‑custody wallets need to be modular and private. Key components need to be as lightweight as possible and standardized in order to allow for decentralization. By pivoting around an open, queue‑centric architecture we can remove today’s forced trade‑offs and deliver a wallet experience that hopefully scales from single‑key simplicity to institutional‑grade governance - all without ever surrendering control.

We invite builders, researchers, and power users to help refine this blueprint and push self‑custody into its next chapter.

About Safe Research

Safe Research is the applied R&D arm of Safe, dedicated to advancing the self custody stack. Our work is grounded in the cypherpunk principles of security, censorship resistance, and privacy, and we focus on building trustless, user centric infrastructure for smart accounts and wallets.

• Discuss on the Safe forum

• Learn more about Safe Research

• Read our manifesto

Let’s make Ethereum’s original cypherpunk vision real, one commit at a time.