Oracle manipulation risks in lending pools.

19 min readMar 13, 2024

Abstract:

Decentralized applications on blockchain require external data to make informed decisions. Blockchain oracles facilitate the communication of off-chain data to smart contracts, enabling them to execute based on external events. Lending and decentralized exchange protocols in DeFi rely heavily on oracle data to determine the value of assets and make lending decisions. However, recent attacks on lending protocols have highlighted the vulnerability of oracles to manipulation by malicious actors. In April 2022, Deus Finance was exploited, resulting in a loss of $15.7 million, while in January 2023, Mango Markets lost $100 million due to an oracle manipulation attack. These attacks emphasize the importance of robust oracle systems and the need to implement security measures to prevent manipulation. The responsibility of fetching the correct external data falls on the oracle, and if this data is not reliable, the blockchain decisions can be affected. DeFi protocols need to ensure that they have reliable oracles to prevent such attacks and ensure the security of their users’ funds. In this report we describe Oracles used in Defi specifically lending platforms, the building blocks and types of oracles, and the attacks on them through oracle manipulation. Finally, we describe a real-life Oracle manipulation attack on Solana based DEX Mango markets. We describe the series of events that took place on the Mango market platform and how the attacker was able to wash of $114 million from Mango Markets.

Overview:

Blockchains execute various consensus protocols based on the on-chain data specifically transactions. For validation of a transaction the validators utilize the transaction information like signature to arrive at a consensus. The transaction data is present on the blockchain can be used as an input for the consensus as well as running any smart contracts. However, some decentralized applications on blockchain require external data. The smart contracts use this off-chain data to take decisions on a decentralized application. Let us understand the importance of external data on blockchain through the following example: Suppose Alice bets 5 ETH that India will win in World Cup. If India wins the smart contract on Ethereum has to credit 5 ETH to Alice’s address. But how will the blockchain know who won the World Cup. The winning result is communicated to the smart contract through Blockchain Oracles which facilitates Alice’s payout. This gives smart contract the ability to execute on off-chain data. Oracle communicate data to and fro from on-chain to off-chain as well. Consider a digital vault which opens if and only if the user pays a certain amount of fees. Here the oracle can take the transaction information to the smart lock and confirm the user has paid it. Depending on the information by the oracle the vault opens.

It’s easy to deduce that there is a huge responsibility on the Oracle to fetch the right external data to the smartcontract which will inturn effect the blockchain decisions. Smart contracts power major applications in Defi such as lending protocols, asset management, decentralized exchanges (DEX), insurance and many more in a trustless as well as censorship resistant way. Out of all Defi applications lending and decentralized exchanges have locked around $51 million and $23 million respectively. Users borrow assets from lending protocols where smart contract add tokens to the user’s address. But the transaction data alone is not enough, the smart contract on lending protocols uses the market data to determine the value of the assets. The market data is not inherently present in the lending protocol therefore it uses an oracle to get this data from a decentralized exchange. Lending protocol crucially relies on oracle data for their price feeds and if these input values are fed by on-chain exchanges. The malicious actors find the oracle as an opportunity to manipulate the lending protocol to have illegitimate gains. Recent attacks on various lending protocols have highlighted the feasibility of oracle manipulation attacks. In April 2022 Deus Finance was exploited leading to a loss of $15.7 million. The attacker manipulated the DEI price and withdrew a large amount of DEI while providing small amount of collateral. Recently, a Solana based DEX Mango Markets was robed out of $100 million dollars using oracle manipulation attack. This report gives a detailed description of Oracle manipulation attacks on lending platforms. Further we will describe the exact steps of the attacker on oracle manipulation on Solana DEX.

Oracle Architecture: When a smart contract wants some external data for example exchange prices for a pair of tokens it requests the oracle. The process of fetching the data by oracle can be generalized as follows: [1] • The ground truth has to be collected by the oracle and fed to the smart contract. • These ground truths are collected in form of data sources like centralized database, sensors, humans, other smart contracts etc. • Data feeders report the off-chain data sources to an on-chain oracle system. To achieve truthful reporting reputation is awarded to these data sources. The reputation system can be based on staking a collateral or incentivization. • In the next phase the data feeders are selected. They are either centralized or decentralized.

