Solving the Decentralized Credit Problem

Enabling counterparties to under-collateralize obligations without sacrificing trustlessness, openness, or anonymity

The goal of this article is three-fold: 1) To convince the reader that credit is a pre-condition to the efficient functioning of any financial system. 2) To shed light on why this is so challenging to achieve in the context of a decentralized financial system without sacrificing its core benefits. 3) To outline a unique mechanism for solving this problem in derivative protocols.

Why Credit Matters

“Over the last 500 years, the idea of progress convinced people to put more and more trust in the future. This trust created credit; credit brought real economic growth; and growth strengthened the trust in the future and opened the way for more credit.” — Yuval Noah Harrari
Image pulled from “Sapiens”

Our current financial system relies on credit. It is an essential part of a well-functioning economy.

It facilitates the transfer of liquidity from those with an abundance of it to those with a shortage.

It provides the necessary grease that enables counterparties to efficiently transfer risk in the $1.2 quadrillion derivative asset class.

Most importantly, it enables humans to build the present using the promise of the future, making it possible for society to complete projects that would have otherwise been impossible.

Problems with the Current Credit System

Our current credit system relies almost entirely on centralized financial intermediaries.

Intermediaries are given custody of assets, which they lend out to borrowers, who then store these assets at other intermediaries.

This cycle repeats itself multiple times over and as of today, approximately 90% of the estimated $60 trillion of total money in circulation is credit.

Due to the inherent unpredictability of life, borrowers sometimes fail to repay their obligations. If a large enough number of borrowers default at the same time and depositors request their assets back, these intermediaries may be unable to meet these requests and fail.

Because intermediaries are often counterparties to each other, the failure of one party can lead to the failure of others, resulting in a system-wide “death spiral.”

Influenced by the BP death spiral graph

Similar to other crises before it, the global financial crisis in 2008 was the result of an oversupply of credit relative to a shortage of liquidity.

What made it different than prior crises though was the incredible size, centralization, and opaqueness of the financial system.

This made the short-term costs of its failure intolerable and unknown. In response, policy makers decided to socialize the losses through government bailouts.

While credit itself is inarguably a force for good, the current distribution mechanism relies on trusted centralized intermediaries that are so large they cannot be allowed to fail. In the current system, the rewards that come from providing credit go to these intermediaries while the losses are absorbed by society.

Credit on a Public Blockchain

The key challenge then, is figuring out how to get the benefits of credit, without the instability that is caused by the misaligned incentives, opaqueness, and closed nature of the current system.

Decentralized credit systems built on public blockchains could be the solution. Public blockchains have a number of benefits over the current financial system:

  • Trust is placed in software protocols, not centralized intermediaries.
  • Non-discriminatory and permissionless to access.
  • Globally-distributed by design with equal access from anywhere on earth.
  • Individual user privacy with macro-level transaction transparency.
  • Natively programmable and open-source, enabling rapid innovation.

Their unique nature renders the local regulatory barriers that protect traditional financial incumbents moot, flattening the playing field for a new wave of entrants.

In short, we think it is a fundamentally better infrastructure to host a financial system on.

Why Credit is Hard on a Public Blockchain

Traditionally, counterparty obligations are enforced through the legal system. Obligations are typically structured as legal contracts that give creditors the right to pursue the borrowers assets in case of a default.

Unfortunately, this is difficult to achieve in the context of a public blockchain, due to three characteristics of these networks:

  • Pseudo-anonymity of accounts
  • Globally distributed users
  • Permissionless access

Pseudo anonymity makes traditional legal enforcement impossible as lenders are unable to identify borrowers. Even if this is solved with identification, the globally distributed nature of public blockchains makes traditional legal enforcement highly inefficient.

All three problems can be solved if you identify users, censor undesirable ones, and restrict access for the others. At this point however, you might as well utilize a private blockchain as you’ve given up the core benefits of utilizing a public one.

