The Wallet Service Guide

Too often, even among founders and developers, the understanding of what it truly means to operate a wallet is overly simplistic. Needs may vary from one organization to another, but in our experience, they evolve quickly and often faster than anticipated. A scrappy setup relying on private keys stored in a Ledger Nano, AWS KMS, or worse, and passing signatures to smart contracts from Safe might seem sufficient at first. But for an organization building a fintech application or financial service—with moving parts, multiple stakeholders, stringent security and compliance obligations—such solutions are inadequate. They don’t just fall short, they introduce unnecessary risk.

As Delphi Digital analyst Robbie Petersen writes in what he terms the “fat wallet thesis”: "Throughout crypto’s history, there has been ongoing debate about where value will ultimately accrue within the blockchain stack. While the core contention has traditionally been between protocols and applications, there appears to be a third layer that most overlook—wallets." We couldn't agree more. Wallets are the gateway to crypto ownership for individuals and the infrastructure scaffolding blockchain adoption for businesses. Yet, like many in the industry who are captivated by the latest flashy consumer apps (e.g., the Phantoms of the world) this fat wallet thesis also underestimates a fundamental reality: a large part of crypto today (and tomorrow) runs on wallet APIs and infrastructure products.

The wallets we see today will be a mere fraction of those people interact with in the future. The real wave will come from neobanks, fintechs, super apps, and, most crucially, OCC-chartered banks, each building in-house or integrating crypto with the support of wallets-as-a-service platforms like Dfns. This shift will either eliminate most of the existing wallet apps or relegate them to niche use cases. Consider this: Many assume Revolut is a self-contained wallet without realizing that Fireblocks operates behind the scenes to enable it. Or that Stripe facilitates crypto transactions via internal wallets, without recognizing that Dfns powers them. The future of wallets isn’t in standalone consumer apps. In our opinion, it’s in the invisible, embedded and API-first infrastructure that will help trusted financial services use onchain rails.

Now, finding the right wallet infrastructure platform can be a daunting task. That’s precisely what we aim to simplify in this blog post. As you begin your search, taking notes and browsing for a few hours, you'll quickly realize the sheer abundance of services, each claiming distinct yet overlapping features and benefits. These platforms describe themselves in various ways: wallets, wallets-as-a-service, digital asset infrastructure, custody platforms, embeddable wallets, custodial wallets, non-custodial wallets, and more. Some avoid the term wallet altogether, opting instead for accounts to align with traditional finance, while others conflate blockchain wallets with e-wallets or digital wallets akin to what Apple, Google, and similar providers offer. To be clear, this discussion is about blockchain wallets.

But why a guide? At Dfns, we believe now is the time to push for greater standardization and consensus in crypto technology. People often suggest that we should establish a new taxonomy for wallets and related infrastructure. While there have been previous attempts, like this well-crafted article from Jay Prakash, we find that overall existing classifications fall short. Beyond disagreements over specific categorizations, no framework has fully captured the breadth of challenges facing wallets today, be it security, functionality, privacy, regulation, compliance, scalability, interoperability, operational requirements, and much more. This is why we wrote a guide for wallet services, not just a guide for wallets. Indeed, this is not about wallet UI and UX. Instead, we’re focused on the substratal technologies, protocols and processes preceding UX. In particular, we discuss Developer Experience (DX) and Admin Experience (AX) which are the foundational layers that shape digital asset finance.

This post is our attempt to untangle the complexity, break it down, and establish a meaningful frame of reference. Our deep engagement with digital asset technology puts us in a strong position to clarify definitions and distinguish concepts that have, until now, remained ambiguous. Today, we operate in a landscape cluttered with vague terminology, confusing classifications, and marketing-driven narratives.

Through this guide, we aim to provide both a high-level and technical perspective on the wallet service ecosystem, its nuances, overlaps, and distinctions. But more importantly, selecting the right wallet service, like any critical infrastructure decision, requires a careful evaluation of your business needs: What is the wallet’s purpose? How will users interact with it? Without further ado, let’s begin.

