Trust Spectrum

Most people talk about financial services in crypto—trading, saving, lending, etc.—as either “decentralized” or “centralized.” Crypto advocates tend to characterize the former as less risky because users don’t have to trust a counterparty to custody their assets, removing the risks of losing their funds through a hack, impropriety, seizure from governments, and other forms of human error or malice.

The reality is not so binary. While the platonic ideal of “decentralization” certainly has its appeal, the guarantees that today’s products and services offer cannot be accurately described as simply “centralized” or decentralized . These products and services are best understood along a spectrum of trust models.

In this post, we explore the concept of trust and show how trust isn’t binary, but rather multi-dimensional. Then, we use those properties to develop a “trust score” for some of the top products and services in the market today, show where they fall across those spectrums, and lastly we suggest that custodial-risk doesn’t always predict trust scores.

Each property in this post will include three sub-sections: (1) its trust score spectrum, (2) top products and services in the space along this spectrum, and (3) market observations.

Trust Properties

Before we can start scoring protocols and companies, we must establish a framework to generate scores. We define five properties that contribute to the overall trust a user has to place in a product or service when they use it. These properties are:

1. Custody
2. Immutability
3. Verifiable security
4. Legal and regulatory protections
5. Insurance

These properties were determined by asking two questions. First, “how could a user lose their funds?” and second, “If necessary, how can users recover lost funds?”

A user can lose their funds in the following ways:

• Theft by operator (custody)
• Theft by hacker (custody)
• Frozen by an operator (custody)
• Frozen by a third party (e.g. law enforcement) (custody)
• Frozen by a bug (verifiable security)
• Mismanaged by poor system design (verifiable security)
• Rules of the system change leaving a user vulnerable to any of the above (immutability)

In some cases, users can recover lost funds via a formal insurance policy (on-chain or off-chain), or by leveraging legal recourse.

Using these five properties, we define criteria to determine how to score a given product or service from 1 to 5 (most trust required to least trust required; a higher score is better). In each of the following five sections, we introduce each property, establish the criteria for scoring, and score a sample of 21 products and services. Our sample aims for diversity across product categories (e.g. exchange, lending, otc) and size (we tried to pick the most well known projects and companies in each product category).

Custody

Custody is the property most commonly associated with trust. However, custody is not binary. We rate custody on the following five point scale.

TRUST SPECTRUM

While #1 Custodial and #5 Completely non-custodial are easy to define, the scores in between require a deeper understanding of how each product and service operates. We identified three properties that are most relevant (inspired by Chris Blec’s work here): (1) presence of admin key with the ability to seize or freeze funds, (2) time-lock, and (3) strength of op-sec around the admin key. Scores #2, #3, and #4 are determined by how many of these properties a product or service possesses. For each of these traits that a protocol includes, we increment the score by one point. In sum:

1. Custodial: User funds are custodied by the operator of the product or service. For example, Coinbase is the sole custodian of user funds.
2. Non-custodial, with an admin key: While the operator isn’t custodying user assets, a smart contract is. And if someone—usually the developer(s) of the contract—has the authority to freeze, modify, or drain assets from that contract, then assets are potentially vulnerable. For example, a prior version of Compound allowed an admin key - without a time-lock - to arbitrarily drain user funds (the Compound team did not do this).
3. Non-custodial, with an admin key and a time-lock: This is the same as the above (2), but in this case, it’s more difficult for the operator to compromise users’ assets because of the time-lock. For example, the current version of Compound still allows an admin key to make changes to the contract, but only after a 48-hour waiting period. This gives users a window of time to withdraw their funds.
4. Non-custodial, with an admin key, time-lock, and strong admin key op-sec: This is the same as the above (3) but with published and verifiable practices around the operational security of admin key(s). There were no projects in our sample where the security of user funds were dependent on an admin key and the project had a time-lock and strong admin key op-sec. This will likely change this year as projects as projects improve their op-sec and communicate it to their users.
5. Completely non-custodial: In this model, smart contracts custody user assets and there is no back door of any form. An example of this is Uniswap.

TRUST SCORES