Current Solutions to Public Blockchain Credit

There are a number of methods currently being used to make public blockchain credit systems function, and they broadly fall into three categories: collateralization, reputation systems, and commingling.

Collateralization is the practice by which borrowers pledge collateral ahead of receiving a loan or entering into an obligation. In turn, if the counterparty defaults on their obligation, the lender is able to seize the collateral. It is currently the default method for all decentralized credit systems as it is the simplest and least risky method for ensuring repayment.

Notable examples include:

  • EthLend enables borrowers to get $0.75 of credit for every $1 of collateral
  • Augur requires users to fully collateralize every derivative position
  • Dharma borrowers get around $0.85 of credit for every $1 of collateral
Screenshot of Bloqboard, the leading dharma relayer.

The downside of collateralization is that it makes obtaining credit a very capital intensive process, removing most of the benefits of a credit system. Counterparties must already have significant capital reserves in order to receive credit.

The current designs tend to also require significant over-collateralization to account for the volatility of the underlying crypto collateral. This mechanism removes the leverage benefits that are gained from credit, and resembles more like a mechanism for swapping assets.

The main mechanism for credit creation in collateralization is the idea of counterparties putting “skin in the game” to protect creditors in case of default.

Reputation systems are processes by which a user’s reputation is tokenized and represented as monetary value. Borrowers can then “stake” their reputation when receiving loans, which is then in danger of being damaged in case they default on an obligation.

Bloom is the most prominent example of this, with their peer-to-peer credit staking system.

Bloom enables users to vouch for other users they personally know, and whom they expect to be financially responsible. If a user defaults on a loan, users that vouched for them suffer a decrease in reputation. Users, particularly ones with existing loans outstanding and credit histories, thus have a strong incentive to only vouch for users they believe can repay.

Bloom’s Peer-to-Peer Credit Staking

One downside with reputation systems is that it makes the assumption that the reputation has value. This requires a robust bootstrapping mechanism to achieve.

Reputation systems hold a lot of promise. At this point though, they are highly unproven. It’s unclear whether this system will be secure enough to handle more than just small individual loans.

The main mechanism for credit creation in reputation systems is the idea of creating a new form of collateral that can be used to lower collateral requirements on subsequent deals.

Commingling is the process where individual counterparties contribute unique types of collateral into a single pooled account. This pooled account can then be used to cover any individual borrower defaults.

MakerDAO stands out here as an example.

In MakerDAO, individuals send ETH collateral into a single pooled collateral pool and receive credit in the form of DAI.

The risk with commingling, particularly in the case of Maker, is if there is a sudden market crash in the value of the collateral (in this case, ETH). This leads to a protocol wide collateral shortfall, which has to be addressed by diluting existing holders through issuance. It is thus imperative that commingling is done with non-correlated sources of collateral, which is what Maker is progressing to.

The main mechanism for credit creation in commingling is the idea of diversifying the types of collateral backing individual credit to reduce overall collateral requirements.

Background on CDx

Before jumping into the credit system we’re utilizing, it’s helpful to give some quick background on our protocol.

CDx is a protocol for creating, trading, and resolving tokenized credit default swaps (CDS) on Ethereum. In effect, it’s a peer-to-peer insurance market where buyers pay premiums to sellers in return for a set payment in case some pre-defined event happens (called the “credit event”).

Credit events can be determined automatically by using an on-chain trigger or by referencing an off-chain event that is then voted on by a token-incentivized oracle (similar to Augur).

For example, a credit event for a swap referencing a crypto exchange could be the disabling of all withdrawals for an extended period of time, which has historically been a reliable signal of a major hack.

Like every other decentralized finance protocol, CDx plans to initially deal with the limitations of counterparty credit by initially requiring positions to be fully collateralized.

This means that a participant selling 100 ETH of swap notional has to post 100 ETH of collateral in order to receive the premium. This locked up collateral guarantees full payment for the buyer in the case of a credit event, thereby eliminating any swap seller counterparty risk.