Introducing a new taxonomy for wallets

Kudos to Jay Prakash and the Silence Labs team for writing the best article we've seen so far on defining wallets and their different setups. Building on their work, we aim to refine their framework, as contrasting thoughts and arguments often bring more clarity.

Their article defines custody as “the legal right or duty to care for someone or something.” We agree with this definition at a high level and believe custody should be understood as a legal construct rather than a purely technical one. Many in the blockchain space have blurred this distinction since 2009. Jay Prakash rightly views technology as an enabler (or disabler) of custody, not a definition of it. On another way to look at it is if you take the idea of self-custody to its extreme, you end up with a brainwallet, aka storing crypto solely in memory by memorizing a seed phrase. We strongly advise against this. Relying on human memory alone is a (very) risky way to secure digital assets that has already cost the industry a lot.

We’ve noticed that the traditional cypherpunk idea of linking custody strictly to physical control of data, especially in handheld hardware, is fading. Regulators worldwide are taking a more practical and business-friendly approach by separating tech services from financial services while ensuring they remain closely connected through contracts. In most cases, custody is defined more by legal agreements than by technology. That doesn’t mean physical security is irrelevant, on the contrary. Many jurisdictions, such as VARA and FSRA in the UAE, HKMA in Hong Kong, MAS in Singapore, FSC in South Korea, and FSA in Japan, require keys to be created and stored locally on the national soil, accessible and seizable by law enforcement. Some also mandate that keys remain offline 98% of the time, but they don’t prohibit the use of online HSMs that can receive firmware updates.

In March 2024, a vulnerability (CVE) was found in IBM’s Common Cryptographic Architecture (CCA), which interacts with IBM’s Hardware Security Module (HSM). This flaw (CVE-2023-47150, CVE-2023-33855) could allow remote denial-of-service attacks or data leaks. While IBM provided fixes and documented the issue well, this incident highlights a key reality: no technology can offer absolute control. True security comes from combining technical safeguards with legal agreements, much like a two-factor approach to protecting digital assets. In this, we align with Prakash.

Our main disagreement lies in how they define and frame the wallet glossary. They state: "As part of our effort to standardize terminology and promote better solutions, we encourage people to view custody through the lens of user empowerment." By "user empowerment," they mean how wallets give or don’t give users (read: retail users) more freedom, ownership, and control over digital assets. While we acknowledge the importance of user empowerment and individual property rights, we don’t believe custody should be primarily defined this way.

Historically, custody has always been about convenience, risk management, capital efficiency, and the resource-intensive process of building civilizations—from ancient Sumerian merchants to the Swedish central bank in the 16th century to modern Wall Street. Blockchain doesn’t fundamentally change this from our standpoint. Its humble contribution is to digitize custody, not necessarily shifting it toward reinforced individual ownership. From this perspective, Chris Dixon’s idea of web3 as the "internet of ownership" is only partly true. Yes, assets can now be owned in their digital form, but in practice, most digital assets will remain under active control by companies, governments, banks, or under passive control by cloud providers and hardware manufacturers, but almost never by people themselves. Ultimately, we interpret the definition differently. Optimizing for "user empowerment" as a libertarian and self-sovereign ideal, goes against history in many ways and is neither always possible, desirable, nor practical.

Last, we believe our role as a tech provider is to build tools, not to shape opinions through our products. When you build hammers, you don’t build weapons—you just build hammers. Wallets, like any tool, can be used in many ways by businesses, individuals, groups, and governments. That’s why we recommend setting up and optimizing your wallet infrastructure based on your specific needs. Take Bitcoin Lightning, for example. Right now, the network requires nodes to be online at all times, which pushes companies to run high-performance, trusted nodes in secure environments. Subsequently, individual users often delegate control to these companies (e.g., Voltage, Lightspark) to prioritize speed and cost-effectiveness, which is Lightning’s main appeal. Interestingly, while this reduces user control, or as Prakash puts it “user empowerment”, it also improves efficiency, which ultimately empowers users in a different way.

