New DeFi narrative? Interpretation of the new smart contract security model without Oracle protocol

Author: YBB Capital Researcher Ac_Core

Word count: This article exceeds 7000 Reading time: 15 minutes

Preface

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 destroy, 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, although its rules, profits and even risks are relatively "obscure" The way is open, but still has a very strong degree of openness.

But after several years of development, the DeFi field has also suffered billions of dollars in theft [1] , even the most fanatical believers will continue to question whether it can become the mainstream of future finance. Among them, in 2022 alone, the funds stolen by hackers through DeFi protocols and cross-chain bridges exceeded 3.8 billion US dollars, which is also the year with the largest amount of theft in the history of encryption. If you want to allow a larger group to enter the encrypted world and rely on DeFi in the future, security is the primary consideration.

Source: Chainalysis

Oracle risk and "source code"

Nascent believes that the concept of "No Oracle Protocol" will fundamentally provide DeFi with a more robust and secure technical architecture. Today, DeFi prefers to define itself as "Primitives", and hopes that more teams will build products or combined protocols on top of 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 management-style upgrade variable will involve The current and future of the changeable environment brings more risk factors. As the name implies, the introduction of Oracle creates a dependency on external data, and this relationship will bring potential risks. For this reason, Dan Elitzer proposed a new definition: in order to meet the conditions of source code (Primitives), it cannot rely on any external factors except the contract deployed on the blockchain, such as: no governance, contract upgradeability and oracle machine .

But the reality is that DeFi protocols that meet this basic definition are very rare today, the most representative of which is Uniswap V1, but from the perspective of security, even Uniswap V2 and V3 that are consistent with the definition proposed by Dan Elitzer above Nor are they eligible, as they allow for governance over certain features, such as closure of protocol fees and fee tiers for introduction into pools.

Having said that, this narrow governance function does not introduce systemic risk due to the large-scale upgrades that exist in other protocols, so the reason for the great success of Uniswap in all versions so far is that it does not have the two keys of 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 it, but there will also be free 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 great for DEXs, lending protocols still require oracles.

In March of this year, the Euler Finance lending agreement was hacked, and the amount of loss was as high as 200 million US dollars. It allows users to post collateral and borrow money, and has some unique features. In short it's a problem that occurs in a specific function without security checks for it, allowing users to break fundamental invariants of the lending market. For the detailed process of this attack, please read [2] 。

