What is Developer Trust and how it applies to Self-Custody

Few weeks ago, Paris-based wallet maker Ledger faced severe backlash for their ‘Ledger Recover’ feature which exposed a rather unsettling truth — Ledger’s firmware updates could now access user keys stored on its hardware.

Crypto twitter was up in arms against this feature. 

Here is how one of these notorious tweets effectively contradicts a different statement from November, 2022. Besides, the latter tweet was deleted.

And Ledger’s response did not help.

Ledger Recover: A Message From Pascal Gauthier, Chairman & CEO at Ledger | Ledger

I want to address the concern over Ledger Recover, the way it was announced, and share with you our improved path forward.

LedgerPascal Gauthier

There was a massive backlash, fueled by numerous concerns from users that it effectively negates the self-custody of a hardware wallet — that the kept key could never be exported or shared with anyone, be it via software or hardware. 

Twitter had people both defending and bashing Ledger, it was quite a controversial topic. But why do we feel so split about it? 

If hardware wallets aren’t self-custodial, is the only form of self-custody a paper wallet? Are we all relegated to writing things down for self-custody?

Are hardware wallets self-custodial?

Let’s try to break things down. If you ask an average crypto enthusiast, he or she would define self-custody as ‘nobody but the user has access to her public-private key pair’. 

A good example of this would be Metamask or similar browser-based and mobile wallets. Generally, if you survey a cohort of people who consider Metamask or other browser or mobile-based wallets to be self-custodial, and if you asked them why they believe so, here is how their train of thought could look like:

• Browser extension (Metamask) owns my key pair.
• The browser extension (Metamask) is on my laptop.
• I own my laptop, nobody else.
• Only I own my key and nobody else, so Metamask is self-custodial.

Similarly now, let us try and consider Ledger or other hardware wallets: 

• Hardware wallet owns my key pair.
• Only I own my hardware wallet and nobody else.
• Only I own my key and nobody else, so doesn’t that mean hardware wallets are self-custodial?

Why do we feel that they aren't?

Developer trust. That is our answer.

Developer trust is the assumption that your key-pair is not accessible, somewhere in the supply chain of where it is held. For example, a very web2 equivalent version of this statement would be to assume that the laptop that your password is being entered into, is safe.

With the Ledger incident, developer trust helps in explaining why crypto twitter became highly controversial on the subject:

• Developers at Ledger can update firmware that accesses your key.
• So these developers can steal my key.
• That means, is Ledger not self-custodial?

The idea of developer trust being a point of risk, does not exist only in hardware wallets like Ledger, Trezor, but also in other popular wallet types.  With browser extensions like Metamask, this is the case:

• A browser extension or a mobile wallet has my key.
• A Metamask developer can update the browser extension to export my key.
• My key can be exported, and hence the browser extension is not self-custodial.

Developer trust could be also harder to think about, relative to the simple idea of ‘who owns my key’,because almost everything is dependent on something. And if we push it hard enough, it becomes weird, everything becomes custodial.

Let us assume that we are comfortable with firmware updates on hardware wallets, and dig deeper into the next hypothesis:

• Developers at Ledger can update firmware which could access your key but let us assume that it is safe and in their integrity.
• Ledger depends on Qualcomm chips which could have a driver update or a backdoor, that could steal your key-pairs
• Ledger is now custodial to Qualcomm, and your key is custodial to Qualcomm And if we want to push it even further, let’s take a paper wallet that you have kept in a safe:
• The paper wallet has to be generated somewhere first before being written down, so we start by being reliant on the software/developer that generates your wallet.
• Paper wallet is stored in your safe.
• The brand that built the safe could have a backdoor in it.
• If somebody breaks in, and uses power tools to break your safe down, they can access your key pair too.
• Additionally, when you use your paper wallet, you have to use some software to sign a signature, even if it is offline.

We can keep extending this to much more ridiculous dependencies. There is no limit. But everything can’t be custodial.

Evaluating the optimum level of developer trust for self-custody

Frankly, there is not an astute explanation or definition out there, when it comes to developer trust being self-custodial. There are different approaches towards evaluating how far one can go on the spectrum of developer trust, and it is bound to be different across individuals and use cases. A good way to identify the value of the desired developer trust — is to assess the same against practical tradeoffs that your users or yourself might feel is required v/s the assumptions you are comfortable with. 

An example here — trust in developers of the software and reliance on updates is something I believe most people would deem necessary. Most users would not want to purchase a Ledger subscription for each new chain or signature type. And they appreciate that Metamask goes on to improve its user interface, fixes bugs and allows people to interact with dApps, among similar updates. People are also probably comfortable when their laptops are not backdooring them.

There are a few other ways to reduce the risk for developer trust:

• Open-sourcing the code, so that others may view it and audit the builds.
• Approaches like Lavamoat built by Metamask that reduce the package risk. (At Web3Auth, we clone all critical packages that this risk depends on)
• SHA codes on builds that further verify installs. 

They go the extra mile, relative to many of their competitors and most companies, when it comes to developer trust. As such, we would argue that at the end of the day, in most people’s eyes, Ledger with its firmware updates —  is self-custodial. 

If you found this useful, take a look at our series of blogs that take you through self-custody, several key management architectures, account abstraction, among other subjects. 

Frequently Asked Questions (FAQs)

What is self-custody?

No parties or subsets of parties can access the user’s public and private key pair. The user has full access over their public and private key pair. Self-custody represents that a user has full control over their key and their assets and custodial means that a third party handles a user’s key and assets on their behalf.

What is a hardware wallet?

Hardware wallets are physical devices designed to securely store and manage cryptocurrency private keys. They provide an extra layer of protection by keeping the private keys offline, away from internet-connected devices online, to safeguard them from potential hacking attempts or malware. Hardware wallets are often referred to as ‘cold wallets’ because they store private keys offline. This isolation from online environments significantly reduces the risk of unauthorized access and online threats. 

A few popular hardware wallets include Trezor, Ledger Nano, BitBox, Keevo, SafePal, and CoolWallet.

If you are building a Wallet or a dApp and you are looking to onboard the next billion users onto Web3, sign up here to try out our SDKs.

Read more: How do you truly own a self-custodial wallet?

Read more: Web3Auth MPC is here.