With our Buyer’s Guide: Stablecoin Payment Infrastructure set for launch in just a few weeks (register your interest in purchasing a subscription), we’re continuing to break down the technical sides of stablecoin infrastructure, closing out a three-part miniseries on stablecoin wallets.

A table graphic showing the key features of the two main custody approaches for stablecoin wallet infrastructure, with columns titled custodial wallets and non-custodial wallets and rows titled key control, transaction authority, operational burden, control & customisation, counterparty risk, regulatory clarity, scalability at volume and typical users

As we previously explored, wallets are less pockets to store value than critical nodes in the on-chain movement of digital tokens such as stablecoins, which rely on ‘keys’ to ensure security and access control. Last week, we looked at the two dominant security models for such wallets, hardware security modules (HSM) and multi-party computation (MPC), but this week we’re turning our attention to wallet custody.

When companies begin building their stablecoin infrastructure stacks, they need to make a variety of decisions around what works best for them, balancing their levels of on-chain technical capabilities, available resourcing and risk appetite, among other factors. One such decision concerns their approach to wallets. 

Whether offering wallets to end users or just requiring them for their own internal operations, all companies engaging in on-chain money movement will use wallets in some respect. However, they have two primary choices for how they want to handle their day-to-day security and management, known as custodial and non-custodial wallets.

Custodial wallets are when a third party, typically a managed service provider of stablecoin payments infrastructure, controls the private keys to the wallet on behalf of their client. For the business in question, it means they don’t have to worry about the operational complexity or handling the security directly. However, they have to trust that the provider has good security itself, and their level of direct control can be fairly minimal.

On the other side of the spectrum are non-custodial wallets, where the client controls their keys directly in-house, often aided by a key security tool or other related solution. This option gives greater direct control over fund management and policy customisation, and prevents questions around regulatory ownership. However, the client is taking on greater responsibility in terms of both operations and risk, with errors having potentially significant repercussions. 

For fintechs, smaller players and those newer to stablecoin infrastructure, custodial wallets are typically the preferred approach, while regulated institutions such as banks and other enterprise-grade organisations often prefer non-custodial wallets.

Crucially, in practice you may also see some variation in how these terms are used by providers. While custodial generally refers to custody being held by the stablecoin infrastructure provider’s client, such as a fintech or payment company, in cases where that payment company provides services to their own client its use can vary. This is because there are three entities involved: the infrastructure provider, the payment company client and their end user. 

In such instances, custodial and non-custodial is sometimes used by some companies to refer to keys being held by the payment company vs their end users, not the infrastructure provider. In others, wallets being held and managed by the end users are sometimes known as self-custody. 

The release of our Buyer’s Guide: Stablecoin Payments Infrastructure product is now just a few weeks away. If you are working on your own stablecoin products, register your interest to purchase a subscription to the guide to gain vital insights into how to navigate the sector.