Centralized data feeders such as Oraclezeit and PriceGeth used one data feeder. The allow list for these feeders are decided by a centralized authority. [5]
Decentralized data feeders are used in oracles such as Chainlink. The allowlist is generated through staking or voting. • Next the data is aggregated to get the final representation of the result from multiple sources. If there is wrong data at this point, then it can lead to wrong input on the oracle hence incorrect computation on the on-chain smart contract leading to intentional manipulation or unintentional errors. • Finally, the wrong input data feeders are punished in the dispute phase.

All Defi projects have different ways of implementing an oracle every one of them follows the above path while collecting data from external sources. Also, we may note that the type of data feeders that an oracle implements has a huge impact on how the data is collected and how much we can trust on them.

The oracle can be categorized into five of these forms depending on what kind of data feeders they use as well how they deliver (on-chain/ off-chain) the data to the smart contracts: [3]

Off-chain Centralized Oracle: This type of oracle simply accepts new prices from an off-chain source, typically an account controlled by the project [5]
Off-chain Decentralized Oracle: This type of oracle accepts new prices from multiple off-chain sources and merges the values through a mathematical function, such as an average.
On-chain Centralized Oracle: This type of oracle determines the price of assets using an on-chain source, such as a DEX. However, only a central authority can trigger the oracle to read from the on-chain source.
On-chain Decentralized Oracle: This type of oracle determines the price of assets using an on-chain source but can be updated by anyone. There may be some sanity checking to ensure that prices don’t fluctuate too wildly.
Constant Oracle: This type of oracle simply returns a constant value and is typically used for stablecoins. Nearly all projects mentioned above use this type of oracle for USDC due to its guaranteed peg.

Inside the Oracle All of the above oracles are basically smart contract codes which listens to the data request from other smart contracts. They can also perform computation on fetched data points.

The oracle contract exposes some functions which client contracts call when making a data request. Upon receiving a new query, the smart contract will emit a log event with details of the data request. This notifies off-chain nodes subscribed to the log (usually using something like the JSON-RPC eth_subscribe command), who proceed to retrieve data defined in the log event.

Example of an oracle

The contract defines a Request struct that contains the ID of the request, the URL of the API, the attribute to fetch, the agreed value, and a mapping of answers provided by the oracles. [5]

pragma solidity >=0.4.21 <0.6.0;

