Why DeFi is Broken and How to Fix It, Pt 1: Oracle-Free Protocols

I love DeFi. The promise of permissionless payment protocols and an open financial system are what attracted me first to Bitcoin and then the wider world of crypto.

Reading an introduction to Uniswap in 2018 opened my eyes to the power of what was starting to happen in the part of the crypto world that would come to be known as DeFi (though I still prefer Open Finance).

But after years of repeated hacks and billions of dollars stolen, it’s reasonable for even the most ardent believers to question whether DeFi will ever be suitable for mainstream use, let alone to become a central piece of the global financial system.

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

We’ve invested heavily in security at Nascent. In 2020, we were the first investors to put a Tier 1 audit firm (Open Zeppelin) on retainer on behalf of our portfolio companies, to secure priority access to rigorous security reviews prior to launch. We were early backers of Spearbit, Code4rena, Macro, and Skylock.

We’ve also invested our time into 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, which mixes symbolic execution, abstract interpretation, and static analysis.

Through these efforts, we’ve come to believe it’s not just a question of “trying harder” on the security front. That’s necessary, but not sufficient—industry-wide, the frequency and severity of exploits is at least two orders of magnitude above what might be considered acceptable levels for mainstream adoption. 

In 2022, over $3.8B was stolen via crypto hacks, largely via exploits of DeFi protocols and bridges. While some exploits were due to disturbingly poor security posture, even protocols developed by well-regarded teams who followed current best-in-class processes were not immune.

If we want to see billions of people rely upon DeFi, we need to fundamentally rethink how protocols are designed and secured.

‍

We at Nascent think there are a range of security-related concepts that are promising and deserve further discussion and exploration.

Today, we will start by explaining the concept of “oracle-free protocols” and why we think they point to a fundamentally more robust and secure architecture for DeFi.

Modular protocols and primitives

A lot of DeFi protocols like to style themselves as “primitives,” with the hope of having other teams build products or composable protocols on top of them.

I’d like to propose a new definition: In order to qualify as a primitive, a contract must have zero external dependencies, other than those of the blockchain it is deployed upon.

This means no governance, no upgradeability, no oracles.

As soon as any external dependency has been introduced into a contract, the contract inherits any risks associated with that dependency. Governance over contract functionality implies a form of upgradeability, requiring threat models to factor in both the range of possible changes and current and future conditions under which they could be made. Oracles by definition introduce external data, and with it, all dependencies that go into delivering that data and all potential variability in its accuracy and timeliness.

A primitive should do simply what it says on the tin - no more, no less, no dependencies.

There are shockingly few DeFi protocols today meeting this definition of a primitive. Uniswap v1 is probably the best known, but even Uniswap v2 and v3–while directionally in the spirit of this definition from a security perspective–would not qualify, as they allow governance over certain functionality such as a protocol fee switch and the ability to introduce new fee tiers for pools.

That said, such narrow governance functionality does not meaningfully introduce risks in the form of the massive upgradable proxies present in many other protocols, so let’s focus in on the big wins across all versions of Uniswap thus far:

• No oracles
• Fully onchain

Uniswap overall has been hugely successful and we should all be grateful for its emergence as the dominant decentralized exchange and the further DEX experimentation it has inspired. Its rise was widely attributed to the simplicity of providing liquidity across all prices versus learning how to be a market maker, and it ultimately supplanted earlier efforts that were far more centralized or reliant on dubious token schemes. 

As the industry evolved, Uniswap launched new versions of their protocol, moving the design space to be much more similar to an order book. Uniswap v3 introduced the concept of non-fungible liquidity positions, where liquidity providers (LPs) have the ability to concentrate their liquidity within specific ranges. This allows LPs to capture a greater share of swap fees for trades within that range, but increases the divergence loss they experience as prices change. This has resulted in more efficient use of capital and professionalization of the LP portion of the market, alongside the emergence of an ecosystem of position management tools, including Arrakis, Gamma, and Sommelier.

I expect at this point that many readers are thinking “fine, that’s all well and good for DEXs, but what about lending protocols? You need oracles for lending!”

I would agree: lending does require oracles… but, as with decentralized exchanges, they can be moved outside the protocol.

Re-building lending

Recently, we’ve seen a burst of interest in new and forthcoming oracle-free lending protocols, such as Ajna, Ethereum Credit Guild, Metastreet’s Automated Tranche Maker, and Blur/Paradigm’s Blend.

Unlike traditional DeFi lending markets, there are no collateral factors set by Gauntlet governance, nor a single universal oracle such as Chainlink providing a source of “true” asset prices for all users and protocol functionality. Instead, lenders are responsible for evaluating risks and deciding how much collateral they want to require from borrowers and must update their criteria for lending as asset prices change.

The way this generally works is that lenders choose the specific asset they will accept as collateral (e.g., BAYC tokens, an individual Bored Ape NFT, etc), the quote asset (e.g., USDC) they will provide to be borrowed against that collateral, and the ratio of quote asset to collateral asset at which they will require the borrower be liquidated. Borrowers can then post collateral and borrow the quote asset at the prevailing market interest rate.

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

Here’s a key advantage to this approach: the protocols are literally incapable of being insolvent. As each individual lender ultimately has responsibility over the solvency of their own loan, there is no concept of “bad debt” that might need to be absorbed by a DAO treasury / insurance fund or socialized across lenders.

Feel safe letting someone borrow USDC against their ETH at 95% LTV? Have at it. 

Feel comfortable lending against MKR collateral, but only at a 10% LTV? No problem.

