Original author: YBB Capital Researcher Ac_Core
foreword
Oracle (oracle machine) is an important factor in the DeFi world. Although the security of different protocols is usually inherited by the underlying smart contract network, its normal operation still depends on the oracle machine. If the oracle machine of a protocol is attacked Or destroyed, then the entire agreement will be manipulated. Recently, new DeFi creators are creating new narratives by conceiving new lending and derivatives structures, and the change in these protocols is that they no longer rely on oracles.
DeFi Risks and Fixes
The biggest charm of DeFi comes from: decentralization. It is an open financial system with no permission payment agreement in a broad sense. Compared with traditional finance, its rules, profits and even risks are all in a more obscure The approach is public, but still very open.
However, after several years of development, the DeFi field has also suffered billions of dollars in theft [1], and even the most ardent believers will continue to question whether it can become the mainstream of finance in the future. Among them, in 2022 alone, hackers stole more than $3.8 billion through DeFi protocols and cross-chain bridges, which was also the year with the largest amount of theft in crypto history. If you want to allow a larger group to enter the crypto world and rely on DeFi in the future, security is the primary consideration.
Source: Chainalysis
Oracles Risks and Source Code
Nascent believes that the concept of “Oracle-less Protocol” will provide a fundamentally more robust and secure technical architecture for DeFi. Nowadays, DeFi prefers to define itself as “Primitives” and hopes that more teams will build products or combination protocols based on them. Once the contract is mixed with any external dependencies, they will inherit all related risks. At the same time, the contract will be upgraded in order to carry a larger system ecology, and this managed upgrade variable will involve The present and future changes in the environment bring more risk factors. As the name suggests, the introduction of Oracle creates dependencies on external data, and this relationship brings potential risks. For this reason, Dan Elitzer proposed a new definition: in order to qualify as source code (Primitives), it cannot rely on any external factors other than the contract deployed on the blockchain, such as: no governance, contract upgradeability and oracles .
But the reality is that DeFi protocols that meet this basic definition are very rare today. The most representative of them is Uniswap V1, but from a security perspective, even Uniswap V2 and V3 are consistent with the definition proposed by Dan Elitzer above. Also not eligible as they allow for governance of certain features such as closure of protocol fees and fee tiers introduced into the pool.
Having said that, this narrow governance function does not cause systemic risks due to large-scale upgrades that exist in other protocols, so the reason for the huge success of Uniswap in all versions so far is that there are no Oracle and full chain. factor.
There is no doubt that Uniswap is the leader of decentralized exchanges. It has achieved great success, and on this basis, many experiments of decentralized exchanges have been born. For example, Uniswap V3 introduced the concept of non-homogeneous liquidity positions, allowing liquidity providers (LPs) to concentrate their liquidity within a specific range, which allows LPs to capture more of the transactions generated within this range. A large share of transaction fees and profit from them, but there will also be uncompensated losses as the price fluctuates. This led to a more efficient use of capital and the specialization of the LP segment of the market, leading to a range of position management tools such as Arrakis, Gamma and Sommelier. While this is very friendly to DEXs, lending protocols still require oracles.
In March this year, the Euler Finance lending protocol was hacked, resulting in losses of up to $200 million. It allows users to post collateral and borrow money, and has some unique features. Simply put the problem occurs in a specific function and there is no security check on it, allowing users to break the basic invariant of the lending market. Please read [2] for the detailed process of this attack.
For lending protocols, eligible collateral is limited to assets with reliable oracle price feedback. Loan parameters (such as loan-to-value ratio [3]) are governed by its agreement, so any bad debts are the responsibility of the agreement rather than the individual lender. Similarly, derivatives protocols that rely on oracles for pricing lack internal price discovery mechanisms and are susceptible to price lags and no updates, severely limiting their scale and user experience. As mentioned in the preface, this also explains exactly why trader Avraham Eisenberg was able to successfully attack Mango Markets and drain $116 million from the cryptocurrency trading platform.
Why Uniswap is safe now
AMM can have the simplest basic invariant in any DeFi source code (Primitives): tokenBalanceX * tokenBalanceY == k (such as constant product). For example, the Pair 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, keep k unchanged;
Skim: Rescale tokenBalanceX * tokenBalanceY so that it equals k.
Uniswap V2’s path to security: a simple core invariant that all functions serve. The only thing that is controversial is that it can toggle the governance mode of the fee switch, but this does not touch the core invariant, just affects the distribution of token balance ownership, and it is precisely because of this simplicity in their security (not upgradeable) smart contracts and basic invariants), Uniswap itself has never been hacked.
Reconstruction Loan Agreement
Source: Author Balakov
Recently, we have seen the emergence of many projects for oracle-less lending protocols, such as Ajna, Ethereum Credit Guild, MetaStreet’s Automated Tranche Maker, and the hybrid protocol Blend launched by Blur and Paradig [4].
Unlike traditional DeFi lending markets, Gauntlet does not set collateral, and there is no single-purpose oracle like Chainlink to provide a source of “real” asset prices for all users and protocol functions. Instead borrowers need to assess risk and decide to require a certain amount of collateral from borrowers, and must update their borrowing criteria when asset prices change. Generally speaking, the way it works is that borrowers choose the designated collateral they are willing to accept, such as BAYC Token and individual Bored Ape NFTs, etc., the reference assets (such as USDC) they are willing to provide to the borrower as collateral, and the The ratio of quoted assets to collateral assets that require a borrower to be liquidated. Finally the borrower can post collateral and borrow the referenced asset at current market rates.
It is important to note that an oracle is not required since the borrowers and lenders have agreed that the loan will be liquidated based on the ratio of the number of units of each asset rather than the dollar price. However, if the relative dollar value of either asset changes, lenders will adjust the terms of current or future loans to achieve a collateral ratio they feel is safe.
The biggest advantage of these methods is that the agreement is virtually insolvent. This is because each lender is ultimately responsible for the repayment of their own loan, so there is no"bad debts"concept, and this"bad debts"May be borne by the DAO treasury/insurance fund, or handled between lenders.
Blurs Blend protocol assumes"More sophisticated lenders exist that are able to participate in complex on-chain and off-chain protocols, assess risk, and use their own funds". This makes sense in the context of Blur being the primary trading venue for professional NFT traders, but for the average user it seems a lot more complicated than borrowing and lending on Aave or Compound.
No new faces at Oracle
According to the definition of Messari researcher Chase Devens, the definition architecture of the oracle-less machine can be divided into two categories, namely peer-to-peer (Peer-to-Peer) and AMM-based hybrid type. The main features of both of them are as follows:
peer to peer
Supports any on-chain collateral type
The user assumes the loan parameters and bears the risk of bad debts (no longer the contract assumes the risk), the borrower no longer defines the interest rate and LTV parameters, but decides the value comparison himself, and the removal of the oracle from the mechanism of the protocol means that these loans can be made by Any on-chain collateral creation.
Positions need to be actively managed, and to ensure that the liquidity provided is effectively utilized, users must actively manage their positions in a manner similar to Uniswap V3’s centralized liquidity position.
AMM-based hybrid type (Lending/Derivatives—LPs Liquidity Provider)
Supports any on-chain collateral type
The underlying LP position provides pricing data for clearing and derivatives contracts and is also the primary market for liquidation. Enabling the protocol to calculate the outcomes of liquidation and derivative contracts from its underlying liquidity pool, the LP position essentially acts like an oracle in itself. Additionally, these LP positions provide a primary market for offloading protocol inventory during liquidations or contract expirations without the need to go to an external platform to liquidate collateral.
for example:
Ajna.finance
Ajna is a lending protocol designed specifically for EVM, with no governance, permissions or external price feeds (oracles). It can be used to lend against our entire portfolio (including NFTs). Two core problems have caused other lending projects to reach a critical mass of scale: (1) Token governance systems are insufficient to analyze complex risks (2) The use of external price feedback (oracles) limits the scope of assets to liquid secondary markets of blue chip stocks. These flaws have caused catastrophic losses to the DeFi lending market and limited the ability to support new assets. Ajna solves these problems through some key innovations:
(1) Lenders provide asset pricing: When lenders use the Ajna protocol, they tell the contract what price they are willing to mortgage the assets for. This effectively lets them input their lifetime value and transforms it from a governance parameter to a market parameter;
(2) Automatic interest rate discovery: In each Ajna market, there is an equilibrium state determined by internal indicators. If the market is imbalanced, anyone can change the exchange rate by 10% every 12 hours. If not, make no changes;
(3) Liquidation margin: Since Ajna does not have an oracle, it relies on users to tell it when to liquidate the loan. This is accomplished by having the liquidator post a deposit to trigger liquidation. If they are honest, they will be rewarded. If not, they are punished.
So whats the point? These innovations enable 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 perpetual lending protocol that supports any collateral including NFTs. It matches users interested in borrowing with lenders willing to provide competitive interest rates through a complex off-chain quotation agreement.
By default, interest rates on Blend loans are fixed and never expire. Borrowers can repay at any time, and lenders can exit their positions by triggering a Dutch auction to find new lenders at new interest rates. If the auction fails, the borrower will be liquidated and the lender will take possession of the collateral. The whole system has four major characteristics: it does not rely on oracles, has no deadline, is mobile, and is peer-to-peer:
No oracle
Many DeFi protocols require oracles to determine the timing of liquidating positions or determining interest rates. Taking NFT as an example, its price is difficult to objectively measure, and timely floor price updates are also very difficult to observe on the chain. This solution usually involves to a trusted party or transaction manipulation. The hybrid protocol avoids any oracle dependence in the core protocol, allowing the interest rate and loan ratio to be determined by the lender’s willingness and conditions, and the final liquidation is triggered by the failure of the Dutch auction;
no limit
Some DeFi protocols only support debt positions with maturity. This is inconvenient for borrowers, who need to remember to close or adjust their positions before maturity (otherwise they may face penalties such as confiscation of the NFT). The process of manually adjusting positions also consumes Gas, which also reduces the income generated by borrowing and lending. As long as there is a lender willing to lend the amount against the collateral, Blend will automatically adjust the borrowing position, requiring on-chain transactions only if interest rates change or one of the parties wants to exit the position;
flowable
Some protocols do not support pre-maturity liquidation, which is more convenient for borrowers and makes sense in many use cases. But this effectively gives the borrower a put option, with the lender needing to choose from a higher rate/lower loan at a shorter expiration time to avoid the risk of the position being liquidated. In Blend, as long as the lender triggers the refinancing auction, the NFT can be liquidated if no one is willing to take over the debt at any interest rate;
peer to peer
Some of these agreements pool lenders funds together and attempt to manage the assets for them. This means a heavy reliance on on-chain management or centralized management to set parameters. Blend adopts a peer-to-peer model, and each loan is matched individually. It does not optimize the simplicity of the loan method but assumes the existence of more complex borrowers with the ability to participate in complex on-chain and off-chain protocols. This gives you greater authority to control your assets.
What is FREI-PI mode
According to the FREI-PI pattern explained by Nascent member Brock Elmore: Function Requirements-Effects-Interactions + Protocol Invariants pattern, here the SoloMargin contract (source code) of dYdX is For example, this is a loan market and leveraged trading contract, which is an excellent example of the FREI-PI model. This is the only lending market in the early lending market that does not have any market-related vulnerabilities.
When looking at the code below, note the following abstract concepts:
Input requirements ( _verifyInputs )
Operation (data transformation, state manipulation)
State requirements ( _verifyFinalState )
Source: Brock Elmore
The commonly used Checks-Effects-Interactions here are still implemented. But it should be noted that Checks-Effects-Interactions with additional Checks is not equivalent to FREI-PI, although they are similar but serve different goals. To this end developers should understand the difference: FREI-PI is a high-level abstraction for protocol safety, while CEI is a high-level abstraction for functional safety.
The interesting part of this contract structure is that users can continuously perform multiple operations as they wish, including deposits, loans, transactions, transfers, liquidations, etc. We assume that 3 different Tokens are deposited, the 4th Token is withdrawn and the account is liquidated. 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 hold at the end of the call, users can do whatever they want within the protocol. For this contract, this will be performed in _verifyFinalState, checking the collateral status of each affected account to ensure that the agreement is better than when the transaction started.
There are some additional invariants included in this function that complement the core invariants and help with auxiliary functions such as closing the market, but it is the core checks that really make the protocol safe.
The entity-centric concept is another difficulty of FREI-PI, exemplified by the lending market and the assumed core invariant: users cannot take any action to put any account into an unsecured collateral state. From a technical point of view, this is not the only invariant, but it is the only invariant for users (it can be understood as still the core protocol invariant, because the user invariant is the core protocol invariant). There are usually two additional invariants in lending markets:
1. Oracle
Generally speaking, Chainlink is a good choice. Its main function is to provide accurate and relatively accurate real-time information, which can meet the requirements of most invariants. In the rare case of manipulation or accident, it may be beneficial to have lower real-time safeguards for accuracy (such as checking whether the last known value was hundreds of percentage points greater than the current value). However, there was a $130 million attack on Cream Finance. For more information about oracles, please refer to: Manipulating Uniswap V3 TWAP Oracle [5];
2. Governance
Governance is the trickiest invariant because it is hard to condition on and most of its effect is to change other invariants, and some governance cannot be verified by FREI-PI when it operates. Take Compound’s governance operation that destroyed the cETH market in August 2022 as an example. This upgrade violates the invariant of the oracle machine. For details, read [6].
In practice, each additional invariant makes the protocol more difficult to protect, so the fewer the better. Therefore, complexity is dangerous, and the most important invariants are the invariants of the core of the protocol, but as mentioned above, there will also be some entity-centric invariants, which must satisfy the requirements of the core invariants. Requires that the simplest/smallest set of invariants possible is safe.
Summary: The future of DeFi
Is it the best solution to build DeFi on non-upgradeable source code (Primitives) and away from oracles? After all, the flexibility and ease of use brought about by the current DeFi protocol relying on governance, upgradeability, and oracles have also made the entire market size reach hundreds of billions of dollars. According to Dan Elitzer, a member of Nascent: Governance, upgradeability, and oracles are not inherently bad. On the contrary, these elements have great practical value in a broader environment, but this will also increase the protocol. Attack probability.
On the premise of updating functions or improving efficiency according to needs, the source code (Primitives) itself can also be occasionally replaced. When choosing how to create a DeFi protocol, you will face two important choices: hand over all user data and external conditions to a relatively centralized single protocol, and entrust it to a small number of Token holders who are willing to participate in governance ? Or should we value the ownership of each participant in the market and let users decide on their own protocols and service providers?
Participants and developers throughout the industry are committed to building a more decentralized, permissionless, and highly composable DeFi to improve the security and resilience of the entire industry. Regarding the future development direction of DeFi, we hope that it can continue to occupy the market share of traditional finance in a more secure and efficient way of operation.
Explanation 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
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