contract Oracle {
  Request[] requests; //list of requests made to the contract
  uint currentId = 0; //increasing request id
  uint minQuorum = 2; //minimum number of responses to receive before declaring final result
  uint totalOracleCount = 3; // Hardcoded oracle count  // defines a general api request
  struct Request {
    uint id;                            //request id
    string urlToQuery;                  //API url
    string attributeToFetch;            //json attribute (key) to retrieve in the response
    string agreedValue;                 //value from key
    mapping(uint => string) answers;     //answers provided by the oracles
    mapping(address => uint) quorum;    //oracles which will query the answer (1=oracle hasn't voted, 2=oracle has voted)
  }  //event that triggers oracle outside of the blockchain
  event NewRequest (
    uint id,
    string urlToQuery,
    string attributeToFetch
  );  //triggered when there's a consensus on the final result
  event UpdatedRequest (
    uint id,
    string urlToQuery,
    string attributeToFetch,
    string agreedValue
  );  function createRequest (
    string memory _urlToQuery,
    string memory _attributeToFetch
  )
  public
  {
    uint length = requests.push(Request(currentId, _urlToQuery, _attributeToFetch, ""));
    Request storage r = requests[length-1];    // Hardcoded oracles address
    r.quorum[address(0x6c2339b46F41a06f09CA0051ddAD54D1e582bA77)] = 1;
    r.quorum[address(0xb5346CF224c02186606e5f89EACC21eC25398077)] = 1;
    r.quorum[address(0xa2997F1CA363D11a0a35bB1Ac0Ff7849bc13e914)] = 1;    // launch an event to be detected by oracle outside of blockchain
    emit NewRequest (
      currentId,
      _urlToQuery,
      _attributeToFetch
    );    // increase request id
    currentId++;
  }  //called by the oracle to record its answer
  function updateRequest (
    uint _id,
    string memory _valueRetrieved
  ) public {    Request storage currRequest = requests[_id];    //check if oracle is in the list of trusted oracles
    //and if the oracle hasn't voted yet
    if(currRequest.quorum[address(msg.sender)] == 1){      //marking that this address has voted
      currRequest.quorum[msg.sender] = 2;      //iterate through "array" of answers until a position if free and save the retrieved value
      uint tmpI = 0;
      bool found = false;
      while(!found) {
        //find first empty slot
        if(bytes(currRequest.answers[tmpI]).length == 0){
          found = true;
          currRequest.answers[tmpI] = _valueRetrieved;
        }
        tmpI++;
      }      uint currentQuorum = 0;      //iterate through oracle list and check if enough oracles(minimum quorum)
      //have voted the same answer has the current one
      for(uint i = 0; i < totalOracleCount; i++){
        bytes memory a = bytes(currRequest.answers[i]);
        bytes memory b = bytes(_valueRetrieved);        if(keccak256(a) == keccak256(b)){
          currentQuorum++;
          if(currentQuorum >= minQuorum){
            currRequest.agreedValue = _valueRetrieved;
            emit UpdatedRequest (
              currRequest.id,
              currRequest.urlToQuery,
              currRequest.attributeToFetch,
              currRequest.agreedValue
            );
          }
        }
      }
    }
  }
}

The contract allows the creation of new requests by calling the createRequest function, which adds a new Request struct to the requests list and emits a NewRequest event. The function also initializes the quorum mapping with the addresses of the trusted oracles.

Oracles can provide answers to a request by calling the updateRequest function and passing the ID of the request and the retrieved value. The function checks if the oracle is in the list of trusted oracles and if it hasn’t voted yet. If the oracle is eligible, the function marks the oracle as having voted and adds the retrieved value to the answers mapping.

The function then iterates through the answers mapping and counts the number of oracles that have voted the same answer as the current one. If the number of oracles is greater than or equal to the minimum quorum required, the function sets the agreed Value of the request to the retrieved value and emits an Updated Request event.

Overall, the contract allows multiple oracles to provide answers to API requests and reach a consensus on the final result, providing a decentralized and trustless oracle service.

So far, the article answers the questions about the source from which data is collected, trust worthiness of the data and the complete working of oracles on different modes.In the next section we elaborate on how attackers use price oracles in lending protocols to gain millions of dollars illegitimately.

Oracle Manipulation Attacks on Lending pools

As described in the above section that oracles rely on data feeders for correct information. If the data feeders give incorrect data, the oracle will still forward it to the smart contracts on chain leading to catastrophizes. In practice, manipulated data feeds can cause significant damage, from unwarranted liquidations to malicious arbitrage trades.

Lending protocols and oracles

Lending protocols are smart contracts that let borrowers borrow money at a fixed rate. A pool of assets that creditors have deposited as investments is where the borrowed assets are drawn from. The loss is divided among various creditors if this pool experiences a loss as a result of a bad debt. The creditors that participated to the pool from which the loan was created will each receive a portion of the interest if the borrower repays the obligation on time. As borrowers are only public keys on a blockchain, these protocols are unable to take action against loan defaulters. To keep the protocols liquid, over-collateralization is used.

Collateralization Ratio

Collateralization ratio © is defined as: (a*Va)/(b*Vb). If the borrower does not repay the loan, the protocol allows any liquidator to pay back the borrowed asset and redeem the collateral at a discounted price. For this to be effective, during the period of the loan, C should not fall below 1. If the borrower fails to repay the loan, any liquidator can use the protocol to repay the borrowed asset and retrieve the collateral at a reduced price.

