Self-Custody, Custodial, Non-Custodial, and similar such jargon are loosely used across the industry by products and protocols, creating confusion and a cascaded loss of trust. Let’s fix this once and for all.
While nomenclature helps consolidate discussions, it also opens up doors for exploits, especially if the definitions have loose ends because these ultimately affect the Web3 users' trust and expectations.
As part of our series of blogs analyzing designs that enable decentralization through a user-centric lens, we attempt to tighten the definitions of digital asset solutions, serving different constructs of custody.
‘Custody’, is defined as the legal right or duty to care for someone or something. The subjects to be associated with this legal right in our discussion are ‘digital asset account keys’ and ‘their functional controls’ thereof.
The current wallet landscape maps products claiming to be either self-custodial or custodial in nature. A bilateral conjecture of wallets was fine until they remained within the domain of just private-key custody types. But with the development of numerous wallet types: Social wallets, MPC wallets, Multi-Sig wallets, Custodial wallets, Semi-custodial, Non-Custodial wallets, hybrid wallets, browser-extension based wallets, newly coined ‘Smart Accounts’ à la (Gnosis) Safe, and many more, not to mention the upcoming wave of Ethereum Improvement Proposal (EIP) number 4337 being deployed on the mainnet which will produce some new types too, the lines in nomenclature and custodialism are blurring.
What’s worrisome here is that a large number of these wallets project themselves as self-custodial. While competition is healthy for the digital asset ecosystem, we also need to ensure that nomenclature are not misused, and thereby, users misled.
CEXs have shown multiple instances of how delegated custody is dangerous. Because FTX controlled users’ wallets and keys for them, users depended heavily on FTX to access their holdings and were unable to access or withdraw their own assets once FTX began to experience liquidity issues. This is not a new phenomenon, several such cases have been experienced by the industry before also.
In the previous blog, we proposed a framework to study and analyze digital asset wallets through a tri-dimensional lens: Usability, Security, and Empowerment.
As a continuation of our effort to standardize the nomenclature and push for better solutions with empowerment in mind, we encourage folks to think about custody primarily from the perspective of user empowerment.
Empowerment is a function of the user’s freedom, ownership, and capabilities of their account, generally manifested in the access of the wallet’s key. The concept of Empowerment can, therefore, be captured across four features:
- Perpetual access and complete control of digital assets held by the user,
- Permissionless movement of assets from one wallet service provider to another,
- Permissionless recovery of accounts/wallets/access to digital assets, and
- Platform Transparency w.r.t their type of custody and steps to take for safekeeping
It is to be noted that the majority of these features can be manifested through abilities encompassing possession of a private key and the generation of a valid signature across Web3. Building on the four features and capabilities, we propose the following nomenclature:
- A. Self-Custody
A. 1 Localized Self-Custody
A.2 Distributed Self-Custody - B. Shared-Custody
B.1 Enterprise Shared-Custody
B2. P2P (Peer-to-Peer) Shared-Custody - C. Delegated Custody
C.1 Designated Localized/Centralized Custody
C.2 Designated Distributed Custody
Custody should be seen as Spectrum as a function of empowerment.
A. Self-Custody
Users of self-custody wallets have total and perpetual access-cum-control of their digital assets. The user controls the private key as a whole or in parts. No matter what, unless not exposed to theft and cyber-attack, they cannot be blocked from performing any transactions. The self-custody wallet service provider cannot deny their users from exporting wallets and shifting to a different service provider. Recovery of the wallet to a new device does not involve the wallet service provider’s approval. Users can never be blocked from recovery. All these are possible because the private keys of the wallet are under the control of the users (stored locally in the browser’s or phone’s storage). Since the users completely control their Private Keys, wallet providers cannot fiddle with the user’s funds.
Note that while the keys are under the control of the users, their localization still possibly leads to a single point of failure (keys can be stolen or users can be phished to type seed phrases) which affects all such wallets; be it MetaMask, Trust Wallet or Exodus.
On the bright side, the recent adoption of cryptographic methods for decentralization of signatures through MPC-Threshold Signature or Multi-Signatures has led to designs where private keys do not exist as a whole, throughout the lifetime of the wallet; rather key shares are used to either compute a valid signature or generate multi-signature verifications. If the key shares are still controlled by the user somehow, all previously suggested benefits of single private-key-based self-custody wallets can be supported while bringing risk decentralization to these wallets.
In light of the above discussions, we further segregate self-custody into two parts:
- Localized Self-Custody: Private keys as a whole are locally stored and accessed by the wallets (eg: Trust Wallet, Electrum, Exodus, and MetaMask in their current adopted forms)
a) Signature: Pull the private key from local storage and generate a signature.
b) Recovery: Dominantly seed-phrase based. - Distributed Self-Custody: Wallets in this category (should/would) provide distributed signature methods wherein private keys do not exist ever as a whole, rather distributed key shares (shards) exist. The distributed nature of self-custody is possible through cryptographic algorithms based on multi-party computation (MPC)-Threshold Signatures, Multi-Signature, etc.
It is to be noted that users of these wallets control all key shares and can sign any transaction using MPC-Threshold Signatures (for example, Silent Shard by Silence Laboratories where distributed key-shares are agreed between user’s devices during the first installation of the distributed key generation (DKG) phase, while setting-up an MPC wallet or exporting an EOA wallet to MPC). Multi-sig (for example, SAFE (Gnosis-based Multi-Sig between different users)) can also enable distributed self-custody smart-contract(SC) wallets, through some hybrid innovations. Several account abstraction SC and hybrid wallets, with all signing factors under the user’s control, will also fall under this category.
a) Signature: Private keys are never exposed, and distributed signature is generated through relaying MPC protocols between devices or signature aggregation through multi-sigs
b) Recovery: Cloud-based recoveries, social recovery, enterprise-assisted encrypted backup, self-custodial backup on hardware of Decentralized Storage products, etc.
The beauty of distributed self-custody is in the fact the while there is no single point of failure, thanks to MPC and related technologies, the user still has the very maximum level of empowerment.
As shown in Table 1, both the designs of self-custody tick all metrics of empowerment, basis the model proposed in the previous article. A detailed blog on designing distributed self-custody wallets is coming up soon, stay tuned. We’re already seeing the adoption of such designs by major wallet players.
B. Shared-Custody
In another set of designs, wallets are associated with distributed key shares held in parts by the user and the enterprises (providing wallets) or a set of guardians. A threshold number of parties (each with a key share) must come online (synchronously or asynchronously) and participate in the signature generation process. Alternatively, a threshold number of parties (guardians) can be affiliated with Multi-sig Smart Contract Wallets for validations as well.
In light of the above discussions, we further segregate shared custody into two verticals:
- Enterprise Shared-Custody: As a popular construct of distributed signature, wallets have adopted shared key shares between phone wallets and enterprise servers, cloud, rackspace or storage.
The generic design, as popularized by Zengo and Coinbase, has certainly given a boost in security over traditional seed phrases and single private-key-based wallets.
.webp)
We would be seeing multiple variants of such design including 2 to ’n’ number of MPC nodes, each having a key share. Several clients who come to us, adopt something similar wherein the resilience, load-sharing, and risk aversions of the computation have been key decision-makers.
a) Signature: Private keys are never exposed, and distributed signature is generated through chatty MPC protocols between the smartphones and the enterprise servers.
b) Recovery: Cloud-based recoveries, enterprise-assisted encrypted backup, etc.
2. P2P Shared-Custody: In another set of designs, particularly with Multi-Sig constructs, signing authorities are shared between peers. There are examples of social multi-sigs using Gnosis SAFE or MPC-based custody solutions where peers in a company share key shares.
Key notes on Shared-Custody design:
a) While there is a big jump in the dimensions of security, this design lags behind Distributed Self-Custody along the dimensions of empowerment. A user/signer may be blocked (for example, if the server part of the key-share is disallowed from participating in the signature or recovery) from accessing/shifting the account by the enterprise or the co-signing peers.
b) This is actually desirable under enterprise (digital asset management companies) settings where consensus or hierarchical approval is needed. But a retail user might expect a higher degree of empowerment where nobody can deny them from accessing services.
More and more, we have to make user and case-centric design decisions when products are first conceptualized, and make them as the first choice.
C. Delegated Custody
In yet another set of designs, keys or key shares are handled by delegated enterprises or a network. We can position any centralized exchange that controls and stores the keys of customers in this category. The mayhem such models can create in the case of deeply centralized enterprises like FTX needs no explanation. When one enterprise has the highest authority, we can call that design a Designated Localized Custody.
When the delegated key shares are held by a group of enterprises or a network of nodes, we can categorize them under Designated Distributed Custody. While the risk is distributed, users are not in ultimate control of their assets. Users typically provide some form of identity to trigger MPC or Multi-Sig protocols and generate a valid transaction/signature on their behalf.
As part of this blog series, we would be doing deep dive into each of these designs from different perspectives.
Wehave come a long long way as an industry — from seed phrases to sophisticated designs around custody. Thanks to the researchers who’ve been pushing the boundaries of cryptography and engineers who have been keeping pace to test, ratify and scale those algorithms. What a time to build together!
Conclusive remarks:
- Industry nomenclature needs to be revisited and an attempt has to be made in general consensus towards standardization. This blog is just a start.
- While Self-Custody and Shared Custody are at the higher end of the empowerment spectrum, innovation around distributed self-custody and shared custody are emerging as promising paths for safeguarding digital assets.
If we decide to solve the management of the digital assets at enterprise and retail levels, let’s make user empowerment a moonshot target and march towards building a trustless system.
While distributed self-custody wallets check a much-needed box in the balance across the 3 dimensions, unfortunately there are hardly any EOA wallets in this domain. Silence Laboratories provides dedicated SDKs for converting existing wallets to distributed self-custody, and shared-custody wallets. As of today, the SDKs use ‘DKLs’ protocols: DKLs18, DKLs19, Lindel17 and GG20 with niche features in access, synchronizations and structuring quorums.
As always, progress is a collaborative affair, and we’re open to feedback and conducting joint research. Aiming to open-source the framework, methodology, and results, with all credits attributed, we welcome you to join the discussion by emailing info@silencelaboratories.com, booking a slot to discuss more through Calendly, or writing to us on @SilentAuth on Twitter.
ABOUT US:
Silence Laboratories is a deep-tech authentication provider that offers developer-friendly SDKs and libraries for protocols, wallets, and custodians that can be used to embed/build distributed, zero-trust authentication or authorization products alike. We aim to be a defacto MPC and Proofing product suite for others to build on top of. For ease of integration, we are application, protocol, custodian, and stack agnostic, technologically fluid and future-forward.
Acknowledgements
Thanks to the continuous discussions with Schwarze Katze and
, and for their detailed feedback and edits.
CEO, Co-Founder
