Why DeFi is Broken: The Importance of Non-Oracle Protocols

DeFi's Flaws: The Significance of Non-Oracle Protocols

Author: Dan Elitzer, NASCENT; Translation: Tiny Bear, Denglian Translation Project

Bring diversity of dependencies to DeFi, instead of relying on a single oracle. DeFi primitives should be zero-governance, non-upgradable, without oracles or any form of external dependencies.

• CoinEx fined $1.7 million and reached a settlement with the New York State Attorney General’s Office (NYAG)
• Evolution of Uniswap: Opportunities and Impacts of V4
• What is Binance Chain’s Layer 2 network opBNB? Binance’s official interpretation

Background

I love DeFi. Permissionless payment protocols and open financial systems initially drew me to Bitcoin, and then to the wider world of cryptocurrencies.

In 2018, I read about Uniswap, which showed me the power of the changes happening in the crypto world. This part will be referred to as DeFi (although I still love open finance).

However, after years of repeated hacks and billions of dollars being stolen, even the most ardent believers have reason to question whether DeFi is suitable for mainstream use, let alone becoming a core part of the global financial system.

The answer is: it won’t…at least not in the way it’s currently built.

At Nascent, we’ve made significant investments in security. In 2020, we were the first investors to commission a tier-one auditing firm (Open Zeppelin) for our portfolio companies to ensure rigorous security reviews prior to launch. We’re also early supporters of Spearbit, Code4rena, Macro, and Skylock.

We’ve also put time into creating tools for the industry. Simple Security Toolkit has been forked nearly 100 times, and we recently announced the beta release of Pyrometer, an open-source tool for auditors and developers that integrates symbolic execution, abstract interpretation, and static analysis.

Through these efforts, we believe that security is not just a matter of “trying harder.” It’s necessary, but not enough– vulnerabilities occur at a frequency and severity at least two orders of magnitude higher than what’s acceptable for mainstream adoption across the industry.

In 2022, over $3.8 billion was stolen through hacks, primarily exploiting vulnerabilities in DeFi protocols and cross-chain bridges. While some vulnerabilities are due to alarming poor security practices, even protocols developed by respected teams following current best practices are not immune.

If we want to see billions of people rely on DeFi, we need to fundamentally rethink the design and security of protocols.

At Nascent, we believe there are a number of security-related concepts that are worth exploring further.

Today, we will first explain the concept of “oracle-less protocols” and why we believe it will fundamentally point to a more robust and secure architecture for DeFi.

Modular Protocols and Primitives

Many DeFi protocols like to dress themselves up as “primitives,” hoping that other teams can build products or composable protocols on top of them.

I’d like to propose a new definition: To qualify as a primitive, a contract must have no external dependencies except for the blockchain on which it is deployed.

This means no governance, no upgradability, and no oracles.

Once any external dependencies are introduced to a contract, the contract inherits any risks associated with that dependency. Governance over contract functionality implies some form of upgradability, requiring threat models to consider potential ranges of change and conditions that may occur both now and in the future. Similarly, oracles introduce external data and all dependencies associated with providing that data, including all potential changes to its accuracy and timeliness.

Primitives should do only what is written on the tin — no more, no less, and without adding any dependencies.

Today, surprisingly few DeFi protocols meet this basic definition. Uniswap v1 may be the most famous, but even Uniswap v2 and v3 (although they meet the spirit of this definition from a security perspective) do not meet the criteria since they allow for some governance functionality, such as the ability to convert protocol fees and introduce new fee tiers for pools.

However, this limited governance functionality does not mean introducing the risk of the large-scale upgradable proxies that exist in many other protocols, and in our focus Uniswap is a big winner:

• No oracles

• Entirely on-chain

Overall, Uniswap has been very successful, and we should all be grateful for its emergence as the mainstream decentralized exchange and the further DEX experimentation it has inspired. Its rise has been widely attributed to offering liquidity for all prices and the simplicity of learning how to become a market maker, and it ultimately displaced earlier projects that were more centralized or reliant on dubious token schemes.