However, to make this work, the collateralization ratio © must remain above 1 throughout the loan period. If C drops below 1, the loan is undercollateralized, which can happen if the collateral loses value relative to the borrowed asset or the borrowed asset appreciates against the collateral asset. As C approaches 1, the lending protocol attempts to utilize the remaining collateral value to restore the balance with the borrowed asset.

Before the loan becomes fully undercollateralized (C < 1), it can experience a “bad health” period where C has decreased since the loan was initiated and is now dangerously close to 1 (with some allowance). To avoid the risk of complete under collateralization, the protocol provides liquidators with the opportunity to repay the loan at a discount and take possession of the remaining collateral.

This makes the protocol whole again, the liquidator gets collateral for a slightly cheaper price, and the borrower is liquidated. The borrower is thus motivated to “top-up” the collateral to make sure that the loan never becomes unhealthy.

For over-collateralization to be effective, it is necessary for the lending protocol to have knowledge of the dollar values of assets A and B, which are traded on centralized exchanges outside of the blockchain. Nowadays, lending protocols are able to use off-chain oracles to obtain price updates for these assets. Alternatively, they may choose to use on-chain oracles, which are deployed as smart contracts that can provide market-based exchange rates for assets.

Automated market makers (AMMs) are a type of exchange that can also serve as an on-chain price oracle by enabling trades between multiple pairs of assets and reporting the relative exchange rates between these pairs through state variables that are available on-chain.

Attacks on Lending protocols

Throughout the duration of a loan, there are intricate interactions between various entities such as the borrower, creditors, lending protocol, liquidator, and the AMM oracle. If a malicious actor has the ability to manipulate the on-chain value of the collateral, they can take advantage of the lending smart contract by assuming the roles of borrower or liquidator and gain unfair profits, which would be detrimental to the creditors.Below are the various types of attacks on the Lending protocol:

Spot Price Manipulation:

Relying on the spot price of a decentralized exchange is a well-known weakness in the domain of on-chain price oracles. When a user deposits ETH into a smart contract, the protocol needs to determine the price of the asset, typically using the corresponding Uniswap pool as a reference. A malicious actor can exploit this by utilizing a flash loan to drain one side of the Uniswap pool, causing the protocol’s internal price to be distorted significantly, for example, by a factor of 100. Due to the lack of diverse data sources, the attacker can now take advantage of this price discrepancy to extract additional value from the protocol [11]

The code below shows a concrete example of a (vulnerable) lending protocol that uses a Uniswap liquidity pool as a price oracle. It is clear to see in this example that the price returned by the getEthPrice function is directly calculated from the reserves in the liquidity pool.

Thus, it follows that an adversary would be able to manipulate the ETH price in this smart contract by simply manipulating the reserves of this particular Uniswap liquidity pool. [2]

pragma solidity ^0.8.0;

import "./ILendingProtocol.sol";
import "./IUniswapV2Pair.sol";
import "./FixedPoint.sol";contract SimpleLendingProtocol is ILendingProtocol {
    
    address public daiEthPairAddress;
    
    constructor(address _daiEthPairAddress) {
        daiEthPairAddress = _daiEthPairAddress;
    }
    
    function getEthPrice() public view override returns (uint256) {
        (uint112 daiReserve, uint112 ethReserve, ) = IUniswapV2Pair(daiEthPairAddress).getReserves();
        return FixedPoint.fraction(daiReserve, ethReserve).decode();
    }
    
    // other functions
    
}

Uncollaterized Loan Attack

A malicious actor can exploit a lending protocol by pretending to be a borrower and using a combination of attack and manipulation capital. They use manipulation capital to buy Asset A from an automated market maker (AMM) and drive its price up, which then affects the collateralization ratio of the lending protocol. The attacker can then use their attack capital as collateral to borrow Loan Asset B from the lending protocol at a higher amount than if the price of Asset A had not been manipulated. The attacker then sells Loan Asset B in the market and, if possible, also sells Asset A at a higher price to make a profit. For instance, if a lending protocol has a collateralization ratio of 0.8 and the market price of ETH/USDC is $3000, the attacker can borrow up to $2400 worth of USDC by depositing 1 ETH as collateral. But by manipulating the price to $4000, they can borrow $3200 worth of USDC and earn a profit of $200.[11]