OBSERVATIONS

Three interesting observations can be derived from the scores above.

First, there’s a trade-off between absolute trust-minimization (e.g. Uniswap) and upgradeability. While both MakerDAO (score of 4) and Uniswap (score of 5) are relatively trust-minimized with regards to custody, MakerDAO is able to upgrade system parameters via a formally defined governance system, whereas Uniswap cannot modify existing contracts at all. This means in many situations, MakerDAO users don’t need to exit old contracts, and move their assets to new contracts to receive some upgrades. On the other hand, there is no way to modify the existing Uniswap contracts or parameters; the rules of the system are static, and cannot be changed.

Second, the most used DeFi products and services are closer to their centralized counterparts than the platonic ideal of decentralization. In particular, stablecoins require a high degree of trust because most stablecoins are fiat-collateralized. Compound and dYdX are also notable given their relatively large share of collateral in DeFi protocols. In dYdX and Compound, the teams control admin keys that can be used to modify the smart contracts with some restrictions (e.g. time-locks).

Third, almost every service with a score of 2-5 markets itself as being “non-custodial” and strongly implies high degrees of trust minimization, and thus security. In practice, some users are actually taking on meaningful custody risk. To safely use any of these services, a user must understand the underlying designs of the systems. Blind trust in non-custodial protocols is a risk in and of itself.

Immutability

Rules don’t matter if they can be changed arbitrarily. Whether the rules will change are a function of (a) the motivation of empowered stakeholders to change the rules and (b) the degree to which the rules can be changed. Because (a) is not observable, we focus on (b)--in other words, the mutability of the system.

TRUST SPECTRUM

We rate mutability on a scale of #1 Fully mutable in which operators can change anything to #5 Fully immutable in which nobody can modify contract logic, contract parameters, or pointers/references. Scores of #2, #3, and #4 are determined by the degree to which the system can be changed.

1. Operator has unilateral power to make changes to all aspects of the system. For example, all centralized exchanges (e.g. Binance, Coinbase). This may change as exchange tokens play a larger role in governance.
2. Operator has the power to make changes over most aspects of the system. For example, DeFi products and services without a governance token (e.g Compound).
3. Operator has the power to make changes to some aspects of the system. In our sample, the only product that we scored as a 3 was Unchained Capital because their primary product is a mult-sig “vault” which is immutable but their ancillary products are more mutable.
4. Changes are limited in scope and often only possible through decentralized governance. For example, DeFi products and services where most decisions are governed by token holders (e.g. MakerDAO).
5. Nobody can make any changes. The only product we scored as a 5 was Uniswap.

TRUST SCORES

OBSERVATIONS

Most of the products we assessed were more mutable than not (leaning towards a score of 1). Even the DeFi projects aren’t particularly immutable. This means that a user of DeFi or CeFi should assume that the rules in the system they are using can change. Importantly, even if the system seems to meet all of a user’s trust minimization requirements at one point in time, the ability for the operator to change the rules means that the guarantees of the system are weak.

Most of the time, changing the rules is relatively harmless and even expected; for example, the rules change when centralized exchanges add KYC(this has happened to almost every major exchange and expect to see more of it this year). But even if it’s unlikely to happen, it’s important for a user to understand the worst case scenario in which a malicious operator changes the rules. The most common example of this is an exit scam in which an operator freezes withdrawals and runs away with the money (e.g. Bitconnect).

It’s worth noting an important nuance around opt-in. For major protocol upgrades like MakerDAO’s multi-collateral Dai or 0x v3, users (and 3rd party developers) had to migrate from the prior version to a new version. When Uniswap upgrades to v2, users will have to do the same. The immutability of the prior version creates friction for users (migrating is a pain), but also acts as a natural barrier against malicious changes to the rules. In these cases, developers cannot force changes upon users--the users have to actively opt-in.

Verifiable Security

Every investor’s nightmare is to wake up one day and find that their assets have been stolen. Unfortunately, this nightmare has become reality for many crypto traders. Exchange hacks are a common occurrence, dating back to the Mt. Gox hack of 2014 through the more recent Upbit hack of 2019.

