Why Defi Is Broken On The Importance Of Oracle-Free Protocols

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

Bring the diversity of dependencies to DeFi instead of relying on a single oracle. DeFi primitives should have zero governance, no upgradeability, no oracles, or external dependencies of any kind.

background

I love DeFi. Permissionless payment protocols and an open financial system are what drew me to Bitcoin in the first place, and then to the wider world of cryptocurrencies.

In 2018, I read about Uniswap, which opened my eyes to the power of change that was happening in the crypto world. This segment will be called DeFi (although I still like Open Finance).

But after years of repeated hacks and billions of dollars stolen, even the most ardent believers have reason to question whether DeFi will ever be suitable for mainstream use, let alone become a core part of the global financial system.

The answer is: it won't...at least not in the way it's currently set up.

At Nascent, we've invested heavily in security. In 2020, we were the first investor to entrust a Tier 1 audit firm (Open Zeppelin) to our portfolio companies to ensure priority access to stringent security reviews prior to launch. We are also early supporters of Spearbit, Code4rena, Macro and Skylock.

We also dedicate our time to creating tools for the industry. The 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 being safe isn't just a matter of "trying harder." This is necessary, but not sufficient – across the industry, the frequency and severity of vulnerabilities are at least two orders of magnitude higher than acceptable levels for mainstream adoption.

In 2022, more than $3.8 billion was stolen through hacking attacks, mainly exploiting vulnerabilities in DeFi protocols and cross-chain bridges. While some vulnerabilities are the result of disturbingly bad security attitudes, even protocols developed by respected teams and following current best-in-class processes are not immune.

**If we want to see billions of people relying on DeFi, we need to fundamentally rethink protocol design and security. **

At Nascent, we believe there are a range of security-related concepts that deserve further exploration and exploration.

Today, we'll start by explaining the concept of an "oracle-free protocol" and why we think it will fundamentally point to a more robust and secure architecture for DeFi.

Modular protocols and primitives

Many DeFi protocols like to dress themselves as "primitives", hoping that other teams can build products or composable protocols based on them.

I would like to propose a new definition: In order to qualify as a primitive, a contract must have no external dependencies other than the blockchain it is deployed on.

This means no governance, no scalability, no oracles.

Once any external dependency is introduced into a contract, the contract inherits any risk associated with that dependency. Governance of contract functionality implies some form of upgradability, requiring a threat model that takes into account both the range of possible changes and current and likely future conditions. Likewise oracles introduce external data and all dependencies associated with it for providing that data, including all potential changes in its accuracy and timeliness.

A primitive should just do what it says on the jar - i.e. no more and no less, without adding any dependencies.

Today, there are surprisingly few DeFi protocols that fit this basic definition. Uniswap v1 is probably the best known, but even Uniswap v2 and v3 (while in the spirit of this definition from a security standpoint) do not qualify as they allow management of certain functions such as protocol fee conversion and funding The ability for pools to introduce new fee tiers.

However, this limited governance functionality does not mean the risk of introducing massively scalable proxies that exist in many other protocols, and Uniswap is the big winner here:

• no oracle
• fully on-chain

**Uniswap has been very successful overall, and we should all be grateful for its emergence as a mainstream decentralized exchange and the further DEX experiments it has inspired. Its rise is widely credited to providing liquidity at all prices and the simplicity of learning how to become a market maker, with Uniswap eventually replacing earlier projects that were more centralized or relied on dubious token schemes. **

As the industry evolved, Uniswap launched a new version of their protocol, shifting the design space to be more akin to an order book. Uniswap v3 introduces the concept of non-homogeneous liquidity positions, where liquidity providers (LPs) have the ability to pool their liquidity within a specific range. This allows LPs to capture a larger share of conversion fees from transactions in that range, but also increases their divergence losses when prices change. This has led to a more efficient use of capital and the professionalization of LPs in the market, along with the emergence of an ecosystem of position management tools, including Arrakis, Gamma, and Sommelier.

I expect at this point that many readers will be thinking "well, no oracle is fine for a DEX, but what about a lending protocol? You need an oracle for lending!"

I agree: lending does require oracles...but, as with DEXes, they can be moved outside the protocol.

Restructure lending

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

Unlike traditional DeFi lending markets, Gauntlet does not have a collateral factor set by a governance body, nor does it have a single universal oracle like Chainlink that provides "true" asset prices for all users and protocol functions. Instead, lenders are responsible for assessing risk, deciding how much collateral they want from borrowers, and must update their lending criteria as asset prices change.

Typically, the lender chooses the specific asset they will accept as collateral (e.g., BAYC tokens, a Bored Ape NFT, etc.), the asset they offer to borrow (e.g., USDC), and the set Determine the ratio of the borrower's liquidated quotation assets to collateral assets. Borrowers can then submit collateral and borrow the quoted asset at prevailing market rates.

Note that no oracle is required since the borrower and lender have agreed to a loan where liquidation is determined via a ratio based on the number of units collateralized on each asset rather than relying on dollar prices. However, if the relative dollar value of either asset changes, lenders may wish to adjust current or future loan terms to reflect what they consider a safe collateralization ratio.

A key advantage of this approach: it is virtually impossible for a protocol to go bankrupt. Since each individual lender is ultimately responsible for the solvency of its own loan, there is no concept of "bad debt" that needs to be socialized by DAO treasuries, insurance funds, or among borrowers. **

Is it safe for someone to mortgage their ETH to borrow USDC at 95% of the loan amount? It doesn't matter.

Feel uncomfortable taking out a loan with MKR collateral but only have a 10% loan collateralization ratio? It doesn't matter.