Building on this focus on user empowerment, Prakash categorized wallets as follows:

• A. Self-Custody – The user fully controls their private keys.
  
  • A.1. Localized Self-Custody – Keys are stored on a single device controlled by the user.
  • A.2. Distributed Self-Custody – Keys are split across multiple devices owned by the user.
• B. Shared-Custody – Multiple parties co-manage private keys.
  
  • B.1. Enterprise Shared-Custody – Keys are shared within an organization for security and governance.
  • B.2. P2P Shared-Custody – Keys are shared among individuals in a peer network.
• C. Delegated Custody – An external entity controls the private keys.
  
  • C.1. Designated Localized Custody – A single custodian holds full control.
  • C.2. Designated Distributed Custody – A custodian distributes key management across systems.

We’re not here to break down every part of this segmentation, but there are a few things we want to clarify. One key issue is the idea of “self-custody,” the other is the conceptual ubiquity of “custody.”  

First, we don’t believe “self-custody” is a real concept. It simply doesn’t exist. Silence uses Metamask as an example, but we can’t say that Metamask truly empowers users when it generates private keys inside a browser controlled by Google Chrome or on a hardware device managed by Ledger.

Second, because so many factors influence security, we prefer not to frame custody as a defining concept in technology. A wallet is either highly secure or vulnerable, depending on its attack surface. The security of a wallet determines how much technical control a custodian has over its assets. Hence, calling a wallet "custodial" or "non-custodial" makes it seem like a fixed fact, but it can give a misleading sense of stability, ignoring the constant risks that come with managing and securing digital assets.

What makes a wallet a wallet

There's a lot of confusion. People call their wallet "smart" because it can do all sorts of things, but when you ask where the “signer” is, they say, "Oh, it's a Ledger Nano." Without realizing it, they've just described their wallet as two separate parts:

1. A hardware-stored key that signs transactions.
2. A smart contract that runs predefined logic (usually only on Ethereum—so really, it’s just an Ethereum wallet).

A wallet is not a key. It’s not a signature. It’s not a node. It’s not a smart contract. It’s not a device. A wallet is a combination of all these elements. More specifically, a blockchain wallet is a software application or hardware device that acts as a digital gateway to a blockchain network. 

It securely stores private keys, which are cryptographic codes proving ownership and control of digital assets tied to a blockchain address. This means a wallet must handle key management. A wallet lets users check their balances, generate new addresses, and create and sign transactions to send assets. This requires running a blockchain node and indexing data. To keep funds secure, wallets use encryption and seed phrases for protection and recovery. They come in different forms: software wallets on personal devices, hardware wallets for offline storage, web wallets accessed via browsers, and even paper wallets (not recommended). Some wallets offer advanced features like multi-signature approval for shared control and smart contract interactions for decentralized applications.

So, a blockchain wallet is basically a key manager and a tool for handling blockchain transactions. It allows users and organizations to securely store, manage, and interact with digital assets across one or multiple blockchains. With that in mind, there are many ways to configure a blockchain wallet, leading to different types. Let’s break them down one by one.

The wallet pyraminx framework

The Pyraminx, also called the triangle Rubik's Cube, is a tetrahedron-shaped puzzle with three layers. We think this toy is a good analogy for wallets, as they can be broken down into three "slices": their technical structure, service deployments, and interaction methods.

• Wallet Components:
  
  • Key management layer: Manages cryptographic keys for secure signing and access.
  • Node management layer: Connects and indexes RPC nodes for blockchain interactions.
  • Transaction building layer: Constructs and prepares transaction playloads before signing.
  • Transaction management layer: Handles transaction execution, tracking, and security.
  • Transaction policy layer: Enforces security rules and approval workflows for transactions.
  • User management layer: Controls and managed user identities, devices, and roles.
  • Entitlement management layer: Defines and enforces user, bot and system permissions.
  • Smart contract layer: Facilitates deployment and interaction with smart contracts.
  • Third-party app layer: Enables connections with external services and platforms.
    ‍