Liquidation Attack

To execute this attack, a bad actor takes on the role of a liquidator. In a loan, collateral asset A is backing the loan asset B. The bad actor manipulates the price of A lower or the price of B higher, making the loan appear to be in poor health.

The oracle, which feeds the price ratio of A vs. B to the lending protocol, is then manipulated to make the lending protocol believe that the price of A has decreased relative to the price of B.

This allows the liquidator to settle the loan back in asset B and take asset A out of the protocol, resulting in a profit for the liquidator. In contrast to the undercollateralized loan attack, the liquidator must purchase asset B from an external exchange to repay the loan and claim the collateral asset A with a profit.

Other actors are also incentivized to profit from this new price, and the oracle manipulator competes with them to execute either the undercollateralized loan attack or the liquidation attack, bidding up their transactions to get included in the next block.[11]

Example of an Oracle Manipulation smart contract

The code below is a Solidity smart contract for a simple oracle attack, where the attacker aims to manipulate the price of a token (in this case ETH) on a lending protocol by manipulating the price of a different token (in this case DAI) on an automated market maker (AMM) like Uniswap. [2]

pragma solidity ^0.8.0;

import "https://github.com/Uniswap/uniswap-v2-periphery/blob/master/contracts/interfaces/IUniswapV2Router02.sol";
import "./LendingProtocol.sol";contract SimpleOracleAttack is Ownable {
    IUniswapV2Router02 uniV2Router;
    LendingProtocol lendingProtocol;    constructor(address _uniV2Router, address _lendingProtocol) {
        uniV2Router = IUniswapV2Router02(_uniV2Router);
        lendingProtocol = LendingProtocol(_lendingProtocol);
    }    function attack() external onlyOwner {
        // 1. Swap DAI -> ETH (This increases the ETH price on Uniswap)
        uint256 daiToSell = 100 ether;
        uint256 deadline = block.timestamp + 1200;
        address[] memory path = new address[](2);
        path[0] = address(lendingProtocol.dai());
        path[1] = uniV2Router.WETH();        uint256[] memory amounts = uniV2Router.swapExactTokensForETH(
            daiToSell,
            0, // Minimum amount of ETH to receive
            path,
            address(this),
            deadline
        );        uint256 ethBought = amounts[1];        // 2. Deposit ETH (_NOT_ the ETH we just swapped) into lending protocol
        uint256 ethDeposit = 1 ether;
        lendingProtocol.depositCollateral{value: ethDeposit}();        // 3. Borrow max DAI according to new mid-price that this lending protocol thinks it’s at
        uint256 daiReserve = lendingProtocol.dai().balanceOf(address(lendingProtocol));
        uint256 wethReserve = lendingProtocol.weth().balanceOf(address(lendingProtocol));        uint256 newEthPrice = (daiReserve + daiToSell) * 1 ether / (wethReserve - ethDeposit);        uint256 maxBorrow = newEthPrice * ethDeposit * 100 / 150;        lendingProtocol.borrowDai(maxBorrow);        uint256 daiBorrowed = maxBorrow;        // 4. Swap back ETH -> DAI
        uint256 wethBought = ethDeposit - ethBought;
        path[0] = uniV2Router.WETH();
        path[1] = address(lendingProtocol.dai());        uniV2Router.swapExactETHForTokens(
            daiBorrowed * 99 / 100, // Amount of DAI to receive
            path,
            address(this),
            deadline
        );        // Transfer all DAI to the owner
        lendingProtocol.dai().transfer(owner(), lendingProtocol.dai().balanceOf(address(this)));
    }
}