Buyers receive a unique ERC20 token (“buyer tokens”) that can be redeemed for the collateral in the event of a credit event in that specific market. For a swap referencing Poloniex, a buyer would receive “Poloniex buyer tokens”.

Sellers receive a unique ERC20 token (“seller tokens”) that redeemed for the collateral in case of swap expiry in that specific market. For a swap referencing Poloniex, a seller would receive “Poloniex seller tokens”.

The amount of tokens given to each party is equivalent to the amount of protection bought or sold.

Introducing Rehypothecation

An ideal system would guarantee buyer repayment while simultaneously enabling sellers to only partially collateralize their positions.

We believe rehypothecation may be the solution.

Rehypothecation is the practice by which a party that receives a pledge of collateral then pledges the rights to that collateral to another counterparty in a separate deal.

It is widely used by prime brokers to lower collateral requirements for hedge funds trading derivatives as it enables collateral “re-use”.

The practice is relatively complex, so it’s best illustrated with a simple example. Imagine a swap seller that just sold 100 ETH of protection on Binance for 5 ETH of premium. It received 100 “Binance seller tokens” that represents their claims to the 100 ETH of collateral held in the swap, which can they redeem after expiry.

Rehypothecation is simply the idea of letting that seller then collateralize a subsequent swap, perhaps referencing the Bittrex exchange, with those tokens. The seller is paid an additional 5 ETH of premium, but posts no additional ETH collateral.

Very simplistic application of rehypothecation by extending the prior example

However, as you may have guessed, rehypothecation introduces new risks into the protocol, and therefore requires strict rules regarding the practice. A simplistic design like the one above is not robust: if Binance were to suffer a credit event the Bittrex swap would unfunded, exposing Buyer #2 to the risk of being unpaid.

Designing a Decentralized Rehypothecation System

The following proposal outlines how one could extend a derivative protocol, as we intend to do with CDx, to enable counterparties to gain credit by using rehypothecation while still assuring that buyers are repaid.

We outline five broad rules we think should be put in place for derivative protocols using the practice:

  1. The denomination of the re-pledged collateral claims must be identical to the collateral of the new position. This is necessary to prevent mismatches between collateral types. For example, ETH collateral should only be rehypothecated against other ETH-denominated positions.
  2. The expiry date of the rehypothecated collateral should be equal to or after the expiry date of the positions it is being pledged against. This is necessary to prevent expiration time mismatches. For example, the collateral held in a 1-month swap should not be rehypothecated against a 6-month swap.
  3. There should be a minimum base collateralization level. This is optional, and simply a guideline to be conservative. For example, 50 ETH of new posted collateral for every 100 ETH of notional.
  4. Counterparties should only be able to re-pledge collateral once. This is necessary to prevent “double-dipping” of collateral. For example, a counterparty that posted 50 ETH of new collateral on a 100 ETH notional position would receive rehypothecation rights to 50 ETH, not 100 ETH.
  5. Counterparties should over-collateralize any positions that use rehypothecated collateral to adjust for the “lower quality” of this collateral. Rather than a set ratio, positions should be collateralized with a diversified pool of collateral claims.

To use an example in CDx, imagine a swap seller that wanted to sell 100 ETH of swap notional referencing the Binance cryptocurrency exchange.

Using the rules above, they would first partially collateralize the position with 50 ETH. However, they should not be able to collateralize the other 50 ETH of notional by simply rehypothecating 100 ETH worth of collateral claims from a swap they sold on Bittrex.

This is because if Binance were to suffer a credit event, the rehypothecated 100 ETH would disappear, and the Bittrex swap would now be under-funded with only 50 ETH of collateral backing a 100 ETH swap.

Instead, the Binance swap seller should diversify the sources of rehypothecated collateral that back the Binance swap. They could still rehypothecate 100 ETH worth of collateral claims, but it would be split across multiple different markets. For example, it could be 25 ETH worth of seller tokens from prior swaps referencing Bittrex, Poloniex, Coinbase, and Kraken.