As the industry has evolved, Uniswap has launched a new version of their protocol that moves the design space closer to that of an order book. Uniswap v3 introduces the concept of non-fungible liquidity positions, giving liquidity providers (LPs) the ability to concentrate their liquidity within a specific range. This allows LPs to capture a larger share of the exchange fee from trades within that range, but also increases their divergence loss in the event of price movements. This has led to more efficient capital utilization and specialization of LPs in the market, as well as the emergence of an ecosystem of position management tools including Arrakis, Gamma, and Sommelier.

At this point, many readers may be thinking “well, no oracle is fine for DEXs, but what about lending protocols? You need an oracle for lending!”

I agree: lending does indeed need oracles…but, like with decentralized exchanges, they can be moved outside of the protocol.

Rebuilding Lending

Recently, we’ve noticed investor interest in new and upcoming non-oracle lending protocols like Ajna, Ethereum Credit Guild, Metastreet’s Automated Tranche Maker, and Blur/Paradigm’s Blend.

Unlike traditional DeFi lending markets, Gauntlet doesn’t have collateral factors set by governance or a single universal oracle like Chainlink providing “real” asset prices for all users and protocol functions. Instead, lenders are responsible for assessing risk, deciding how much collateral they want to receive from borrowers, and must update their loan standards as asset prices change.

This is typically done by lenders selecting the specific asset(s) they’ll accept as collateral (e.g. BAYC tokens, a Bored Ape NFT, etc.), the quote asset(s) they’ll offer as loans (e.g. USDC), and setting the ratio of quote asset to collateral asset at which the borrower will be liquidated. The borrower can then submit collateral and borrow the quote asset at the prevailing market rate.

Note that because the borrower and lender have agreed to a loan where liquidation is determined by a ratio of units of collateral on each asset, rather than relying on the USD price, no oracle is needed. However, if the relative USD value of either asset changes, the lender may want to adjust the current or future loan terms to reflect what they consider to be a safe collateral ratio.

One key advantage of this approach is that the protocol is actually impossible to go bankrupt. Since each individual lender is ultimately responsible for the repayment ability of their own loan, there is no concept of “bad debt” that needs to be socialized among DAO treasuries, insurance funds, or borrowers.

Someone mortgaged their ETH to borrow USDC at 95% of the loan amount, is it safe? No problem.

Borrowing with MKR collateral, but only a 10% loan-to-collateral ratio, feels uncomfortable? No problem.

Blur’s Blend assumes that “there are more sophisticated lenders who can participate in complex on-chain and off-chain protocols, evaluate risk and use their own capital”. This makes sense in the context of Blur being a primary venue for professional NFT traders, but for the average user, it seems much more difficult than borrowing on Aave or Compound.

The good news is that it doesn’t have to be that way.

Other protocols or services can make it easy for you to maintain consistent collateral requirements, even if the price of the collateral you lend fluctuates. For example, Ajna is likely to use Oasis and DeFi Saver (or other protocols/services) to automatically adjust the ticks you provide. You can even set up a treasury that allows users to provide DAI or USDC and allows them to borrow the same assets at the same collateral factor as Aave, automatically rebalancing between pools to maximize borrowing rates. Such a treasury can even use Chainlink as its oracle, making the borrower’s user experience and risk profile almost identical to what you get today using Aave.

But if all you’re doing is layering on top of protocols or services to replicate Aave’s existing user experience and risk, why bother building a protocol on top of an oracle-less protocol like Ajna or a raw protocol?

Secure Unified Market Through Diversity

Let me be clear: real financial institutions will never (and should never) invest billions of dollars in a protocol whose security is entirely dependent on Chainlink.

Bringing off-chain data reliably to the chain involves many complex issues, especially when operated in a decentralized, anti-censorship manner. While Chainlink has done admirable work under these constraints, they also become a potential single point of failure for all of DeFi.

The no-oracle protocol — actually designed explicitly to allow users to use their own oracles (BYOO: Bring your own oracle) — provides an alternative path, particularly for complex institutional users who can obtain their own high-quality data sources without needing decentralization or censorship resistance.