The contract contains a function called attack () which is marked as external, meaning it can be called by anyone externally to the contract. The function first swaps a certain amount of DAI for ETH on the Uniswap router using the swapExactTokensForETH function. This is done in order to increase the price of ETH on the Uniswap pool.
Next, the attacker deposits a certain amount of ETH into a lending protocol by calling the deposit Collateral function. This is the ETH that was not swapped in the previous step. The lending protocol uses the price of ETH to determine how much collateral is needed to borrow a certain amount of DAI. By depositing ETH at an artificially high price, the attacker can borrow more DAI than they would have been able to otherwise.
The contract then calculates the new ETH price using the DAI and ETH reserves on the Uniswap pool and calculates the maximum amount of DAI that can be borrowed based on this new price using the borrowDai function. The attacker borrows this maximum amount of DAI.
Finally, the attacker swaps back the borrowed ETH for DAI using the swapExactETHForTokens function, which is similar to the first swap but in the opposite direction. The attacker then profits from the price difference between the original amount of DAI they swapped for ETH and the new amount of DAI they obtained through the lending protocol.

Attack in Action: Oracle Manipulation on Solana DEX

In November 2021, the decentralized finance (DeFi) platform Mango Markets was hit by a flash loan attack that resulted in a loss of $69 million. This attack was followed by a second attack in December, which saw the platform suffer losses of an additional $112 million.

The second attack was carried out through a series of price manipulations on the platform’s decentralized oracle. An oracle is a system that provides real-world data to smart contracts on a blockchain, allowing the contracts to execute certain actions automatically based on that data. In the case of Mango Markets, the oracle was used to determine the price of certain assets on the platform, such as cryptocurrencies and tokens.

The attacker manipulated the prices of several assets on the oracle, causing the prices to diverge significantly from their actual values on other exchanges. This allowed the attacker to carry out a series of trades on Mango Markets, buying assets at artificially low prices and selling them at artificially high prices. The attacker was able to execute these trades quickly, taking advantage of the time delay between the oracle updating the price and the blockchain processing the transaction.

The attack caused the prices of several assets on Mango Markets to fluctuate wildly, causing panic among traders and leading to a cascade of liquidations. Many traders were forced to sell their positions at significantly reduced prices, causing a loss of $112 million in total.

Mango Markets responded to the attack by temporarily halting trading on the platform and reimbursing affected users with a portion of the lost funds. The platform also implemented measures to improve the security of its oracle system and prevent similar attacks from happening in the future.

The attack procedure

Set Up

The attacker created two anonymous accounts on Mango Market: Mango Account A Mango Account B
He funded both the accounts with approximately 5 million USDC.
The attacker then sold Mango Account B USDC to sell to Mango Account A using the current MNGO and USDC price values.

The Attack

Later that same day, the attacker made multiple transactions on different cryptocurrency trading platforms, buying MNGO tokens at incrementally higher prices using USDC and USDT. He submitted and cancelled some of these orders, but ultimately purchased over 4.5 million MNGO tokens in a 20-minute period. For example, on one crypto asset trading platform, attacker purchased 3.5 million MNGO tokens through approximately 10 transactions.
On another crypto asset trading platform, Eisenberg purchased over 1 million MNGO tokens through six transactions. For example, on one crypto asset trading platform, attacker purchased 3.5 million MNGO tokens through approximately 10 transactions.
On the day the attacker manipulated the market, the trading volume for MNGO was significantly higher than usual. It was 2000% higher than the average volume for the preceding ten days and 2018% higher than the average volume for the preceding 90 trading days. attacker trading accounted for as much as 90% of the trading volume on some exchanges on that day. This indicates that the manipulation significantly influenced the market activity and prices for MNGO.
This caused the price of MNGO to increase artificially, from about 0.0382 USDC/MNGO to as high as 0.91 USDC/MNGO on some cryptocurrency trading platforms. This increase in price was due to attacker’s manipulation of the market, and not reflective of the actual market demand or value for MNGO.
To determine the relative value of MNGO and USDC Mango used a oracle which automatically gave input to the Mango Market such that when the price changes of a certain token pair its reflected on Mango Markets.
The attacker focused his purchases of the MNGO tokens on the oracle price source platforms.
As a result, manipulative trading of the MNGO token on oracle price source platform and another crypto asset trading platform during this period, the price of MNGO rose from 0.0382 USDC/MANGO to a high of 0.54 USDC/MNGO.
This lead to the Mango account A assets to increase by 1300%.
Now, the attacker uses Mango account A as a collateral and borrows around $116 million worth of crypto assets from Mango markets through 19 separate transactions.
This withdrawal left mango markets at a deficit because the total value of user’s assets on Mango markets at the time of attack was $104 million.
After the attacker stopped purchasing large amounts of MNGO token, the price of MNGO fell to 0.0198 causing the price to decrease to approximately 0.02USDC/MNGO.
From the peak of attacker’s manipulation of MNGO the price dropped by 90% and volume fell by 80% resulting MNGO token to become even more illiquid. [7][8][9][10]

