Self-custody essentials and tradeoffs
Henri Stern
|May 13, 2024
Our mission at Privy is to enable products to empower their users online. We believe making self-custody a seamless part of app experiences is at the heart of this mission. In turn, this has driven our technical decisions to ensure users really remain in control when using products, to the benefit of users and developers alike.
Yet, self-custody comes with a number of tradeoffs: controlling your keys also means you are more likely to lose them. In this piece, we discuss some of the technical and UX implications of building a self-custodial system. While we’ll touch on regulatory issues, the legal definition of self-custody is shaped by legal opinions and jurisprudence rather than cryptography. We work closely with our regulatory counsel to navigate these questions.
Self-custody and asset composability are crypto’s defining features. Custody is about who controls keys. A self-custodial system is one in which the user is the sole party that possesses and controls the private key needed to sign transactions and prove ownership of their assets. Put simply, in a self-custodial system, the user is the only one who can control their assets.
This is core to web3’s potential as a positive technology that can empower users on the web. Self-custody helps address:
Platform risk – By controlling their own assets rather than delegating this to a third-party, users have guarantees that they cannot be deplatformed or unbanked by a given provider for arbitrary reasons. Certainly, clients can choose what customers to serve (within the bounds of the law) but self-custody ensures that a product-level decision doesn’t affect a user’s assets or livelihood beyond that one product.
Security – Self-custody limits the fallout of a given provider breach. Since the user account is distinct from the product itself, apps themselves are no longer honeypots for user data and value. Only the user can control their assets.
Regulatory – By ensuring your users remain in control of their funds and assets, self-custody ensures your product does not become a “money service business” which rightfully entails a number of onerous regulatory requirements.
This last point is essential—building a crypto-enabled product does not entail building a financial institution. This is the difference between accepting payments with Stripe and building a neobank.
Accordingly, self-custody enables you to make the best of decentralized systems without becoming a financial institution. It enables your product to empower your users, and can unlock differentiated experiences. But this power comes with drawbacks.
Fundamentally, users should not need to understand modern cryptography to use the Internet, much in the same way you don’t need to understand TCP-IP to use the Internet. Yet today, self-custodial systems often saddle their users with deep complexity, and the need to understand seed phrases or the limitations of modern cryptosystems.
As we work to improve self-custodial systems, it’s helpful to pin down the features of self-custody so we can understand how to walk these tradeoffs. The more power you give a user, the greater their ability to harm themselves if they are not properly equipped/educated. For instance, approving every signature can be tedious for many applications, yet abstracting them away from users gives developers a lot of power. Likewise, enabling users to export private keys makes it easy for them to take their assets elsewhere, but it also makes compromise more likely. With all of these systems, it’s important to weigh the benefits of user power against potential misuse.
We break down these tradeoffs with 4 key questions:
Who controls keys?
This is the closest thing we have to a litmus test on self-custody.
✅At Privy, we use Shamir’s Secret Sharing to split keys so they are only ever reassembled on the user’s device to be used by them. No one but your user ever has access to their keys, and they must always be present in order for the keys to be reassembled and used.
Am I prompted for signatures?
Active consent is the first key question. Users should always be online and present when their keys are used, unless they have explicitly delegated permission for usage over certain actions.
✅At Privy, we default to requiring signatures for all actions but also enable a headless signature mode for apps where UX interrupts are too costly (like games). In any case, a user must be online and active for keys to be used.
Can I always leave?
Your user should always have an escape hatch. This means giving them the ability to bypass any client or UIs you give them, or retrieve their assets unilaterally if they are ever unhappy with your product.
✅Key export has been a feature of Privy’s embedded wallets since day 1. Today, we work with wallet providers to improve the UX of export!
Will I be able to get my keys in case of an outage?
A self-custodial system should be resilient to outages, meaning your user should be able to unilaterally retrieve their assets even when a service provider is down. This is akin to censorship resistant.
❌This is an unlock we are working toward but a Privy outage today will make your keys temporarily unavailable.
While there is tension between self-custody and accessibility, walking through these questions can help you determine how to make the best of self-custody. Users are not one size fits all, nor should the machinery they use be.
The future is bright for self-custodial systems. The last 15 months have seen deeper focus on UX and accessibility for crypto-native products than ever before. As we continue to push the bounds of what is possible, self-custody will become a common part of the web’s fabric!
Onward!