It is entirely possible that most users of no-oracle protocols like Ajna will still rely on public oracle protocols like Chainlink and use tools like Oasis to help securely manage their lending positions. But they will also be able to seamlessly operate in the same market as complex users who decide to rely on another protocol (such as Pyth), various zk-based oracles, Bloomberg APIs, or even their own internal price calculations.

We have recently seen in Ethereum itself that the ability to rely on healthy client diversity has allowed downtime to be avoided. A layered protocol development approach that achieves diversity of security-critical service providers could result in similar forms of robustness in DeFi, where problems can be isolated and only affect a subset of users.

For Ajna in particular, remember that it is not just a no-oracle protocol, it is a protocol primitive: it is zero-governance, non-upgradeable, and has no oracles or any form of external dependency. This means that borrowers and lenders can each make their own demands, choose their own management protocols and service providers, and have their own outcome dependencies. Some users may choose to use services that rely on Chainlink and reflect Aave’s collateral assets and ratios, while other users may choose to use Bloomberg APIs and only borrow ETH with conservative collateral ratios.

If an event occurs that damages an oracle or rapidly crushes the value of a collateral asset, users who use different oracles or who do not have loans against that asset will be completely unaffected.

Furthermore, regardless of these choices, users will still aggregate liquidity and interact with counterparties in a single unified market through Ajna. This is the true work of DeFi primitives: providing an efficient, secure market for counterparties to find each other and settle trades, that can run indefinitely.

If you want to know how complex things can be built on top of primitives like this: Infinity Pools is a decentralized exchange that is about to be built on top of Uniswap V3, and provides almost infinite leverage for any asset, without liquidation, counterparty risk, or oracles.

The Future of DeFi is Layered

Is it a good idea to transition DeFi to be primarily built on immutable primitives? After all, we’ve already built exchange and lending worth hundreds of billions from scratch, on top of the flexibility and usability brought by governance, upgradability, and oracles.

I think it is necessary.

Governance, upgradability, and oracles are not inherently bad things. Quite the contrary, they are useful in a wide range of contexts. However, they do increase the attack surface of protocols, and result in most or all users of a protocol being vulnerable to attack due to the enabling of these functionalities.

Moving as much logic and dependencies out of the bottom-level primitives as possible can create a more robust high-level service market, while still unifying liquidity through contracts with an absolute minimum attack surface.

The primitives themselves may occasionally need to be replaced, either due to major new functionality or efficiency improvements introduced in future designs, or due to potential vulnerabilities being discovered. The good news here is that if someone develops a better way to do a primitive, most of the protocols and service providers built on top will be able to migrate their users to the new and improved primitive, as the higher-level services have been explicitly designed to be modular.

Is it worth it?

I think it is.

Compared to various forms of centralized databases and services, blockchains are inherently inefficient. We use them because we believe the power of permissionless access and composability — and the ability to choose to self-custody our own wealth, or choose service providers we trust — are enough to offset the costs and hassle we as users face.

When choosing how to build our DeFi protocols, we face a similar choice: Do we want a protocol that delegates decision-making power over all users’ parameters and external dependencies to the small fraction of token holders who care enough to participate in governance?

Or do we choose a protocol that prioritizes authorization of market participants? That allows users to make their own decisions, or choose other protocols and service providers to decide on their behalf, rather than imposing those decisions on everyone they wish to transact with?

We can depend on centralized failure points. Or we can choose to increase robustness through stack-layered diversity and modularity.

We, who work in this industry, have chosen to commit to the development of decentralized, permissionless, composable protocols, believing that their advantages over traditional centralized, permissioned systems will become undeniable. Similarly, I believe people will come to appreciate the modular, layered approach to DeFi protocol design as it offers secure and resilient improvements.

Remember: We’re not here to build 50% better than before; we’re here to build 50 times better.

Whether you believe oracle-less or layered protocol designs are the future, I hope we can all agree that security in DeFi is not an insurmountable problem. If we never make progress on security, crypto will forever remain a niche.

In addition to the protocol design changes suggested above, there is a host of other concrete steps we can take to push the state of security forward. Future articles in this series will explore the potential and challenges around some of these themes, stay tuned.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!