But “exchange hacks”—in which a security vulnerability at an exchange allows hackers to obtain the private key and steal user funds—aren’t the only way users can lose money. Smart contract bugs can leave assets frozen or susceptible to hacks, like in the infamous Parity bug that froze over 1 million ETH. More recently, a bug in the money market protocol bZx allowed two attackers to take $370K and $665K in two separate trades.

Users need to render judgement on a product’s security. In some cases, they have no information available to them—it’s a black box. In other cases, all of the code is open source and has been independently audited by reputable audit firms. In the former, users must trust blindly. In the latter, they can validate security for themselves.

(Note: there are many types of audits--financial, security, process, and even economic--but for the purposes of this post we are focusing on security audits.)

TRUST SPECTRUM

We assign a #1 to black boxes, and a #5 to systems with verifiable security. We score the grey area by assessing the degree to which the products are opaque/transparent and whether and by whom their systems have been audited. An audit is better than no audit, and multiple independent audits is best. Transparent is better than opaque. (Note: formal verification helps reduce contract security risks but we are not accounting for it in this post because none of the projects in our sample have it.)

1. Opaque and unaudited. For example, a centralized exchange with no independent audits. This is common in startup exchanges.
2. Opaque and claims of audit. For example, Tether has claimed solvency audits but these claims have been largely unsubstantiated.
3. Either transparent or audited. For example BitMEX and FTX have stated that they’ve received audits but we could not find any independent reports confirming these audits.
4. Transparent and one single audit or Opaque and audited multiple times. This describes most large centralized exchanges. For example Coinbase and Binance are opaque but both have undergone multiple independent audits.
5. All aspects of the system are public and have received multiple professional audits. This applies to most large DeFi products and services.

TRUST SCORES

OBSERVATIONS

One natural advantage of DeFi protocols is that they’re transparent because they run on public chains and can thus be verified by anybody (note: smart contracts don’t have to be open source, but all major contracts are open source). Because user funds are at risk and writing smart contracts securely is difficult, the more prominent projects in the space have gone through multiple independent audits. This can explain why users tend to feel comfortable sending very large sums through these relatively new systems.

Traditional centralized exchanges have rapidly professionalized over the last few years. This is largely a function of industry maturation, and increased expectations of traders.

However, there are still some cowboy exchanges, notably irreverent (e.g. BitMEX) or upstart (e.g. FTX) exchanges. Interestingly, lack of verifiable security has not stopped these cowboy exchanges from attracting users and significant volumes as BitMEX is one of the largest exchanges and FTX is one of the fastest growing. In fact, one can argue that their lack of verifiable security is a feature, and not a bug. For example, verifiable security requires KYC, which many traders do not want, and formal oversight by derivatives regulators, which encumbers innovation and new product development.

Legal and Regulatory Oversight

While many in crypto celebrate liberation from the legal and regulatory frameworks that govern everyday financial products and services, most people find comfort knowing that if something goes wrong, there is a legal system that facilitates recourse. Moreover, people usually want to know that the entity they are doing business with is bound by a trusted regulatory regime and justice system. Institutional investors in particular prefer—and often require—strong legal and regulatory guarantees from their counterparties.

TRUST SPECTRUM

We assign ratings by asking the question, “if a user’s funds are lost, how likely are they to recover it through legal and regulatory protections?” For DeFi products in particular, there isn’t any legal precedent to rely on so we’ll need to update these scores as the case law develops. For now, we are assessing these protocols to the best of our ability given current information.

1. No protections. This applies to most DeFi products and services.
2. Low chance that users will be protected by laws and regulations. This applies to centralized financial products and services located in jurisdictions known for permissive financial regulation (e.g. Seychelles).
3. A reasonable chance that users will be protected by laws and regulations.
4. High chance that users will be protected by laws and regulations.
5. Strong guarantees that users will be protected by laws and regulations. This applies to centralized finance products and services located in most developed countries.

TRUST SCORES

OBSERVATIONS

It’s clear that legal and regulatory oversight is the most binary of all of the trust properties. Users should either expect almost no legal protection, or strong legal protections.