• Wallet Configurations:
  
  • User-controlled wallets : Solely managed and hosted by individual users.
  • Org-controlled wallets : Managed and hosted centrally by an organization.
  • Co-controlled wallets : Shared control between users and organizations.
  • Delegated wallets : Access delegated to third parties under predefined rules.
  • Non-controlled wallets : Operate without direct user or organization control.
    ‍
• Wallet Interfaces:
  
  • APIs/SDKs: Programmatic access to wallet functions for developers.
  • Web applications: Browser-based interfaces for wallet interaction.
  • Mobile applications: Wallet access and management on smartphones.
  • Browsers: Direct integration with web browsers for seamless usage.
  • Iframes: Embedded wallets within web applications for transactions.
  • Devices: Hardware and IoT integrations for secure wallet access.
  • AI Agents: Automated wallet interactions via AI, e.g., cuicui.

There may be some edge cases or missing details, but this covers most of the key aspects of wallets. You'll notice we don’t mention custody. That’s intentional because it’s not the focus here. Blockchain wallets are technical systems with many possible configurations (over 300 in this case). This complexity should make developers, founders, and innovators pause and take a step back. In this blog post, we’ll offer some guidance on how to configure and deploy wallets, whether you choose to build or buy. Let’s start by exploring real-life use cases, putting our “wallet pyraminx” to the test.

• Use Case 1 – Institutional Crypto Trading Desk: A hedge fund operates a high-frequency crypto trading desk. Traders execute transactions via APIs, while risk management and compliance teams approve large transfers through a web dashboard. The firm deploys multi-party computation (MPC) for key security, ensuring no single person can move funds alone.
  
  
  • Components Used:
    
    • Key management layer (MPC-based KMS for private keys)
    • Transaction policy layer (Passkey-based approval workflows)
    • Entitlement management layer (Granular role-based access controls)
      ‍
  • Interfaces Used:
    
    • APIs (Automated trading integrations)
    • Web applications (Administrative dashboard for oversight)
      ‍
  • Configurations Used:
    
    • Org-controlled wallets (Managed centrally by the trading desk)
    • Delegated wallets (Compliance grants traders temporary access)*
      
      
• Use Case 2 – E-Commerce Embedding Wallets: An online retailer wants to accept crypto payments without requiring customers to download a wallet. Buyers use an embedded wallet iframe at checkout, where payments are processed through smart contracts that hold funds in escrow until delivery is confirmed. If a dispute arises, an arbitration smart contract releases funds accordingly.
  
  
  • Components Used:
    
    • Transaction building layer (Pre-signing transactions for a seamless checkout experience)
    • Smart contract management layer (Automated escrow and dispute resolution)
    • Third-party app integrations layer (Merchant services and fraud detection)
      ‍
  • Interfaces Used:
    
    • Iframes (Embedded wallet within checkout pages)
      ‍
  • Configurations Used:
    
    • Delegated wallets (Buyers control funds, but merchants receive automated payments)
    • Org-controlled wallets (E-commerce platform collects fees in crypto)
      
      
• Scenario 3 – Corporate Treasury Management: A multinational corporation manages millions in digital assets for cross-border payments. Their finance team uses a governance-driven wallet setup where any transaction over $500K requires approvals from both the CFO and at least two board members. HSMs are used for additional security when approving high-value transactions.
  
  
  • Components Used:
    
    • Governance management layer (Enforces multi-signature policies)
    • Transaction policy layer (Approval workflows for fund movements)
    • User management layer (CFO, finance team, auditors assigned roles)
      ‍
  • Interfaces Used:
    
    • Web applications (Corporate finance dashboard)
    • Devices (Yubikey devices for passkey signing)
    • APIs (Integration with enterprise treasury management systems)
      ‍
  • Configurations Used:
    
    • Co-controlled wallets (CFO and board members share control)
    • Org-controlled wallets (Company holds final authority over treasury funds)