For lending protocols, eligible collateral is limited to assets with reliable oracle price feeds. Loan parameters (such as loan-to-value [3] ) is governed by its protocol, so any bad debts are the responsibility of the protocol rather than individual lenders. Likewise, derivatives protocols that rely on oracles for pricing without internal price discovery mechanisms are vulnerable to price lags, 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 siphon $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 (like 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: readjust tokenBalanceX * tokenBalanceY to be equal to k.

The safe way of Uniswap V2: a simple core invariant, all functions serve this purpose. The only controversial thing is that it can toggle the governance model of the fee switch, but this will not touch the core invariant, just affect the distribution of token balance ownership, and it is precisely because of their simplicity in security (non-upgradeable smart contracts and fundamental invariants), Uniswap itself has never been hacked.

Rebuild Loan Protocol

Source: Author Balakov

Recently, we have found that there are many projects for lending protocols without oracle machines, such as Ajna, Ethereum Credit Guild, MetaStreet's Automated Tranche Maker, and Blend, a hybrid protocol jointly launched by Blur and Paradig. [4] 。

Unlike traditional DeFi lending markets, Gauntlet does not set collateral, nor does it have a single universal oracle like Chainlink that provides a "true" source of asset prices for all users and protocol functions. Instead borrowers need to assess risk and decide to require certain collateral from borrowers, and must update their borrowing criteria as asset prices change. Generally speaking, the way it works is that the borrower chooses the designated collateral they are willing to accept, such as BAYC Token and individual Bored Ape NFT, etc., they are willing to provide the reference asset (such as USDC) that the borrower uses as collateral, and they will The ratio of reference assets to collateral assets that require the borrower to be liquidated. Finally the borrower can post collateral and borrow the referenced asset at the current market rate.

Note that no oracle is required since the lender and borrower have agreed that the liquidation of the loan is determined based on the number of units of each asset rather than the ratio of 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 what they consider a safe collateralization ratio.

The biggest advantage of these methods is that the protocol is practically indestructible. This is because each lender is ultimately responsible for the solvency of their own loan, so there is no concept of "bad debt" which may be borne by a DAO treasury/insurance fund, or between lenders to process.

Blur's Blend protocol assumes "the existence of more sophisticated lenders who can participate in complex on-chain and off-chain agreements, 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 for Oracle

According to the definition of Messari researcher Chase Devens, the definition architecture without oracle 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

Users assume the loan parameters and assume the risk of bad debts (no longer contractually assumed risk), borrowers no longer define the interest rate and LTV parameters, but decide the value comparison themselves, and the removal of oracles 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 provided liquidity is effectively utilized, users must actively manage their positions in a manner similar to Uniswap V3's centralized liquidity locations.

• AMM-based hybrid type (loan/derivatives—LPs liquidity provider)

Supports any on-chain collateral type

The underlying LP location provides pricing data for clearing and derivative contracts, and is also the primary market for liquidation. Enabling the protocol to calculate the outcome of liquidations and derivative contracts from its underlying liquidity pool, essentially the LP position acts like an oracle itself. Additionally, these LP locations provide a primary market for offloading protocol inventory during liquidation or contract expiration without the need to go to an external platform to liquidate collateral.

for example:

Any.financial

Ajna is a lending protocol designed for the EVM, with no governance, permissions, or external price feeds (oracles). It can be used to borrow and lend our entire portfolio (including NFTs). Other lending projects have reached critical mass with two core issues: (1) The token governance system is insufficient to analyze complex risks (2) The use of external price feeds (oracles) limits the scope of assets to a liquid secondary market "Blue Chips". These flaws have caused catastrophic losses in the DeFi lending market and limited the ability to support new assets. Ajna addresses these issues with a few key innovations:

(1) Lenders provide asset pricing: When lenders use the Ajna protocol, they tell the contract how much they want to mortgage assets. This effectively lets them input their own lifetime value and turns it from a governance parameter into a market parameter;

(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, make no changes;

(3) Liquidation margin: Since Ajna has no oracles, it relies on users to tell it when to liquidate loans. This is achieved by having liquidators post margins to trigger liquidation. If they are honest, they will be rewarded. If not, they are punished.

So what's the point? These innovations allow Ajna to serve the "whole" ecosystem. Anyone can create a lending market with any asset (even NFTs). No more painstaking governance processes and no 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 borrowers with lenders willing to offer competitive interest rates through a complex off-chain quotation protocol.

By default, Blend loans have a fixed interest rate 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 rates. If the auction fails, the borrower is liquidated and the lender takes possession of the collateral. The whole has four characteristics: independent of oracle, unlimited, mobile, and peer-to-peer:

• NO ORACLE

Many DeFi protocols need oracle machines to determine the timing of liquidating positions or determining interest rates. Taking NFT as an example, its price is difficult to be measured objectively, and timely floor price updates are also very difficult to be observed on the chain. This solution usually involves to a trusted party or transaction manipulation. The hybrid agreement avoids any oracle dependence in the core agreement, allowing the interest rate and loan ratio to be determined by the willingness of the lender, and the final liquidation is triggered by the failure of the Dutch auction;

• no limit

Some DeFi protocols only support debt positions with a maturity. This is inconvenient for borrowers, who need to remember to close or adjust positions before maturity (or risk penalties such as forfeiting NFTs). The process of manually adjusting positions also consumes Gas, which also reduces the income generated by lending. As long as there is a lender willing to lend this amount against the collateral, Blend will automatically adjust the borrowing position, and the on-chain transaction is only required when the interest rate changes or one of the parties wants to exit the position;

• Flowable

Some protocols do not support liquidation before maturity, which is more convenient for borrowers and makes sense in many use cases. But this is effectively giving the borrower a put option, and the lender needs to choose from a higher rate/lower loan with a shorter maturity 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 when no one is willing to take over the debt at any interest rate;

• peer to peer

Some of these agreements pool lenders' money together and try to manage the assets for them. This means relying heavily on on-chain or centralized governance to set parameters. Blend adopts a peer-to-peer model, and each loan is individually matched. It does not optimize the simplicity of the loan method but assumes that there are more complex borrowers capable of participating in complex on-chain and off-chain agreements. Thus having greater authority to control their own assets.

What is FREI-PI mode

According to the FREI-PI pattern explained by Nascent member Brock Elmore: "Function Requirements-Effects-Interactions + Protocol Iniants pattern", here the SoloMargin contract (source code) of dYdX is For example, this is a loan market and a contract for leveraged transactions, 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.

Notice the following abstractions when looking at the code below:

input requirements ( _verifyInputs )

操作 ( data transformation, state manipulation )

State requirements ( _verifyFinalState )

Source: Brock Elmore

The usual Checks-Effects-Interactions here are still executed. 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 thing about this contract structure is that users can continuously perform multiple operations according to their own wishes, including: deposit, loan, transaction, transfer, liquidation, etc. We assume that 3 different Tokens are deposited, and the 4th Token is withdrawn and the account is cleared. 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 of each affected account to ensure that the agreement is better than when the transaction was 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 keep 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 machine

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 accidents, it may be beneficial to have less real-time safeguards for accuracy (such as checking that the last known value is hundreds of percent greater than the current value). Still, Cream Finance saw a $130 million attack. For more information about oracles, please refer to: Manipulating Uniswap V3 TWAP oracles [5] ；

2. Governance

Governance is the trickiest invariant because it is hard to be conditional 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 disrupted the cETH market in August 2022 as an example. This upgrade violates the invariant of the oracle machine. Read for details [6] 。

In practice, each additional invariant makes the protocol harder to protect, so there should be as few as possible. 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. requirements, the simplest/smallest set of invariants is likely to be safe.

Summary: The future of DeFi

Is it the best solution to build DeFi on non-upgradeable source code (Primitives) and break away from the oracle? After all, the flexibility and ease of use brought about by the current DeFi protocol relying on governance, upgradeability, and oracle machines has 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 value of the agreement. attack probability.

On the premise of updating functions or improving efficiency according to requirements, the source code (Primitives) itself can also be replaced occasionally. When choosing how to create a DeFi protocol, you will face two important choices: hand over all user data and external conditions to a more 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 the agreement and service provider themselves?

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 safer and more efficient way.

Explanation and references:

[1]

[2]

[3]

[4]

[5]

[6]