The protocols with the fewest legal and regulatory protections are those that currently sit in an area ungoverned by any protective regulation. If something goes wrong, it’s unclear which law enforcement agency or regulatory body should engage, if any at all.

While open finance protocols are untested in courts, companies - even those in permissive jurisdictions like the Seychelles - are bound by some laws. We assign these exchanges a 2 because there is some judicial system to backstop losses.

On the other end of the spectrum, the companies that offer the strongest regulatory protections are those that are located in advanced economies such as the US, Europe, Korea, China and Japan.

Insurance

Insurance in crypto ranges from very familiar—such as the FDIC, which backstops most US banks—to the very new—like decentralized insurance that protects users from financial loss due to smart contract bugs.

Among crypto exchanges, Coinbase is the gold standard in this regard. In addition to having FDIC insurance on cash deposits up to $250,000 per user, Coinbase also insures crypto deposits for their hot wallets. Another institution that falls in this same bucket is Gemini, who also insures both fiat and crypto deposits.

Although most crypto exchanges don’t offer FDIC-like insurance on deposits, they do offer other unique forms of insurance. For example, let’s consider Binance’s SAFU Fund. Created in July 2018, the SAFU fund allocates 10% of trading fees to a wallet that will be used to compensate users in the event of extreme cases, such as a hack. To date, Binance’s SAFU fund has been used once when Binance was hacked for 7,000 BTC in May 2019. In the wake of the attack, Binance used the SAFU Fund to cover losses.

Whereas the SAFU fund protects the deposits of users from hacks and other unexpected vulnerabilities, the BitMEX insurance fund insures winning traders in the event that overleveraged counterparties default. The BitMEX insurance fund is essentially a Bitcoin account that has slowly accumulated value over the years as a product of revenue from BitMEX liquidations. Since the inception of the BitMEX insurance fund, other exchanges have created their own comparable insurance funds including Binance, FTX, and OkEx, among others. However, most (if not all) of these insurance funds themselves are custodial, and could therefore be compromised. Maybe one day an exchange will use its SAFU fund to backstop its liquidation fund!

It is important to note that some decentralized protocols also have edge-case insurance mechanisms. For example, in the Maker system, if the collateral pool becomes under collateralized for any reason, the protocol will mint MKR to cover these losses. In the short term, this dilutes MKR token holders, but allows the protocol to remain solvent.

Most DeFi protocols and small off-shore exchanges do not offer any kind of formal insurance. This includes protocols like Synthetix and dYdX. In the event that user funds are drained, there is no capital remaining for users to be compensated. In these settings, users can seek coverage from a third party willing to underwrite smart contract risk. While there are a handful of such services (e.g. Nexus Mutual and Opyn), they are experimental. We will discuss them but they will not factor into our scores.

TRUST SPECTRUM

We rate insurance as follows:

1. No insurance. This includes virtually all DeFi projects and some exchanges.
2. Insurance in some cases (e.g. overleveraged insolvency). Exchanges with margin trading like BitMEX tend to have an insurance fund for this specific form of risk.
3. Some semi-formal form of insurance. Some exchanges have non-standard insurance such as Bakkt’s $125M policy on BTC deposits, and BlockFi’s capital structuring that places clients at the top of the capital stack in the event of liquidation.
4. Partial coverage (e.g. FDIC). For example, Coinbase offers insurance on fiat and crypto deposits up to a limit.
5. Full coverage Insurance. None of the companies in our sample offered complete insurance coverage and we do not expect this to change in the forseeable future.

TRUST SCORES

OBSERVATIONS

By and large, the market currently offers very few options with comprehensive insurance.

On the high end of the spectrum there is deposit insurance. This varies from cash deposits only (e.g. FDIC insurance) to full insurance of cash and crypto deposits. The middle of the spectrum includes forms of insurance that are either informal or cover edge cases.

At the other extreme, users do not have any formal insurance. This includes DeFi products and services that are smart contract native, as well as some bespoke crypto financial products (e.g. USDT).