Conclusion:

Oracle manipulation attacks have become a significant concern for decentralized finance (DeFi) systems, which rely on oracles to provide accurate and timely information about market prices and other data. Attackers can exploit vulnerabilities in the oracle to manipulate the information used by DeFi systems, potentially leading to financial losses. Apart from Mango Market attack several other attacks on Oracle has been happening which has resulted in loss of $200 million assets of Defi industry.

One example of an oracle manipulation attack on DeFi is the “flash loan attack” on the decentralized lending platform bZx in February 2020. In this attack, the attacker borrowed a large amount of cryptocurrency from a DeFi lending platform using a flash loan, which is a type of loan that can be taken out and repaid in the same transaction. The attacker then manipulated the price feed provided by the oracle to artificially lower the price of a token used as collateral for the loan, which caused the loan to be liquidated and the collateral to be seized. The attacker was able to profit from the price difference and repay the loan with the remaining funds. [9]

Another example is the attack on the Harvest Finance DeFi platform in October 2020, in which the attacker manipulated the price feed provided by the oracle to trick the system into buying a large amount of a token at an inflated price. The attacker was then able to sell the token on another exchange for a profit before the price dropped back down to its actual value. The attack resulted in a loss of around $24 million for the Harvest Finance platform and its users.

These attacks demonstrate the importance of secure and reliable oracles for the security of DeFi systems, as well as the need for ongoing research and development of new defense mechanisms to protect against oracle manipulation attacks.

References:

Eskandari, S., Salehi, M., Gu, W. C., & Clark, J. (2021, September). SoK: oracles from the ground truth to market manipulation. In Proceedings of the 3rd ACM Conference on Advances in Financial Technologies (pp. 127–141).
Tjiam, K. (2021). Investigating Arbitrageurs and Oracle Manipulators in Ethereum.
Oracles: https://ethereum.org/en/developers/docs/oracles/
Taking undercollateralized loans for fun and for profit: https://samczsun.com/taking-undercollateralized-loans-for-fun-and-for-profit/
Oracle Manipulation: https://consensys.github.io/smart-contract-best-practices/attacks/oracle-manipulation/#centralized-oracles-and-trust
2022: Year Review in Lending protocols https://www.certik.com/resources/blog/4Rt6nVfk3RZGuvLGbSCOoK-2022-year-in-review-lending-protocols
What is Blockchain oracle? https://chain.link/education/blockchain-oracles#:~:text=The blockchain oracle problem outlines a fundamental limitation,already stored on the blockchain is considered on-chain.
DeFi Security Lecture 7 — Price Oracle Manipulation https://medium.com/beaver-smartcontract-security/defi-security-lecture-7-price-oracle-manipulation-d716cdeaaf77
How $100M Got Stolen from DeFi in 2021: Price Oracle Manipulation and Flash Loan Attacks Explained https://hackernoon.com/how-dollar100m-got-stolen-from-defi-in-2021-price-oracle-manipulation-and-flash-loan-attacks-explained-3n6q33r1
UNITED STATES DISTRICT COURT SOUTHERN DISTRICT OF NEW YORK https://www.sec.gov/litigation/complaints/2023/comp-pr2023-13.pdf
Mackinga, T., Nadahalli, T., & Wattenhofer, R. (2022, May). TWAP Oracle Attacks: Easier Done than Said? In 2022 IEEE International Conference on Blockchain and Cryptocurrency (ICBC) (pp. 1–8). IEEE.