Blur’s Blend assumes “the existence of more sophisticated lenders capable of participating in complex on- and off-chain protocols, evaluating risks, and using their own capital.” This makes sense in the context of Blur as the dominant venue for professional NFT traders, but for an average user, it seems like a lot more work than lending on Aave or Compound.

Good news: it doesn’t have to be.

Other protocols or services can make it easy to maintain a consistent collateral ratio requirement, even as the price of the collateral you are lending against fluctuates. In the case of Ajna, it will be possible to use Oasis and DeFi Saver (or other protocols/services) to automate the process of adjusting the ticks you are supplying into. You could even have a vault that allows users to supply DAI or USDC and make it available to borrow against the same assets, at the same collateral factors, as on Aave, automatically rebalancing between pools to maximize lending rates. Such a vault might even use Chainlink as its oracle, enabling both a UX and risk profile for lenders that would be nearly identical to using Aave today.

But if you’re just going to layer on protocols or services that recreate the existing UX and risks of Aave, why bother building on an oracle-free protocol or primitive like Ajna?

Unified markets with security through diversity

Let me state this unequivocally: real financial institutions will never (and should never) put billions of dollars into a protocol whose safety is wholly dependent on Chainlink for security. 

There are a LOT of complexities involved in bringing off-chain data reliably on-chain, especially with the requirement of operating it in a decentralized, censorship-resistant manner. While Chainlink has done an admirable job of operating within these constraints, they have also become a potential single point of failure across all of DeFi.

Oracle-free protocols–really, protocols explicitly designed to allow users to Bring Your Own Oracle (BYOO)–offer an alternative path, particularly for sophisticated institutional users who have access to their own high-quality data feeds without the need for decentralization or censorship-resistance.

It’s entirely possible that the majority of users of oracle-free protocols like Ajna will still rely on public oracle protocols like Chainlink to help safely manage their lending or borrowing positions via tools like Oasis. But they’ll also be able to seamlessly operate in the same market as sophisticated users who decide to rely on prices from another protocol like Pyth, various zk-based oracles, the Bloomberg API, or even their own internal price calculations.

We recently saw with Ethereum itself that the ability to depend on a healthy amount of client diversity enabled downtime to be avoided. A layered approach to protocol development–with a diversity of security-critical service providers–has the potential for analogous forms of robustness to emerge within DeFi, where issues can be isolated and only affect a subset of users.

In the case of Ajna, remember that it’s not just an oracle-free protocol, it’s a primitive: it has zero governance, upgradeability, oracles, or external dependencies of any kind. This means that borrowers and lenders can each impose their own requirements, selecting their own management protocols and service providers, each with their own resulting dependencies. Some users may choose to use a service that relies on Chainlink and mirrors the collateral assets and ratios of Aave, while others may choose to use a Bloomberg API and only lend against ETH at conservative collateral ratios. 

If an incident occurs that compromises an oracle or rapidly craters the value of a single collateral asset, users who used a different oracle or did not lend against that asset would be wholly unaffected.

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

And in case you’re wondering how complex you can get building on top of primitive-like protocols: Infinity Pools is a forthcoming decentralized exchange built on top of Uniswap V3, capable of offering 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 largely built on top of immutable primitives? After all, we’ve gone from zero to hundreds of billions in swaps and loans on the basis of the flexibility and ease-of-use enabled by governance, upgradeability, and oracles.

I think it is.

Governance, upgradeability, and oracles aren’t inherently bad. To the contrary, all are quite useful in a broad range of settings. However, they do increase the attack surface of a protocol and result in most or all users of the protocol getting rekt when an exploit occurs via an attack vector these functions enable.

Moving as much logic and as many dependencies as possible out of the lowest-level primitive allows for a more robust marketplace of higher-level services to be created, while still unifying liquidity via contracts with the absolute least attack surface.

Primitives themselves may occasionally need to be replaced, either due to significant feature or efficiency improvements enabled by future designs, or to potential vulnerabilities being uncovered. The good news here is that if someone develops a better way to do a primitive, most of the protocols and service providers on top will be able to migrate their users over to a new and improved primitive because the higher-level services have been explicitly designed to be modular.

Again, is it worth it?

Yes.

Blockchains themselves are immensely 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 whether to custody our own wealth or select service providers we trust–more than make up for the costs and hassles we face as users.

We are faced with a similar choice in choosing how we build our DeFi protocols: do we want monolithic protocols, with decisions on parameters and external dependencies for all users delegated to the small group of token holders who bother to participate in governance? 

Or do we value the empowerment of individual market participants? To make their own decisions, or to choose other protocols and service providers to delegate those decisions to on their own behalf, without forcing such decisions on all those they hope to transact with? 

We can lean into centralized points of failure. Or, we can choose to add robustness through diversity and modularity at all layers of the stack.

Those of us working in this industry have chosen to dedicate our efforts to promoting the growth of decentralized, permissionless, composable protocols, believing that eventually their advantages over traditional centralized, permissioned systems will become undeniable. Similarly, I believe people will come to appreciate modular, layered approaches to DeFi protocol design for improvements to security and resilience they provide.

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

‍

Whether or not you are convinced that oracle-free or layered protocol designs are the future, hopefully we are able to agree that security in DeFi is not an intractable problem. If we never improve at security, crypto will never move beyond niche status. 

In addition to the changes in protocol design suggested above, there are a range of other concrete steps we can take to move the needle on security, today. Future posts in this series will explore the potential and challenges around topics such as circuit breakers to minimize damage from atomic exfiltration, generalized multi-party sentinel contracts, and bounties that scale with value-at-risk.

We also have some exciting announcements in store about ways that Nascent will be stepping up our support for the security of both our portfolio companies and the broader ecosystem.

Stay tuned.