The best wallet is the one that gets the job done

There are countless ways to use, integrate, configure, and deploy wallets—both for your application and internal operations. With so many options and the reality that small details can have big consequences, it’s crucial to take a step back and clearly define your business requirements, not just for today but for the long term. This means understanding your use case in depth, but also recognizing that wallets are a deeply embedded part of your infrastructure, something you don’t want to revisit every few months. To make the right choices, you need to think ahead, anticipating how your needs will evolve in the coming quarters and years, and ensuring your wallet strategy can scale and adapt as your business grows.The following concepts and examples are not exhaustive and do not capture every nuance of finance and other blockchain-focused industries. However, based on our experience, the most significant trade-offs typically arise in the following design areas:

• Onboarding and authentication
  ‍The onboarding journey varies significantly depending on the type of user (e.g., retail consumers, professional traders, bank employees, fund administrators, gamblers, and more). Authentication methods and security measures must balance usability with risk mitigation. Each user type comes with different expectations and security requirements, requiring careful trade-offs to ensure both seamless access and strong protection.
  ‍

• Organizations and entitlements
‍Structuring your organization within a wallet platform involves aligning your setup with internal policies, regulatory requirements, and operational workflows. Some platforms offer rigid, pre-packaged models with basic user and wallet structures. However, businesses often need more flexibility in defining assets, wallets, accounts, portfolios, sub-organizations, policies, and permissions to maintain granular control. The ability to tailor these structures is essential for efficient operations, whether managing multiple entities, enforcing security policies, or enabling different levels of access across teams.
  ‍

• Wallet interaction interfaces
  ‍‍The way users interact with wallets depends on business goals, security requirements, development expertise, and regulatory considerations. Interfaces can range from UI dashboards, embedded iframes, and APIs to hardware devices and smart contracts. Choosing the right interface impacts user experience, operational efficiency, and even regulatory perception, whether showcasing full control over transaction flows or outsourcing operations to end-users and/or third parties.
  ‍

• Transaction lifecycle management
  ‍‍As your business evolves, you may realize the need to support multiple blockchains, including non-EVM networks. Uniting the diverse and complex semantics of different blockchains under a single API is no simple task. Transaction handling must also align with service level agreements (SLAs), ensuring reliability for large corporations and financial institutions. Cost efficiency also plays a role, aka monitoring margins per transaction, controlling internal approvals, preventing blind signing, and enabling pre-execution checks (e.g., KYT/KYC verification). Building a robust transaction flow ensures security, compliance, and a seamless experience for all stakeholders.
  ‍

• Key management and deployments
‍Regulatory compliance dictates where and how private keys should be stored, influencing key management strategies. The landscape is complex, spanning key generation algorithms, digital signature protocols, data storage methods, computation environments, and hardware security modules (HSMs). Compliance varies by country and organizational policy, making flexible infrastructure more important than ever. A composable and open key management infrastructure allows for adaptable setups, ensuring that businesses can modify and optimize deployments without rigid constraints.
  ‍

• Security and risk management
‍Security in wallet infrastructure is a multi-faceted challenge, given supply chain risks, third-party dependencies, and authentication vulnerabilities. A comprehensive security model must address API request attestation, data encryption (at rest, in transit, and in use), data integrity, deletion policies, recovery mechanisms, tamperproof audit trails, and robust authentication and authorization frameworks. Additionally, having clear documentation, support channels, webhook notifications and alert systems, as well as proactive security measures helps businesses navigate threats while maintaining operational resilience.
  ‍

