As we mentioned in the recent article, decentralized finance (DeFi) aims to remove the middlemen from financial services in order to increase both their efficiency and resilience. Furthermore, it is built on an ambition of freedom from monopolies and cartels, building up on the ‘Satoshi vision’ of a money system without account freezes and inexplicably high fees. Decentralized finance is enabled by three big ideas:
Permissionless setting: no transaction should require permission from any party other than its direct participants, meaning, generally, no third party should be able to prevent a transaction from executing;
Trustlessness: this is a subtle corollary of (1). Holding assets and entering into transactions should not involve trust in any third parties, such as trusting one’s bank to have at all times sufficient liquidity to cash out its depositors, sufficient security to secure the depositors’ funds, etc.
High interconnectivity: combining multiple instruments and/or freely moving liquidity between instruments should be as easy as possible, and available for as wide variety of instruments as possible. This property should not break the previous two properties, e.g. gaining additional interconnectivity by becoming permissioned (i.e. not permissionless) is not acceptable.
This reorientation is becoming possible with the subtle technological shift happening in fintech with introduction of the concept of smart contracts running on blockchains. We will briefly recap the key properties of smart contracts in the Appendix.
Permissionless blockchains running tamper-proof code are the centerpiece of the new finance: they establish a pyramid of infrastructure in which every layer is free from central party risks, and the top layers (application layer) can be shaped into financial services. To retain this independence, however, the design of these services has to account for counterparty risks for every interaction that involves multiple parties: a service has to perform correctly without relying on legal agreements and contract litigation, as that would demote it back to the permissioned version.
Design challenges, therefore, vary by the kind of financial service they try to rebuild, which ends up contributing to the mental framework required for an investor to correctly assess a particular project or service for its existential risks and performance characteristics. Let’s consider a classification of financial services in DeFi.
Map of the industry
One classification was provided in the last post, defining the project lines with the widest current adoption: stablecoins, lending protocols, exchanges, and oracles (infrastructure component, they report external events onto blockchains). This time, since we are considering DeFi in the context of traditional financial services, we will extend this to a functional classification: what does a project offer as its primary use, in the chain of value changing hands (or activities facilitating that). Therefore we start with placing assets at the base layer, since they represent value directly.
Historically, the term DeFi emerged with the first projects focused on decentralized financial services and pioneering some of the patterns we discuss below. Under that definition, Bitcoin and Ethereum would not be considered a part of DeFi. However, from the standpoint of its vision and values, DeFi is inseparable from its groundworks: permissionless blockchains (and their native currencies) set the base on which DeFi is built, and provide the most basic and vital function of value transfers (including payments).
Stablecoins are the transition point, on the one hand, also presenting an asset rather than a service, but on the other hand, relying on the unique novel mechanisms—which we will introduce shortly—to deliver on their value proposition. A narrow category of exotic DeFi contains several cases of asset classes that also use characteristic mechanisms, but have a somewhat specialized value proposition. One example of that is synthetic assets: virtual tokens tied in value to real-world assets and indices (such as gold bullion or FTSE100), traded against the protocol rather than on an open market.
The next layer is the first one focused on services: together with transfers, it comprises asset exchanges and lending instruments, forming the three pillars used universally throughout the industry, both by individual users and within more complex instruments and protocols, internally.
A more complicated layer consists of instruments for hedging and advanced speculation: margin trading, short positions in crypto assets, flash loans (taking place entirely within one transaction, and having to earn by immediate arbitrage), options, and prediction markets. To the side are infrastructure and utility tools, which includes oracle projects, but also many kinds of analytic and data provision tools, as well as interface helpers for retail investors and developers alike.
Decentralized finance stands on four big design ideas uniquely enabled by blockchain (specifically, by a combination of immutable history, immutable code, protocol custody of funds, and permissionless setting).
These ideas are:
- liquidity pools,
- tokenization of participation,
- excessive collateral and liquidation by market agents,
- curve invariants built into pools.
Instead of matching individual counterparties, the protocol pours liquidity from many liquidity providers into one pool, and then the counterparties interact with that pool. For example, peer-to-peer lending (whereby the platform matches a borrower with several individual lenders) is replaced with drawing up liquidity from a liquidity pool, spreading the borrowing operation—and the repaid interest—between every liquidity provider in the pool.
Tokenization of participation
Whenever someone provides liquidity into a liquidity pool, they are issued a token representing that deposit. The entirety of liquidity tokens of a particular pool represent ownership of the entire underlying liquidity committed to that pool, and any repaid interest is just poured into the pool, increasing the value of each liquidity token. This enables open entry and exit (as long as sufficient liquidity remains), which partially fills the role of a debt market.
Overcollateralization and liquidation by market agents
On the borrower side, the only way to guarantee repayment without introducing a central agent (therefore making the system permissioned) is to require overcollateralization. This restriction somewhat narrows the range of use cases, but the construction is still viable for instances such as keeping a long position in a long-term asset while gaining short-term liquidity in another asset. Third-party market agents are responsible for liquidating positions that approach a particular threshold, being incentivized by a discount on the assets they are helping liquidate.
Curve invariants built into pool operations
The pooling mechanic must maintain its ability to function correctly, including repaying liquidity providers, ensuring exchange operations (for exchanges) and lending capabilities (for borrowing pools). This is incentivized by dynamic rates automatically calculated by smart contracts based on the current availability of liquidity. For instance, for a lending solution, the interest on the loan depends on pool utilization (how much free liquidity is still available to lend out from the pool, relative to how much liquidity does the pool represent in total, including money lent out), growing very slowly up to a particular sweet spot (such as 80%) and then rapidly spiking after that. As an example, for an under-utilized pool, interest rate could be 2%, while as soon as someone borrows from an 80% utilized pool, the interest rate would go to 10% and grow exponentially as utilization approaches 100%. This mechanic does two things:
It discourages new borrowers from borrowing too much (by giving them rising rates), and some of the current borrowers may quickly close their loans to avoid paying the spiking rate.
It encourages new liquidity providers to add more liquidity into the pool, offering them spiking returns on their liquidity, as the lender and the borrower side are connected directly (whatever borrowers pays in fees, ends up in the pool).
The equilibrium is at 80% utilization, using as much liquidity as possible while always reserving some tokens for the liquidity providers to be able to cash out at any time.
DeFi instruments leverage the presented design patterns in conjunction with more specific modifications and mechanisms to offer financial services in a permissionless manner, going to great lengths to prevent emergence of single potential points of failure.
The range of services offered partially mirrors traditional finance (it’s envisioned as a replacement, after all), but the specifics of the setting sometimes lead to different mechanics—such as liquidity-based loans instead of p2p or single lender loans,—or entirely new concepts—e.g. flash loans, offering huge amounts of capital without any prior requirements (only for instant arbitrage operations). DeFi opens the door for a new wave of fast and frictionless financial operations, enabling novel operational and business models in the field of managing and utilizing digital assets.
Some ideas commonly seen in DeFi are direct corollaries from the presented patterns: for instance, the concept of “yield mining” or “liquidity farming” arises from liquidity pools tracked by tokenization, with addition of newly minted rewards distributed for liquidity provision. Different variations of curve invariants and pool configurations can produce common use case products, such as lending solutions.
In future articles, we will follow the map of the industry to give a more detailed overview of the key product niches in DeFi. Stay tuned, and stay decentralized!
This article was written by Alexander Bokhenek, tech lead at Republic Advisory Service and co-founder of Byzantine Solutions. It is a part of the ``How to think about DeFi?`` introductory series. An in-depth report on DeFi co-authored by Byzantine Solutions and Cointelegraph Consulting can be found here: Redefine 2020: A Primer.
Appendix: blockchains and smart contracts
The pre-blockchain standard for keeping ledgers is having an organization responsible for the integrity of the ledger. This process can be regulated and externally audited on occasion, but for the day-to-day flow, the organization itself is ultimately in charge of implementing procedures to secure the ledger from hackers, hardware malfunctions, corrupt employees, etc. Auditors, law enforcement, and insurance agencies all support this infrastructure from different sides.
Blockchains do it differently: it is possible to distribute a ledger between many uncoordinated agents and have them compete for the right to add valid transactions to it, offering financial rewards. Agents trying to add invalid transactions would fall out of the game (as the majority will not accept an invalid addition), denying them the reward, so the competition itself ensures the integrity of the system. Open entry and exit for agents is vital, since it is the only way to combat coordination while incentivizing sufficient computational capacity to run the network.
A caveat with this approach is that an arbitrary party will likely not be able to authorise an operation based on a personal relationship with the client, such as requesting personal documents and performing identification and validation. In order for the system to be permissionless, this authorization has to be replicated and verified by every other network participant, which is impossible.
The way to solve this is to replace the requirement of proving identity to one of knowing a secret. Each deposit on the network is associated with a mathematical secret (a cryptographic key pair) that a client creates by themselves and then uses to manage funds: the public key (or its cryptographic derivatives) is an address to send funds to, while the private key signs transactions. Validating that a signature is correct or that the user indeed has funds she is trying to spend is simple for someone who keeps the history of the ledger.
Changing the base assumption from proving identity to demonstrating knowledge of a secret requires tectonic shifts in the ways we do personal IT security, but specialized solutions and new practices with similar (or better) security than debit cards and bank deposits are rather a matter of engineering work than scientific uncertainty.
The same approach to keeping ledgers can be generalized to run complicated code: uncoordinated agents that would validate correctness of signatures and history would take an additional burden to validate transparent computation. With current technology, it is somewhat constrained on throughput and software complexity that can be used under permissionless assumption, but it is plenty for many exciting practical applications—hence this series on DeFi.
This educational article is provided by Republic to help its users understand this area of the market, it should not be construed as investment advice as it is impersonal, disinterested and was produced by Republci’s users, without remuneration received or expected.