While DeFi may not offer native insurance, it’s important to note that third party smart contract insurance may play a larger role as the sector evolves. Nexus Mutual has seen a sharp rise in demand since launch in 2019.

It’s also worth mentioning that even if the exchange does not have explicit insurance for some things, many exchanges have made good faith efforts to remunerate their clients in the event of failures. In particular, Coinbase and Binance have a history of making users whole in the event of a system malfunction (e.g. flash crash) or hack.

Most users expect insurance built into their traditional financial products and services, but the crypto market is not yet mature enough for users to take this for granted. The substantial majority of economic activity takes places in venues that lack strong, traditional forms of insurance.

The Trust Score Spectrum

A critical thing to keep in mind when trying to draw conclusions from these assessments is that different users want different things. So rather than try to develop a single holistic score (e.g. with a simple or weighted average), we focus on considering each property independently. We visualize the trust model of each protocol and company using a radar chart.

We’ve highlighted four projects in particular: 0x (blue), BitMEX (orange), Coinbase (yellow), and Compound (green). 0x occupies a large area on the right side of the chart while Coinbase occupies a large area on the lower left side of the chart. Compound is more similar to 0x than Coinbase (which makes sense as they’re both “DeFi”) but occupies less area because Compound in its current state requires more trust than 0x. It appears that BitMEX requires more trust than any other product or service in crypto.

Furthermore, we can imagine distinct users that prefer one set of trust strengths over another. For instance, a decentralization maximalist might value Custody, Immutability, and Verifiable Security over Insurance and Legal and Regulatory Protections. They prefer to use protocols like 0x rather than Coinbase when possible. An institutional investor might prefer the inverse, prioritizing Insurance, Legal and Regulatory Protections, and Verifiable Security and preferring custodial services and mutability. Their ideal product looks more like Coinbase.

Putting It All Together: The bZx Attack

On February 15th, 2020, lenders on bZx, a “decentralized” platform for margin lending and trading, lost a collective $620K when an attacker used a flaw in the platform’s smart contract to take an under-collateralized position and manipulate thin decentralized exchange order books to make out with $370K of profit (after losing some potential gains due to slippage). This post by Korantin Auguste explains the mechanics of the attack.

Although the bZx protocol was supposedly decentralized, funds were lost. It was (as they market on their website) “non-custodial” and permissionless.

Let’s consider each of the five properties. We include our score of the bZx protocol in bold:

1. Custody: 2 non-custodial with an admin key, no time-lock, and unverified operational security around the admin key.
2. Immutability: 1 decisions are made unilaterally by the team. While the platform has a native token that is intended for governance, so far it has not been used to govern any decisions.
3. Verifiable security: 3 the platform is open source and had received audits by an independent auditor but the codebase changed multiple times after the audits, which could explain why there was still a bug in the smart contracts. This highlights the importance of audit recency.
4. Legal and regulatory protections: 2 the business appears to be domiciled in the United States so there is a possibility of legal protections but there is no precedent for this.
5. Insurance: 1 there is an insurance fund but it is effectively empty.

The radar plot for bZx looks like:

First, some context on the attack itself. In order to execute the bZx attack, the attacker had to leave behind some wBTC collateral in an undercollateralized bZx loan. The bZx team decided that the best option was to liquidate this collateral immediately and use it to pay down interest payments on the principle. At the time of the bZx post-mortem, the wBTC collateral had a market value of 1,902.26 ETH which meant that interest payments could be made on the principle loan for 202 years.

In the year 2222, there will be a 4,698.02 ETH loss that will have to be socialized across the entire lending pool. However, 202 years is more than enough time for the bZx insurance fund to grow substantially. By the time the loss actually comes due, the bZx team expects the insurance fund will be able to cover the losses entirely.

This leads us to our first observation: the bZx team can minimize losses by using their admin key. With the admin key, they were able to pause the protocol and liquidate the collateral needed to service the interest payments to lenders. While an admin key makes a system less non-custodial, it also allowed the team to intervene when things went wrong.