• Wallet cost structures
  ‍‍Wallet service pricing varies widely. Some providers charge based on assets under custody (often posing as custodians when they are merely tech providers) while others impose transaction fees, API call charges, SaaS subscriptions, or licensing costs. Some require upfront payments as high as $2M before deployment. Understanding these models is critical to ensuring alignment with your business, growth plans, and cost efficiency.

If you're building a payment app, managing high transaction volumes with seamless performance is critical. Blockchains like Binance Smart Chain, Polygon, Celo, Sei, Sui, Solana, and Tron are popular in payments because they handle hundreds of transactions per second (TPS). Your wallet infrastructure must match this scale, offering low-latency key generation and signing without compromising security, as breaches can result in significant financial and reputational loss. Fees are another challenge. Payments often run on thin margins, typically below 2% per transaction. When wallet providers charge a percentage of transactions, it conflicts with standard payment models and raises concerns. Cost-efficient solutions are essential for long-term viability.

In trading, the focus shifts to advanced tools for real-time data and order management. Investment apps, trading platforms, and order and execution management systems (OEMS) process millions of trades daily while ensuring compliance and transparency. To maintain control and coordination across your trading desk, middle office, and back office, it's essential to integrate wallets with robust approval workflows and governance frameworks. Seamless connectivity with third-party applications (exchanges, brokers, market makers, and pre-whitelisted wallet addresses) is also important. Strong integrations enhance liquidity and capital efficiency, helping you secure trades in a fast-moving market where prices can shift in an instant.

In banking, the demands are more complex. Banks operate across multiple blockchains, covering diverse asset classes and customer segments with multiple teams. They maintain distinct yet overlapping frameworks for business and retail clients. Many are well-versed in tokenization for instance, which brings unique challenges as wallets must support the full token lifecycle, from issuance to trading. During a token sale, banks must manage thousands of investors while ensuring seamless integrations and regulatory compliance. For this reason, security remains paramount and adherence to top-tier standards like NIST and local key deployments to reduce risks tied to centralized key management is of utmost importance.

The wallet decemma framework

In a previous blog post, Silence Labs introduced a framework for analyzing digital asset wallets based on three dimensions: Usability, Security, and Empowerment. While this tri-dimensional approach may work for blockchains, akin to Vitalik Buterin’s scalability trilemma, it falls short when applied to wallets. Selecting the right wallet service is not a simple trade-off between three factors; it’s a decemma. The final decision should involve balancing ten key considerations, each shaping the overall choice.

1. Security
2. Usability
3. Resilience
4. Programmability
5. Configurability
6. Manageability
7. Compliance
8. Performance
9. Interoperability
10. Cost structure

Example, if you run a B2B payments company, your key priorities might look like this:

Closing remarks on a paradigm shift

For too long, the industry has been stuck in a binary debate—custodial vs. non-custodial—as if that alone defines what a good wallet is. But that’s the wrong question. The real conversation should be about what is secure and what is not, what works for my use case and what does not. Wallets are not just personal finance tools. They are critical infrastructure for fintechs, banks, exchanges, and institutions handling billions in digital assets. What matters is whether your wallet service is secure, resilient, and fit for purpose. Does it integrate with your operational workflows? Can it scale with your business? Does it meet compliance requirements? These are the questions that should define the discussion.

Security isn’t just about who holds the private key. It’s about attack surfaces, operational risks, governance models, how transactions are managed and approved, and much more. A “non-custodial” wallet in a browser can be more vulnerable than a well-structured institutional custody setup. Likewise, a so-called “custodial” solution can be more decentralized in practice if it’s built with the right distribution of control. The labels don’t matter; the implementation does. As crypto adoption accelerates, we need to move past outdated classifications and focus on what really matters: building wallet services that are robust, scalable, and designed for real-world use cases. This guide is a step toward that shift, providing a framework for evaluating wallets beyond marketing buzzwords.

In our next post, we’ll break down how to structure wallet RFPs and help teams make informed, practical decisions about their infrastructure. Because in the end, the best wallet shouldn’t be defined by ideology but by whether it gets the job done or not.