Blur's Blend assumes "the existence of more sophisticated lenders who can participate in complex on-chain and off-chain agreements, assess risk, and use their own capital." This makes sense in the context of Blur being the main venue for professional NFT traders, but for the average user it seems like a lot more work than taking out a loan on Aave or Compound.

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

Other protocols or services can make it easy for you to maintain a consistent collateralization rate requirement even if the price of the collateral you lend fluctuates. Taking Ajna as an example, it will be possible to use Oasis and DeFi Saver (or other protocols/services) to automatically adjust the ticks you provide. You can even build a vault that allows users to provide DAI or USDC, and make it possible to borrow the same asset with the same collateral factor as Aave, automatically rebalancing between fund pools to maximize the loan rate. Such a vault could even use Chainlink as its oracle, making the user experience and risk profile for lenders nearly the same as it is today with Aave.

But why build a protocol on top of an oracle-free protocol like Ajna, or an original protocol, if it's just about layering on a protocol or service to replicate Aave's existing user experience and risk?

A secure unified market through diversity

Let me be clear: **Real financial institutions will never (and should not) put billions of dollars into a protocol whose security depends solely on Chainlink. **

Reliably bringing off-chain data on-chain involves many complex issues, especially the need to operate in a decentralized, censorship-resistant manner. While Chainlink does an admirable job within these constraints, they also become a potential single point of failure for all of DeFi.

No oracle protocols - in fact, protocols explicitly designed to allow users to bring their own oracles (BYOO: Bring your own oracle), provide an alternative path, especially for those that do not need to be decentralized or censorship resistant. Sophisticated institutional users of their own high-quality data sources.

It's entirely possible that most users of an oracle-less protocol like Ajna will still rely on a public oracle protocol like Chainlink, via a tool like Oasis to help securely manage their lending positions. But they will also be able to operate seamlessly in the same marketplace with sophisticated users who decide to rely on another protocol (like Pyth), various zk-based oracles, Bloomberg APIs, or even their own internal price calculations .

As we have seen recently in Ethereum itself, the ability to rely on healthy client diversity enables downtime to be avoided. A layered approach to protocol development, enabling a diversity of security-critical service providers, has the potential to bring about a similar form of robustness in DeFi, where issues can be isolated and only affect a subset of users.

As far as Ajna is concerned, remember that it is not just an oracle-free protocol, it is a protocol primitive: it has zero governance, no upgradeability, no oracles or external dependencies of any kind. This means that borrowers and lenders can each make their own requirements, choose their own management agreements and service providers, each with their own outcome dependencies. Some users may choose to use services that rely on Chainlink and mirror Aave's collateral assets and ratios, while others may choose to use Bloomberg's API and only lend against ETH with conservative collateral ratios.

If an event happens that damages an oracle or quickly shatters the value of a collateralized asset, users who use a different oracle or have no loans against that asset will be completely unaffected.

And, regardless of these choices, users will still pool liquidity and interact with counterparties in a single unified market through Ajna. This is the job of the real DeFi primitives: to provide an efficient and secure marketplace where parties can find each other and settle transactions, running forever.

If you're wondering how complex you can build on top of protocol-like primitives: Infinity Pools is a soon-to-be decentralized exchange built on top of Uniswap V3, capable of virtually unlimited leverage on any asset, with no liquidations , no counterparty risk, and no 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 have built hundreds of billions of exchanges and loans from scratch, based on the flexibility and ease of use that governance, scalability, and oracles enable.

I think it is necessary.

** Governance, scalability, and oracles are not inherently bad. On the contrary, they are quite useful in a wide range of environments. However, they do increase the attack surface of the protocol and lead to vulnerabilities and attacks for most or all users of the protocol due to these features being enabled. **

Moving as much logic and dependencies as possible out of the lowest-level primitives creates a more robust marketplace for higher-level services, while still unifying liquidity through contracts with the absolute minimum attack surface.

Primitives themselves may occasionally need to be replaced, perhaps due to significant functional or efficiency improvements brought about by future designs, or because potential bugs are discovered. The good news here is that if someone develops a better way to do a primitive, most of the protocols and service providers above will be able to migrate their users to the new and improved primitive because the higher level The service has been explicitly designed to be modular.

Again, is it worth it?

I think so.

Blockchain itself is very inefficient compared to various forms of centralized databases and services. We use them because we believe that the power of permissionless access and composability -- and the ability to choose to keep our own wealth for ourselves or choose a service provider we trust -- more than compensates for the challenges we face as users. cost and hassle.

We are faced with a similar choice when choosing how to structure our DeFi protocol: Do we want a protocol that delegates decisions about all user parameters and external dependencies to a small group of delegates who bother to participate in governance? Coin holders?

Or choose which ones focus on empowering market participants? Let users make their own decisions, or choose other protocols and service providers, to decide on their own behalf, without imposing those decisions on everyone they wish to transact with?

We can rely on a centralized point of failure. Alternatively, we can choose to increase robustness through stack layering diversity and modularity.

Those of us working in this industry have chosen to work on promoting the development of decentralized, permissionless, composable protocols, believing that eventually their advantages over traditional centralized, permissioned systems will become undeniable. Likewise, I believe people will come to appreciate the modular, layered approach to DeFi protocol design as they provide improvements in security and resilience.

Remember: we're not here to build something 50% better than what came before; we're to build something 50 times better.

Whether or not you believe that oracle-free or layered protocol designs are the future, I hope everyone can agree that security in DeFi is not a difficult problem to solve. If we never improve on security, encryption will never fall out of niche status.

In addition to the protocol design changes suggested above, there are a series of other concrete steps we can take to advance security concerns. Stay tuned for future articles in this series that will explore the potential and challenges around some of the themes.