How Decentralized is “Decentralized Finance”?
Decentralization “gold standards”, and common design trade offs
Decentralized finance today is primarily on top of Ethereum and has many cooperating, stacked components:
- Core consensus protocol
- Assets
- 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.
Developer approach / Design trade offs
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:
- Decentralization
- Scalability
- 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.
Assets
Bitcoin and ether — represent a sort of decentralization “Gold standard” among other assets listed above. Each are protocol-native, which means custody and new supply are handled at the protocol level, and both are transparent and open. Each has 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 contract 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 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” and “supply snapshot”).
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 stakeholders (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 enables bitcoin (or other cross-chain assets) 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.
Protocols
Here is a brief list of design features I’ve observed that sacrifice decentralization in some way:
- 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, and 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).
- 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.
- Trap doors — smart contract code is not autonomous 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.
Addressing messaging
Some smart contract protocols and assets do not 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. Lacking clear definitions, terms can be easily misrepresented, and a disconnect between perceived trust and actual trust can quickly form.
- 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 and openness
- 2019: Libra attempts to change the original meaning of “cryptocurrency”
So how decentralized is decentralized finance?
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 an asset or protocol to stray from the base layer’s design tenets, then there likely is a good reason not use these new financial tools.
Any common trade offs I missed? Would love to learn more, please reach out DM with any comments, questions, or corrections. Thanks!