Swap seller collateralizing the Binance swap with 25 ETH worth of tokens from four other swaps

This protects the swap buyer in the event that multiple markets default at the exact same time. In this example, the Binance swap would remain fully funded even if both Bittrex and Kraken suffered credit events, as there would still be the 100 ETH worth of collateral backing the swap (50 ETH plus the 25 ETH held in each of the Poloniex and Coinbase swaps).

Given that exchange defaults have historically been uncorrelated with each other, the probability of three hacks happening in the same quarter is extremely low.

In this example, the swap seller was able to sell a 100 ETH notional swap with only 50 ETH of collateral, doubling their effective yield from 5% to 10% (5 ETH premium on 50 ETH of collateral). Additionally, they gained 50 ETH worth of Binance seller tokens they can use to lower collateralization again on subsequent swaps sold.

This also means that as swap sellers participate in more and more markets, they are able to continually lower collateralization levels and increase profitability.

Rehypothecation Risks

Diversification is considered the one “free lunch” in finance.

By combining two investments with non-perfect correlations, diversification enables investors to improve their risk-to-return ratio.

By diversifying the collateral that sellers rehypothecate, they are able to partially collateralize positions while still guaranteeing repayment for buyers under the vast majority of scenarios.

For example, if the probability of an exchange being hacked in a quarter is 2.00%, the probability of three separate hacks happening in the same quarter is 0.0008% (once every 125,000 quarters). However, in the unlikely event this does happen, swap buyers are at risk of not being repaid.

This was a problem in the traditional CDS market during the 2007–08 crisis when many large CDS sellers became insolvent when multiple credit events were triggered simultaneously.

While the crisis had many contributing factors, one of the biggest mistakes made by swap sellers was underestimating default correlation risk, i.e. the risk that credit events of seemingly unrelated entities could become correlated during a crisis.

This is a tail risk that a rehypothecation system could potentially susceptible to as well. For example, using the crypto exchange swap use case, the emergence of quantum computing could be a shared macro risk that renders existing security practices obsolete, which could make credit events between markets cross-correlated.

Mitigating Tail Risk through Token Holder Reinsurance

To assure swap buyers, there needs to be a reinsurer that will step in during extreme scenarios to guarantee swap repayment. For this, we propose a protocol collateral pool that steps in to backstop any collateral shortfalls in the event of multiple, simultaneous credit events.

This protocol collateral pool should managed in a decentralized fashion by a subset of users that are aligned with the best interests of the protocol.

For this reason, we propose having a set of token holders that govern this collateral pool to ensure that the protocol’s collateralization parameters are set in a way that protects swap buyers.

To align incentives, these token holders should put some staked collateral at risk, and in return be paid a portion of on-going trading fees the protocol generates.

If parameters are set too aggressively and multiple simultaneous credit events occur, the risk that the protocol collateral pool will be insufficiently collateralized increases.

In such an event, the protocol could slash the tokens that are staked by the token holders in charge of governance and trigger a public auction of their tokens to replenish the protocol collateral pool. This flow of funds is shown below:

Token holders are incentivized to set conservative collateralization parameters to ensure the collateral pool can cover any possible shortfalls without requiring the protocol to slash their tokens and auction them off.

Token holders set rules that are relaxed enough to encourage swap volume (and thus protocol fees for themselves), but conservative enough to avoid token slashing. In effect, these token holders are the regulators of the protocol that benefit from its success, but have “skin in the game” in case it fails.

Looking Ahead

The vision of an open, decentralized financial system hosted on top of a public blockchain rests on the community’s ability to solve this core problem.

Trustless credit is necessary to open the door to a host of new financial markets, particularly for derivative protocols.

We’re excited to see how these on-chain credit systems evolve moving forward, and will continue to open-source our research to help design them.