Author: YBB Capital Researcher Ac_Core
Word count: Over 7000 Read time: 15 minutes
Introduction
Oracle is an important factor in the world of DeFi. Although the security of different protocols is usually inherited from the underlying smart contract network, its normal operation still relies on oracles. If the oracle of a protocol is attacked or compromised, the entire protocol can be manipulated. Recently, new DeFi creators are creating new narratives by designing novel lending and derivative architectures, and one common change in these protocols is no longer relying on oracles.
- Dialogue with Standard Crypto Partners Diverse New Narratives Emerge, Now is the Best Bear Market Cycle in History
- With the support of the Ethereum Foundation twice, will EthStorage become the storage center of Ethereum?
- Discussion on Jurisdiction of Cryptocurrency Cases Which domestic public security agencies can be involved in exchange cases?
Risks and Fixes in DeFi
The greatest appeal of DeFi is its decentralization. It is, in a broad sense, an open financial system for permissionless payments. Compared to traditional finance, its rules, profits, and even risks are publicly disclosed in a more “obscure” manner, but it still has a high degree of openness.
However, after several years of development, the DeFi sector has suffered billions of dollars in thefts[1]. Even the most fervent believers constantly question whether it can become the mainstream of future finance. In 2022 alone, hackers stole more than $3.8 billion through DeFi protocols and cross-chain bridges, making it the year with the highest amount of theft in crypto history. If we want a larger population to enter the crypto world and rely on DeFi in the future, security is the primary consideration.
Source: Chainalysis
Risks and “Primitives” of Oracle
Nascent believes that the concept of “Oracle-less protocol” will fundamentally provide a more robust and secure technical architecture for DeFi. Nowadays, DeFi hopes to define itself as “primitives” and wants more teams to build products or combine protocols on top of them. Once the contract is mixed with any external dependencies, it will inherit all relevant risks. At the same time, in order to support a larger system ecology, the contract will be upgraded. The variables involved in this managed upgrade will include the current and future changeable environments, bringing more risk factors. As the name suggests, the introduction of Oracle creates a dependency on external data, which can bring potential risks. For this reason, Dan Elitzer proposed a new definition: to meet the conditions of “primitives,” in addition to contracts deployed on the blockchain, they should not rely on any external factors, such as governance, contract upgradability, and oracles.
But the reality is that DeFi protocols that meet this basic definition are very rare today, with the most representative being Uniswap V1. However, even Uniswap V2 and V3, which align with the definition proposed by Dan Elitzer, do not qualify from a security perspective because they allow governance over certain functionalities, such as closing protocol fees and introducing fee tiers for pools.
Nevertheless, this narrow governance functionality has not resulted in systemic risks due to large-scale upgrades in other protocols. Therefore, the reason for the tremendous success of all versions of Uniswap so far is the absence of two critical factors: Oracles and on-chain governance.
There is no doubt that Uniswap is the leader in decentralized trading, achieving great success and spawning numerous experiments with decentralized exchanges. For example, Uniswap V3 introduced the concept of non-fungible liquidity positions, allowing liquidity providers (LPs) to concentrate their liquidity within a specific range. This enables LPs to capture a larger share of trading fees generated within that range and profit from it, but it also results in uncompensated losses due to price fluctuations. As a result, capital is used more efficiently, and there is specialization in the LP sector of the market. This has led to the development of a series of position management tools, such as Arrakis, Gamma, and Sommelier. While this is very friendly to DEXs, lending protocols still require oracles.
In March of this year, Euler Finance, a lending protocol, suffered a hacker attack resulting in a loss of up to $200 million. It allows users to post collateral and borrow with some unique features. In short, the problem occurred in a specific function that was not properly security-checked, allowing users to disrupt the fundamental invariants of the lending market. For more details on this attack, please refer to [2].
For lending protocols, eligible collateral is limited to assets with reliable price feedback from oracles. Loan parameters, such as loan-to-value ratios [3], are governed by the protocol, so any bad debts are the responsibility of the protocol rather than individual borrowers. Similarly, derivative protocols that rely on oracles for pricing lack internal price discovery mechanisms and are easily affected by price lag and lack of updates, severely limiting their scale and user experience. As mentioned earlier, this also explains why trader Avraham Eisenberg was able to successfully attack Mango Markets and withdraw $116 million from the cryptocurrency trading platform.
Why Uniswap is currently secure
AMMs can have the simplest fundamental invariant from any DeFi primitive source code: tokenBalanceX * tokenBalanceY == k (constant product). For example, the LianGuaiir interface in Uniswap V2 is implemented based on the following four function invariants:
Mint: Add to k;
Burn: Subtract from k;
Swap: Move x and y while keeping k constant;
Skim: Adjust tokenBalanceX * tokenBalanceY to equal k.
The Security Path of Uniswap V2: a simple core invariant that all functions serve. The only controversial aspect is the governance mode that allows the fee switch to be toggled, but this does not touch the core invariant, only affecting the distribution of token balance ownership. It is precisely because of this simplicity in security (non-upgradable smart contracts and basic invariants) that Uniswap itself has never been hacked.
Rebuilding Loan Protocols
Source: Author Balakov
Recently, we have noticed the emergence of many projects for non-oracle loan protocols, such as Ajna, Ethereum Credit Guild, MetaStreet’s Automated Tranche Maker, and the hybrid protocol Blend launched by Blur and LianGuairadig [4].
Unlike traditional DeFi lending markets, Gauntlet does not require collateral or a single universal oracle like Chainlink to provide “real” asset price sources for all users and protocol functions. Instead, borrowers need to assess risks and decide on a certain collateral requirement from the lender, and they must update their loan criteria when asset prices change. In general, borrowers choose the designated collateral they are willing to accept, such as BAYC Token and individual Bored Ape NFTs, the reference assets (such as USDC) they are willing to provide as collateral, and the ratio of the reference asset to the collateral asset that they will require for liquidating the borrower. Lastly, borrowers can publish their collateral and borrow reference assets at the current market rate.
It should be noted that since both the borrower and the lender have agreed that the liquidation of the loan is determined based on the unit quantity of each asset rather than the dollar price ratio, no oracle is required. However, if the relative dollar value of any asset changes, the lender will adjust the terms of the current or future loans to achieve a collateral ratio that they deem safe.
The biggest advantage of these approaches is that the protocol is essentially bankruptcy-proof. This is because each borrower is ultimately responsible for the solvency of their own loans, so there is no concept of “bad debt” that may need to be borne by the DAO treasury/insurance fund or resolved among lenders.
Blur’s Blend hybrid protocol assumes “the existence of more sophisticated lenders who can participate in complex on-chain and off-chain protocols, assess risks, and use their own funds.” This makes sense in the context of Blur as a primary trading venue for professional NFT traders, but it appears much more complex for ordinary users compared to borrowing on Aave or Compound.
A New Face Without Oracle
According to Chase Devens, a researcher at Messari, the definition architecture of oracle-less can be divided into two categories: peer-to-peer and hybrid types based on AMM. The main characteristics of these two types are as follows:
- Peer-to-peer
Supports any type of on-chain collateral
Users bear the loan parameters and default risk (no longer contract risk), borrowers no longer define interest rates and LTV parameters, but decide the value comparison themselves, and removing the oracle from the protocol means that these loans can be created with any on-chain collateral.
Active management of positions is required to ensure that the provided liquidity is effectively utilized. Users must actively manage their positions in a similar way to concentrated liquidity positions in Uniswap V3.
- Hybrid type based on AMM (lending/derivatives-LPs liquidity providers)
Supports any type of on-chain collateral
The underlying LP position provides pricing data for liquidation and derivative contracts and is also the main market for liquidation. This allows the protocol to calculate the results of liquidation and derivative contracts from its underlying liquidity pool. Essentially, the LP position itself acts as an oracle. In addition, these LP positions provide a primary market for liquidating protocol inventory during liquidation or contract expiration without the need to liquidate collateral on external platforms.
For example:
Ajna.finance
Ajna is a lending protocol designed specifically for EVM, without governance, permissions, or external price feeds (oracles). It can be used to borrow against our entire investment portfolio, including NFTs. Two core issues that other lending projects have reached a critical mass are: (1) token governance systems are not sufficient to analyze complex risks, and (2) using external price feedback (oracles) restricts the asset range to “blue-chip” assets with liquid secondary markets. These shortcomings have caused catastrophic losses in the DeFi lending market and limited the ability to support new assets. Ajna solves these problems through some key innovations:
(1) Asset pricing provided by the borrower: When borrowers use the Ajna protocol, they tell the contract the price at which they are willing to collateralize the asset. This effectively allows them to input their own lifecycle value and transform it from governance parameters to market parameters;
(2) Automatic rate discovery: In each Ajna market, there is an equilibrium state determined by internal indicators. If the market is out of balance, anyone can change the exchange rate by 10% every 12 hours. If not, no changes are made;
(3) Liquidation collateral: Since Ajna has no oracle, it relies on users to tell it when to liquidate the loan. This is achieved by requiring liquidators to post collateral to trigger liquidation. If they are honest, they are rewarded. If not, they are punished.
So what is the significance? These innovations allow Ajna to serve the “entire” ecosystem. Anyone can create a lending market with any asset (even NFTs). No more laborious governance processes and no more worries about liquidity, secondary markets, and oracles.
Blend
Source: Achal Srinivasan, Kirby
Blend is a peer-to-peer permanent lending protocol that supports any collateral, including NFTs. It matches users with borrowing intentions with lenders willing to provide competitive rates through a complex off-chain quoting protocol.
By default, Blend loans have fixed rates that never expire. Borrowers can repay at any time, and lenders can exit their positions by triggering a Dutch auction to find new lenders at a new rate. If the auction fails, the borrower will be liquidated, and the lender will take possession of the collateral. It has four main characteristics: no oracles, no expiration, liquidity, and peer-to-peer:
- No Oracles
Many DeFi protocols require oracles to determine liquidation positions or timing for interest rate adjustments. For example, the price of an NFT is difficult to objectively measure, and timely updates of the floor price on-chain are challenging to observe. These solutions usually involve a trusted party or transaction manipulation. The Blend protocol avoids any oracle dependencies in the core protocol, allowing the interest rate and loan-to-value ratio to be determined by the lender’s desired conditions, with liquidation triggered by the failure of the Dutch auction;
- No Expiration
Some DeFi protocols only support debt positions with expiration dates. This is inconvenient for borrowers as they need to remember to close or adjust positions before the expiration (otherwise, they may face penalties such as NFT confiscation). The manual process of adjusting positions also consumes gas, reducing the profitability of borrowing and lending. As long as there are lenders willing to lend the amount based on the collateral, Blend will automatically adjust the loan position, and on-chain transactions are only required when interest rates change or one party wants to exit the position;
- Liquidity
Some protocols do not support pre-expiration liquidation, which is convenient for borrowers and reasonable in many use cases. However, this effectively gives borrowers a put option, and lenders need to make choices from higher interest rates/lower loans within a shorter expiration time to avoid the risk of liquidation. In Blend, as long as the lender triggers a refinancing auction and no one is willing to take over the debt at any interest rate, the NFT can be liquidated;
- Peer-to-Peer
Some protocols pool lenders’ funds and attempt to manage their assets for them. This means heavy reliance on on-chain or centralized management to set parameters. Blend adopts a peer-to-peer model, and each loan is individually matched. It does not optimize the simplicity of the lending model but assumes the existence of more complex borrower capabilities to participate in both on-chain and off-chain protocols, giving greater control over their assets.
What is the FREI-PI Pattern?
The FREI-PI pattern, as explained by Nascent member Brock Elmore, stands for “Function Requirements-Effects-Interactions + Protocol Invariants LianGuaittern”. The SoloMargin contract of dYdX serves as an excellent example of the FREI-PI pattern. It is a lending market and leverage trading contract, and it is the only lending market in the early stages that has no market-related vulnerabilities.
When reviewing the code below, pay attention to the following abstract concepts:
Input requirements (_verifyInputs)
Operations (data transformation, state manipulation)
State requirements (_verifyFinalState)
Image Source: Brock Elmore
The commonly used Checks-Effects-Interactions (CEI) pattern is still being executed. However, it is important to note that CEI with additional checks is not the same as FREI-PI. Although they are similar, they serve different goals. Therefore, developers should understand their differences: FREI-PI is a high-level abstraction for protocol security, while CEI is a high-level abstraction for functional security.
What is interesting about this contract structure is that users can perform multiple operations consecutively according to their own wishes, including deposits, loans, trades, transfers, clearings, etc. We assume that three different tokens are deposited, and the fourth token is withdrawn and the account is settled. This series of operations can be completed with just one click.
This is the power of FREI-PI: as long as the core lending market invariants are valid at the end of the call, users can do whatever they want within the protocol. For this contract, this will be executed in _verifyFinalState, checking the collateral status of each affected account to ensure that the protocol is better than it was at the beginning of the transaction.
This function also includes some additional invariants, which are supplementary to the core invariants and help implement auxiliary functions such as closing the market. However, it is the core checks that truly guarantee protocol security.
Another challenge of FREI-PI is the entity-centric concept. Taking the lending market and hypothetical core invariants as an example, users cannot take any actions that would put any account into an insecure collateral state. Technically, this is not the only invariant, but it is the only invariant for users (understood as the core protocol invariant, as user invariants are the core protocol invariants). There are usually two additional invariants in lending markets:
1. Oracle
In general, Chainlink is a good choice, as its main function is to provide accurate and relatively real-time information, which can meet the requirements of most invariants. In rare cases where manipulation or unexpected situations occur, it may be beneficial to have safeguards that sacrifice real-time accuracy to ensure accuracy (such as checking if the last known value is hundreds of percentage points higher than the current value). However, Cream Finance has still experienced a $130 million attack. For more information on oracles, please refer to “Manipulating Uniswap V3 TWAP Oracle”.[5]
2. Governance
Governance is the trickiest invariant because it is difficult to be subject to conditional constraints and most of its role is to change other invariants, and some governance operations cannot be verified through FREI-PI. Taking the governance operation that Compound carried out in August 2022 to disrupt the cETH market as an example, this upgrade violated the invariant of the oracle. For more details, please refer to [6].
In practice, each additional invariant makes the protocol more difficult to protect, so it is better to have fewer invariants. Therefore, complexity is dangerous, and the most important invariant is the core invariant of the protocol. However, as mentioned above, there may also be entity-centric invariants that must meet the requirements of the core invariant. The simplest/minimal set of invariants may be secure.
Summary: The Future of DeFi
Is it the best solution to build DeFi on un-upgradable source code (Primitives) and without oracles? After all, the flexibility and usability brought by governance, upgradability, and oracles have also led to the market size of the entire DeFi protocol reaching billions of dollars. According to Dan Elitzer, a member of Nascent: governance, upgradability, and oracles are not inherently bad. On the contrary, these elements have great practical value in a broader context, but they also increase the probability of protocol attacks.
Under the premise of updating functionality or improving efficiency according to demand, the source code (Primitives) itself can also be occasionally replaced. When choosing how to create a DeFi protocol, there are two important choices to be made: entrusting all users’ data and the dependence on external conditions to a relatively centralized single protocol and entrusting it to a small number of token holders willing to participate in governance? Or attach importance to the ownership of each participant in the market and let users decide the protocol and service providers themselves?
Participants and developers in the entire industry are committed to building a more decentralized, permissionless, and highly composability DeFi to enhance the security and resilience of the entire industry. Regarding the future development direction of DeFi, we hope that it can continuously occupy the market share of traditional finance in a safer and more efficient operating manner.
Explanations and References:
[1] https://rekt.news/leaderboard/
[2] https://medium.com/@omniscia.io/euler-finance-incident-post-mortem-1ce077c28454
[3] https://www.investopedia.com/terms/l/loantovalue.asp
[4] https://www.paradigm.xyz/2023/05/blend
[5] https://github.com/euler-xyz/uni-v3-twap-manipulation/blob/master/cost-of-attack.pdf
[6] https://medium.com/chainlight/the-suspension-of-compound-finances-ceth-market-causes-and-solutions-b106c2e1c922
https://www.nascent.xyz/idea/youre-writing-require-statements-wrong
https://www.nascent.xyz/idea/why-defi-is-broken-and-how-to-fix-it-pt-1-oracle-free-protocols
Like what you're reading? Subscribe to our top stories.
We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!
