How Decentralized is “Decentralized Finance”? – Aaron Hay

0 58


Decentralization “gold standards”, and where design trade offs are commonly made

Decentralized finance today is primary on top of Ethereum and has many cooperating, stacked components:

  1. Core consensus protocol
  2. Assets
  3. Smart contract protocols

Smart contracts enable new assets, and new assets may soon act as collateral to enable yet further new assets, all enabled by the underlying core consensus protocol.

So, 2) and 3) rely on 1), and therefore cannot achieve decentralization that is greater than that of 1). Said otherwise, since 1) sets the foundation layer for 2) and 3) to be built on, 1) also sets a theoretical maximum level of decentralization 2) and 3) can achieve / maintain.

While some assets and protocols are built on top of Ethereum with Ethereum’s core tenets in mind, others may not be.

“One thing that I was really cognizant of when I was creating it [Uniswap] was to try to mimic the properties of Ethereum itself. So Ethereum had a few key properties that I actually cared about. It’s not the most efficient processing, it’s not the most efficient storage. It’s the most decentralized way to program, it’s the most censorship resistant… you have this trustless execution, it has all of these properties. And so these (properties) were the ones that I was trying to recreate.”

Wyre interview with Hayden Adams, Creator of Uniswap

In the above quote, a trade off is touched on, that Ethereum, Bitcoin, and other blockchain protocols face: the scalability trilemma. The scalability trilemma states that it is very hard for blockchain systems to have all three of the following at the base layer:

  1. Decentralization
  2. Scalability
  3. Security

No blockchain today has performant decentralization, scalability, and security. Bitcoin and Ethereum’s proof-of-work designs differ, but both chose the capacity for higher decentralization and security with the cost of lower scalability. For assets and smart contract protocols atop Ethereum, these same design trade offs are passed along.

Keep in mind that there is not a finish line to decentralization, and that decentralization is more of a (often subjective) sliding scale. Decentralization cannot be reached, but only strived toward, and just because something is built on Ethereum doesn’t mean it holds its same properties.

Not everything needs to be decentralized, but some things probably should be.

Basic framework to map assets by custody and supply features

Bitcoin and ether — represent a sort of decentralization “Gold standard” amongst other assets. Each are protocol-native, which means custody and new supply are handled at the protocol level, and is transparent and open. Each have known supply rules (i.e. 12.5 new bitcoin every 10 minutes and 2 new ether every 15 seconds) that can be checked. Each are programmatic disinflationary assets that have been around for 10 years (bitcoin) and 4 years (ether), respectively.

erc-20, erc-721, and other token standards are audited smart contracts standards that, similar to bitcoin and ether, enable custody and new supply to be handled in a transparent and open manner. However, a few additive risks exist arise here: 1) custody and ownership is now handled by smart contract code, and 2) issuance may vary drastically by token and should be checked at a reliable source. OnchainFX is a good source to check supply aspects (see “% Y2050 Supply Issued”).

dai — Maker’s dai is a very interesting ongoing, stablecoin experiment. Dai maintains many of the key aspects of ether, but adds quite a bit of complexities with the coordination of multiple smart contracts and decentralized stakeholder (whitepaper). Dai is an erc-20 token, with custody managed by the smart contract, and supply is variable and market-based, dependent on net CDP creation.

Cross-chain assets— wrapped BTC (wBTC) is relatively new and low volume, but presents an innovative solution (wrapped assets framework) that enable bitcoin access to smart contracts on Ethereum.

wBTC does have some transparency features (here, here and here) that users can check, but wBTC still presents a variety of risks all at once, namely intermediary risks (see merchants, custodians), smart contract risks (erc-20), and collateral risk.

Off-chain custody — poses risks specific to the intermediaries and the degree to which they provide user checks and transparency around custodial procedures and security measures (again, see the wrapped assets approach for what some of these safeguards may look like).

Note: Many of the above assets are derivatives, that is, they derive their value from an underlying asset (e.g. USD, BTC, or even a basket of assets). As is exhibited above, the derivative’s supply (e.g. wBTC) and its underlying’s supply (BTC) will vary.

Note: All of the above assets take on centralized custody risks when owned through a centralized exchange. For example, ether on an exchange is an A1 asset to the exchange, but an A10 asset to the exchange user that owns that asset. Similarly, ether placed in a smart contract becomes an A4 asset to its owner.

Here is a brief list of design features I’ve observed that sacrifice decentralization in some way:

  1. Rent seeking — Rent seeking may be clearly stated through a fee (that is beyond required gas fees) or imposed through the required use of a unique token. In theory, if open source code is released that is rent seeking, that is, a fee is built in to the protocol in some way, the protocol can easily be forked with the fee-specific code removed. We are already starting to see this in practice (see zcash/zclassic, bancor/uniswap).
  2. Closed contributor sets —e.g. in proof-of-stake systems, if validator sets are closed to “selected” validators, or the validator selection process is not random, decentralization is limited with trust placed in the governing intermediaries. Similarly, for smart contracts that rely on external data, small, hand picked oracle set introduce additional risks.
  3. Trap doors — smart contract code is not censorship resistant if a developer can temporarily lock, or permanently halt functionality. However, trap doors may prove beneficial in the event of discovered vulnerabilities.

The above list is by no means comprehensive, but rather just a few examples of common protocol design trade offs that I’ve seen. Often times you need to be very close to the code to understand exactly what you are trusting, or messaging needs to be clear and transparent.

Some of the smart contract protocols and assets don’t exhibit much decentralization, but are open and free to use. That is, an argument can be made that some assets and protocols are part of “open finance”, but not “decentralized finance”. However, the line is not clear, and open finance and decentralized finance constantly overlap and mix. A lack of a clear definition around these terms opens up the possibility for these terms to be misused and clarity around trust may be lost.

  • 2016: “blockchain not bitcoin”
  • 2017: buzzword-heavy whitepapers dilute the original meaning of blockchain-specific terminology
  • 2018: “decentralized finance / defi” and “open finance” emerged and are used to market a variety of initiatives and projects with varying degrees of decentralization
  • 2019: Libra attempts to morph the meaning of “cryptocurrency”

It varies by each protocol, asset, and application, and even things that are decentralized can take on centralized form through custodial exchanges and other aggregators.

Users should constantly question messaging and viability of the new financial tools they are using, and more importantly, have a good idea of who (e.g. centralized intermediaries) or what (e.g. smart contract code) exactly they are trusting.

If there is not a good reason for a asset or protocol to stray from the base layer’s design tenets, then there is likely is a good reason to not use these new financial tools.

You might also like

Pin It on Pinterest

Share This

Share this post with your friends!

WhatsApp chat