Which leads us to our second observation: while bZx has its own insurance fund designed to cover over-leveraged defaults, it did not have insurance on user deposits or smart contract bugs. If users want coverage on smart contract bugs, they can utilize third party insurance providers like Nexus Mutual. A handful of users did, and because there was a bug in the bZx protocol, Nexus Mutual paid out policy holders. This was the first time in history in which a decentralized insurance pool paid out users who lost funds due to a smart contract bug.

And the final and most important point: while bZx would have scored high on verifiable security (transparent and at least one independent security audit), the team has executed thousands of upgrades to the system after the fact, highlighting the importance of recency when factoring in security audits.

This episode concluded with relatively minor losses (about $1M total), but it’s not hard to imagine how greater damages could occur in larger systems with more malicious actors.

Limitations and future work

We chose to present a high-level framework and market review. To achieve this goal, we had to take complex and nuanced topics and simplify them into five-point scales. While we think our approach successfully delivers the broad strokes of the market, there are many topics that were out of scope for our analysis and deserve future attention.

In particular, our approach:

1. Offers a framework to think about this problem but stops short at giving users a tool to compare one product versus another holistically.
2. Does not account for “oracle risk” or the risk that the oracle a product or service relies on fails in some way (and other risks derived from protocol composability).
3. Fails to address centralization in products governed by token holders (e.g. relatively high immutability in theory but low immutability in practice due to concentration of token holders).
4. Focuses only on security audits and ignores other forms of audit like financial, process, and economic.
5. Treats legal and regulatory as a homogenous topic whereas in practice both legal and regulatory are highly complex individually with many nuances based on factors like geography.

We hope to improve on our approach over time and welcome feedback.

Final words

Our intention with this essay is to start a conversation about what trust really means for users of crypto financial products and services. Clearly, a binary label of decentralized or centralized is insufficient for a user to understand the degree to which their funds might be at risk. Evaluating custody, immutability, verifiable security, legal and regulatory protections, and insurance offer a more complete picture. Protocols today span a wide spectrum of trust models and users are unlikely to understand the risks these models pose to their funds.

With regards to custody, we found that many non-custodial services actually imposed significant custody risk on users because of admin keys that allow operators to freeze or drain user funds. In many cases this risk is mitigated by time-locks and verifiably-strong op-sec, but it’s important for users to understand these risks and to not blindly trust non-custodial products and services.

With regards to immutability, we found that in the vast majority of cases the rules of the system can change. So any guarantees in the other four properties are subject to change. In most cases, we expect these changes to be benefit users. But in some cases, operators abuse this trust (e.g. exit scams), so users need to understand if and how the rules of the system can change.

With regards to verifiable security, we found that DeFi projects tend to naturally score high because of their inherent transparency and the best practice of undergoing multiple independent security audits. Interestingly, we found that centralized finance products also score high as exchanges have meaningfully professionalized over the last few years.

With regards to legal, we found that users either have strong protections, or no protections. Unless the product or service is being offered by a US, European, Chinese, Japanese, or Korean company (where they’d have full protections), users should assume they have no protections.

And finally, with regards to insurance, we found surprisingly little coverage by even the biggest exchanges. Only Coinbase offered insurance on both crypto and fiat deposits. And with the exception of “insurance funds” to cover overleveraged defaults, DeFi protocols do not offer native insurance. This could highlight the opportunity for third party insurance providers like Nexus Mutual and Opyn but we’ll have to see more examples in practice to understand the viability and usefulness of such services.

Altogether, this gives us a multi-dimensional look at trust and shows us how deep a user needs to go in order to sufficiently evaluate the trust-model and their risks. We hope that this framework gives users a way to conduct that evaluation and gives developers a way to think critically about the designs of their systems and opportunities for improvement (and indeed, protocol teams are regularly making improvements that reduce the risk for users such as MakerDAO adding a timelock and Compound moving towards decentralized governance). Furthermore, we hope that the industry will collaborate with us by providing us feedback and building on top of this work.

We would love to hear from you. You can reach us at tony@multicoin.capital and ben@multicoin.capital.

Thanks to Calvin Liu, Nic Carter, and Cyrus Younessi for their feedback on this essay.