DittoETH - LinKenji's results

A decentralized stablecoin protocol with an order book design for supercharged staking yield.

General Information

Platform: Code4rena

Start Date: 15/03/2024

Pot Size: $60,500 USDC

Total HM: 16

Participants: 43

Period: 21 days

Judge: hansfriese

Total Solo HM: 5

Id: 348

League: ETH

DittoETH

Findings Distribution

Researcher Performance

Rank: 26/43

Findings: 2

Award: $91.81

🌟 Selected for report: 0

🚀 Solo Findings: 0

Findings Information

🌟 Selected for report: Infect3d

Also found by: Evo, LinKenji, XDZIBECX, falconhoof, foxb868, ilchovski, klau5, nonseodion

Labels

bug
2 (Med Risk)
satisfactory
sufficient quality report
:robot:_114_group
duplicate-114

Awards

67.2468 USDC - $67.25

External Links

Lines of code

https://github.com/code-423n4/2024-03-dittoeth/blob/91faf46078bb6fe8ce9f55bcb717e5d2d302d22e/contracts/libraries/LibOracle.sol#L22 https://github.com/code-423n4/2024-03-dittoeth/blob/91faf46078bb6fe8ce9f55bcb717e5d2d302d22e/contracts/libraries/LibOracle.sol#L19-L67

Vulnerability details

If the market experiences significant price volatility within the 15-minute window, the cached price may diverge from the actual market price. This discrepancy can lead to several issues:

  • Incorrect calculation of collateral ratios:

    • If the cached price is higher than the actual market price, undercollateralized positions may remain open, exposing the protocol to increased risk.
    • If the cached price is lower than the actual market price, positions may be prematurely liquidated, causing unnecessary losses for users.
  • Mispricing of assets during order matching:

    • If the cached price is stale, orders may be matched at prices that do not reflect the current market conditions.
    • This can result in unfair trades, where one party may receive an advantageous price at the expense of the other.
    • Malicious actors may exploit this by manipulating the market during the cache duration to benefit from the stale prices.
  • Delayed liquidations of risky positions:

    • If the cached price is higher than the actual market price, positions that have fallen below the liquidation threshold may not be promptly identified and liquidated.
    • This delay in liquidation can expose the protocol to increased risk and potential losses.

It's from the following: LibOracle.sol#L22

uint256 protocolPrice = getPrice(asset);
// ... Oracle price retrieval logic ...

The getPrice function retrieves the cached price, which may be stale if the cache duration has not expired.

Impact

  • Users may suffer financial losses due to incorrect liquidations or unfair pricing during order matching.
  • The protocol may be exposed to increased risk if undercollateralized positions are not promptly identified and liquidated.

Description

getOraclePrice is responsible for retrieving the asset price from the oracle. It first attempts to fetch the price from the Chainlink oracle and falls back to a TWAP price from Uniswap if the Chainlink price is invalid or outdated.

LibOracle.sol#getOraclePrice

function getOraclePrice(address asset) internal view returns (uint256) {
    AppStorage storage s = appStorage();
    AggregatorV3Interface baseOracle = AggregatorV3Interface(s.baseOracle);
    uint256 protocolPrice = getPrice(asset);        <---------@

    AggregatorV3Interface oracle = AggregatorV3Interface(s.asset[asset].oracle);           <---------@
    if (address(oracle) == address(0)) revert Errors.InvalidAsset();         <---------@

    try baseOracle.latestRoundData() returns (uint80 baseRoundID, int256 basePrice, uint256, uint256 baseTimeStamp, uint80) {  <---------@
        // ... Chainlink price retrieval and validation logic ...
    } catch {
        if (oracle == baseOracle) {
            return twapCircuitBreaker();
        } else {
            // ... Fallback to TWAP price ...
        }
    }
}

retrieves the cached price and the setPriceAndTime function updates the cached price and timestamp. Is expected to retrieve the most up-to-date and accurate price for an asset from the oracle. The retrieved price should reflect the current market conditions and be used for various calculations and checks within the protocol.

Note:

The 15-minute cache duration, the getOraclePrice function may deviate from the expected behavior. If the market price changes significantly within the 15-minute window, the cached price may not accurately represent the current market conditions.

This can lead to incorrect calculations, mispricing of assets, and delayed liquidations, as described in the vulnerability details section.

Proof of Concept

Let's consider a hypothetical scenario where the DittoETH protocol is used for trading a stablecoin pegged to the US dollar (e.g., USDC) against ETH. The protocol relies on the Chainlink ETH/USD price oracle to determine the current market price of ETH.

Assume the following initial conditions:

  • The cached ETH/USD price is $2,000, and the cache was last updated 14 minutes ago.
  • The actual market price of ETH has suddenly dropped to $1,500 due to market volatility.
  • Alice has a short position with a collateral ratio of 1.5, just above the liquidation threshold of 1.4.
  • Bob is a malicious actor who wants to exploit the stale cached price.

Then takes these steps:

  1. Bob observes that the cached ETH/USD price in the DittoETH protocol is stale and significantly higher than the actual market price. The protocol is still using the cached price of $2,000, while the market price has dropped to $1,500.

  2. Bob quickly opens a large short position on the ETH/USD pair, taking advantage of the stale cached price. Since the protocol calculates the collateral ratio based on the cached price, Bob's short position appears to be sufficiently collateralized.

  3. Bob then manipulates the market by placing a large sell order on an external exchange, driving the market price of ETH further down to $1,200.

  4. Alice's short position, which was initially above the liquidation threshold, is now undercollateralized based on the actual market price. However, since the DittoETH protocol is still using the stale cached price of $2,000, Alice's position appears to be adequately collateralized, and no liquidation is triggered.

  5. Bob waits for the cache duration to expire and the protocol to update the cached price to the current market price of $1,200. At this point, Alice's position becomes severely undercollateralized.

  6. Bob quickly buys back the ETH at the lower price, closing his short position at a significant profit. Meanwhile, Alice's position remains open and is at risk of liquidation.

  7. When the protocol finally updates the cached price and detects Alice's undercollateralized position, it triggers a liquidation. However, due to the delayed liquidation, the protocol may struggle to find sufficient liquidity to close Alice's position at the current market price, potentially leading to a cascade of liquidations and further price instability.

Consequences:

  • Alice suffers a significant loss due to the delayed liquidation of her undercollateralized position. She may lose a substantial portion of her collateral.
  • The protocol itself is exposed to increased risk, as it may not be able to liquidate undercollateralized positions effectively, leading to potential bad debt and losses for the protocol and its users.
  • The overall stability and integrity of the DittoETH protocol are compromised, as the stale cached prices can be exploited by malicious actors to gain an unfair advantage and manipulate the market.
function getOraclePrice(address asset) internal view returns (uint256) {
    uint256 cachedPrice = getPrice(asset);
    uint256 cacheTimestamp = getPriceTimestamp(asset);

    if (block.timestamp - cacheTimestamp > 15 minutes) {
        // Cache duration expired, update the cached price
        uint256 currentPrice = fetchCurrentPrice(asset);
        setPrice(asset, currentPrice);
        setPriceTimestamp(asset, block.timestamp);
        return currentPrice;
    } else {
        // Use the cached price
        return cachedPrice;
    }
}

If the cache duration has not expired (i.e., less than 15 minutes have passed since the last price update), the function returns the cached price (cachedPrice). However, if the market price has changed significantly during this period, the returned price may be stale and not reflect the current market conditions, leading to the issues described in the vulnerability details section.

Tools Used

Manual Review

Consider implementing the mitigation measures discussed earlier, such as reducing the cache duration, implementing price deviation checks, using multiple Oracle price feeds, and regularly updating the Oracle integration to ensure the most accurate and up-to-date prices are used for various calculations and decisions within the protocol.

The price deviation check can be implemented:

function getOraclePrice(address asset) internal view returns (uint256) {
    // ... Existing code ...

+   uint256 cachedPrice = getPrice(asset);
+   uint256 currentPrice = fetchCurrentPrice(asset); // Retrieve the current price from the oracle

+   if (cachedPrice > 0) {
+       uint256 deviation = (currentPrice > cachedPrice) ? currentPrice - cachedPrice : cachedPrice - currentPrice;
+       if (deviation * 100 / cachedPrice > 10) { // Check if deviation exceeds 10%
+           // Trigger an alert or emergency action
            // ...
        }
    }

    // ... Existing code ...
}

As can be seen, the getOraclePrice function compares the cached price with the current price fetched from the oracle. If the deviation between the two prices exceeds a threshold (e.g., 10%), an alert or emergency action can be triggered to handle the significant price movement.

Assessed type

Other

#0 - c4-pre-sort

2024-04-06T06:01:39Z

raymondfam marked the issue as sufficient quality report

#1 - c4-pre-sort

2024-04-06T06:01:55Z

raymondfam marked the issue as duplicate of #114

#2 - raymondfam

2024-04-06T06:02:38Z

See #114.

#3 - c4-judge

2024-04-11T16:12:40Z

hansfriese marked the issue as satisfactory

Findings Information

Labels

analysis-advanced
grade-b
sufficient quality report
A-07

Awards

24.5635 USDC - $24.56

External Links

Overview of DittoETH

DittoETH is a decentralized stablecoin protocol that utilizes an order book design to enable supercharged staking yield for users. The protocol aims to create stable assets backed by over-collateralized liquid staked ETH (LST), such as rETH and stETH. By leveraging an order book mechanism, DittoETH allows users to participate as bidders, shorters, or askers, facilitating the minting and trading of stable assets while providing attractive yield opportunities.

Approach Taken in Evaluating the Codebase:

  1. Familiarization with the DittoETH protocol and its intended functionality.
  2. In-depth review of the smart contract code, focusing on critical components and potential risk areas.
  3. Identification of vulnerabilities, edge cases, and potential attack vectors.
  4. Assessment of centralization risks and admin control abuse possibilities.
  5. Evaluation of the overall codebase quality and architecture.
  6. Providing actionable recommendations based on my findings.

Architecture Overview and Risks:

The DittoETH protocol utilizes a unique order book design to enable supercharged staking yield for users. The architecture revolves around the interaction of various components, including the Diamond proxy pattern, facets, libraries, and external contracts.

DittoETH Architecture Overview

+---------------------------+
|     DittoETH Protocol     |
+---------------------------+
|                           |
|  +-----------------+      |
|  |    Order Book   |      |
|  +-----------------+      |
|  | - Bids          |      |
|  | - Shorts        |      |
|  | - Asks          |      |
|  +-----------------+      |
|                           |
|  +-----------------+      |
|  |    Collateral   |      |
|  |    Management   |      |
|  +-----------------+      |
|  | - LST Collateral|      |
|  | - Collateral    |      |
|  |   Ratios        |      |
|  +-----------------+      |
|                           |
|  +-----------------+      |
|  |  Liquidations   |      |
|  +-----------------+      |
|  | - Undercollate- |      |
|  |   ralized Shorts|      |
|  | - Liquidation   |      |
|  |   Mechanism     |      |
|  +-----------------+      |
|                           |
|  +-----------------+      |
|  |      Yield      |      |
|  |   Distribution  |      |
|  +-----------------+      |
|  | - LST Rewards   |      |
|  | - Bidder's      |      |
|  |   Collateral    |      |
|  +-----------------+      |
|                           |
|  +-----------------+      |
|  |    Governance   |      |
|  +-----------------+      |
|  | - Token Holders |      |
|  | - Proposals     |      |
|  | - Voting        |      |
|  +-----------------+      |
|                           |
+---------------------------+
       |            |
       |            |
+------+------------+-------+
|      |            |       |
|  +---+----+  +----+---+   |
|  | Bidders|  |Shorters|   |
|  +--------+  +--------+   |
|                           |
|  +--------+   +--------+  |
|  | Askers |   |Liquidat|  |
|  |        |   |  ors   |  |
|  +--------+   +--------+  |
|                           |
+---------------------------+
  • The DittoETH Protocol is the central component that encapsulates various modules and functionalities.
  • The Order Book module handles the matching of bids, shorts, and asks based on price and quantity.
  • The Collateral Management module manages the LST collateral provided by shorters and tracks collateral ratios.
  • The Liquidations module handles the liquidation of undercollateralized short positions and the liquidation mechanism.
  • The Yield Distribution module distributes the yield earned by shorters, including LST rewards and the bidder's collateral.
  • The Governance module enables token holders to participate in decision-making processes through proposals and voting.
  • External to the protocol, there are different types of users: Bidders, Shorters, Askers, and Liquidators, who interact with the protocol based on their roles and objectives.

Key components:

  • Diamond.sol: The main proxy contract that manages the facets and storage.
  • Facets: Individual contracts that implement specific functionalities and are accessed through the Diamond proxy.
  • Libraries: Reusable code modules that are shared across facets and provide utility functions.
  • External Contracts: Contracts that interact with the DittoETH protocol, such as bridges and governance contracts.

Risks and Recommendations:

  1. Diamond proxy pattern introduces complexity in terms of code organization and upgradability. Ensure thorough testing and auditing of the facet interactions and storage layout to mitigate potential risks.

  2. The interaction between facets and shared storage can lead to unintended consequences if not properly managed. Implement strict access controls and validation checks to prevent unauthorized access or manipulation of shared storage.

  3. The upgradability of facets through the Diamond proxy requires careful consideration. Establish a robust governance process and testing framework to ensure the integrity and security of upgrades.

Codebase Quality Analysis:

DittoETH demonstrates a modular and organized structure, leveraging the Diamond proxy pattern for upgradability and separation of concerns. The use of libraries and constants helps improve code reusability and readability. However, there are areas that require attention to enhance the overall codebase quality.

  1. Error Handling and Validation:

    • Observation: The codebase extensively uses the revert statement for error handling, which is a good practice. However, some functions lack proper input validation, which could lead to unexpected behavior or vulnerabilities.

    • Recommendation: Implement comprehensive input validation checks for all external and public functions to ensure the correctness and integrity of the input data.

  2. Code Documentation and Comments:

    • Observation: The codebase includes some comments and documentation, but there is room for improvement. Consistent and detailed documentation can enhance code readability and maintainability.
    • Recommendation: Provide clear and concise comments for complex logic, important functions, and critical sections of the code. Include documentation for contract interactions, external dependencies, and any assumptions made.
  3. Gas Optimization:

    • Observation: The codebase employs various gas optimization techniques, such as struct packing and storage slot reuse. However, there may be opportunities for further optimization.
    • Example:
      struct Order {
          uint88 ercAmount;
          uint80 price;
          uint16 prevId;
          uint16 id;
          uint16 nextId;
          O orderType;
          uint32 creationTime;
          address addr;
          O prevOrderType;
          uint16 shortOrderCR;
          uint8 shortRecordId;
          uint64 filler;
      }
    • Recommendation: Continuously review and optimize gas usage by minimizing storage reads/writes, using memory variables when possible, and leveraging efficient data structures and algorithms.

Centralization Risks

  1. Admin Roles and Privileges:

    • Observation: The DittoETH protocol includes admin roles with significant privileges, such as the ability to create markets, adjust protocol parameters, and manage bridges.

    • Recommendation: Implement a multi-sig or decentralized governance mechanism to distribute control and reduce the risk of a single point of failure or admin abuse.

  2. Bridge Management:

    • Observation: The protocol allows the admin to create and delete bridges, which could potentially impact user funds if not managed properly.

    • Recommendation: Establish strict guidelines and governance processes for bridge management to ensure the security and integrity of user funds. Consider implementing time-locks or multi-sig controls for critical bridge operations.

  3. Parameter Adjustments:

    • Observation: The admin has the ability to modify various protocol parameters, such as fees, liquidation thresholds, and collateral ratios, which could potentially be abused to gain an unfair advantage.

    • Recommendation: Implement robust governance mechanisms and checks and balances to prevent unilateral parameter changes. Consider using time-locks, multi-sig approvals, or community voting for significant parameter adjustments.

Mechanism Review:

  1. Order Matching Logic:

    • Observation: The order matching logic in the DittoETH protocol is complex and involves various edge cases and potential vulnerabilities.
    • Example: The bidMatchAlgo function in the BidOrdersFacet contract handles the matching of bids with asks and shorts. It involves intricate logic and loops, which could be prone to errors or manipulation.
    • Recommendation: Unit testing and formal verification of the order matching logic to ensure its correctness and robustness. Consider simplifying the logic where possible and implementing additional checks and safeguards to prevent potential exploits.
  2. Liquidation Mechanism:

    • Observation: The liquidation mechanism in the DittoETH protocol plays a crucial role in maintaining the stability and solvency of the system. However, it relies on accurate price oracles and timely execution of liquidations.
    • Example: The liquidate function in the PrimaryLiquidationFacet contract allows liquidators to liquidate undercollateralized short positions. It depends on the accuracy of the oracle price and the correctness of the liquidation logic.
    • Recommendation: Ensure the reliability and security of the price oracles used for liquidations. Implement robust error handling and fallback mechanisms to handle oracle failures or price discrepancies. Conduct thorough testing and auditing of the liquidation logic to identify and address potential vulnerabilities.
  3. Redemption Mechanism:

    • Observation: The redemption mechanism in the DittoETH protocol allows users to redeem their stable assets for the underlying collateral. However, it introduces potential risks related to collateral management and redemption order manipulation.
    • Example: The proposeRedemption function in the RedemptionFacet contract enables users to propose a redemption order based on the collateral ratios of short positions. It relies on user input and is subject to potential manipulation.
    • Recommendation: Implement strict validation checks and constraints on the redemption process to prevent invalid or malicious redemption proposals. Consider using an automated and deterministic approach for determining the redemption order to minimize the risk of manipulation.

Systemic Risks:

  1. Oracle Dependency:

    • Observation: The DittoETH protocol heavily relies on accurate and timely price oracles for various critical functions, such as liquidations, order matching, and collateral ratio calculations.
    • Risk: If the price oracles are compromised, manipulated, or experience significant delays, it could lead to incorrect liquidations, mispricing of assets, and potential exploitation by malicious actors.
    • Recommendation: Implement robust oracle security measures, such as using multiple oracle sources, employing price aggregation techniques, and establishing a fallback mechanism for oracle failures. Regularly monitor and assess the integrity and performance of the price oracles.
  2. Liquidity and Market Dynamics:

    • Observation: The DittoETH protocol's stability and efficiency depend on sufficient liquidity and balanced market dynamics.
    • Risk: If there is a lack of liquidity or imbalanced market conditions, it could lead to inefficient price discovery, slippage, and potential difficulties in executing trades or liquidations.
    • Recommendation: Incentivize liquidity provision and market participation through effective token economics and reward mechanisms. Continuously monitor and analyze market dynamics to identify potential liquidity risks and take proactive measures to address them.
  3. Governance and Upgradability:

    • Observation: The DittoETH protocol relies on a governance mechanism and upgradability features to adapt and evolve over time.
    • Risk: Inadequate governance processes or improper management of upgrades could introduce vulnerabilities, cause community disputes, or lead to unintended consequences.
    • Recommendation: Establish a robust and transparent governance framework that includes checks and balances, community participation, and thorough testing and auditing of proposed upgrades. Ensure the integrity and security of the upgrade process to minimize the risk of introducing vulnerabilities or breaking changes.

System Overview

  1. Stable Asset Creation: DittoETH enables the creation of stable assets, such as dUSD, which are backed by LST collateral. Users can mint stable assets by placing bids on the order book, while shorters provide the necessary collateral and take on a short position.

  2. Order Book Mechanism: The protocol employs an order book design that matches bids and shorts to determine the price and quantity of stable assets minted. Bidders bring ETH to purchase stable assets, while shorters bring ETH as collateral and take a leveraged short position against the stable asset.

  3. Collateral Management: DittoETH ensures that short positions are always over-collateralized to maintain the stability of the minted assets. Shorters must provide sufficient collateral to cover their short positions, and the protocol enforces liquidation mechanisms to manage undercollateralized positions.

  4. Yield Generation: Shorters earn a supercharged yield on their collateral, as they receive the staking rewards generated by the LST collateral in addition to the bidder's collateral. This mechanism incentivizes shorters to participate and provides an attractive yield opportunity.

  5. Liquidations and Risk Management: DittoETH incorporates liquidation mechanisms to handle undercollateralized short positions. When a short position falls below the required collateral ratio, liquidators can step in to liquidate the position and maintain the stability of the system.

Breakdown of Functions

  1. Minting Stable Assets: Users can mint stable assets, such as dUSD, by placing bids on the order book. Bids are matched with short positions to determine the price and quantity of stable assets minted.

  2. Shorting: Shorters provide collateral in the form of LST (e.g., rETH or stETH) and take a short position against the stable asset. They earn a yield on their collateral, which includes the staking rewards and the bidder's collateral.

  3. Collateral Management: The protocol manages the collateral provided by shorters, ensuring that short positions remain over-collateralized. It tracks the collateral ratios and triggers liquidations when necessary.

  4. Order Matching: The order book mechanism matches bids and shorts based on price and quantity. It determines the price at which stable assets are minted and facilitates the exchange between bidders and shorters.

  5. Liquidations: When a short position falls below the required collateral ratio, liquidators can initiate the liquidation process. They buy back the stable assets and receive a liquidation fee, while the remaining collateral is used to cover any outstanding debt.

  6. Governance: DittoETH incorporates a governance mechanism that allows token holders to participate in decision-making processes, such as adjusting protocol parameters, managing collateral types, and upgrading the system.

Roles in DittoETH:

  1. Bidders: Participants who bring ETH to the protocol to purchase stable assets. They place bids on the order book, specifying the price and quantity they are willing to buy.

  2. Shorters: Participants who provide LST collateral and take a short position against the stable asset. They earn a yield on their collateral and are responsible for maintaining the required collateral ratio.

  3. Askers: Participants who sell their stable assets on the order book, specifying the price and quantity they are willing to sell.

  4. Liquidators: Participants who monitor the system for undercollateralized short positions and initiate liquidations when necessary. They buy back the stable assets and receive a liquidation fee.

  5. Governance Token Holders: Participants who hold governance tokens and have the right to participate in the decision-making processes of the protocol.

Workflow

  1. User Interaction: Users interact with the DittoETH protocol through a web interface or API, allowing them to place bids, create short positions, and manage their assets.

  2. Smart Contracts: The core functionality of DittoETH is implemented through a set of smart contracts deployed on the Ethereum blockchain. These contracts handle the minting and burning of stable assets, order matching, collateral management, and liquidations.

  3. Order Book: The order book is a central component of the DittoETH protocol. It maintains a list of bids and shorts, sorted by price. When a new bid or short is placed, the order book matches it with existing orders based on price and quantity.

  4. Collateral Management: The protocol tracks the collateral provided by shorters and ensures that short positions remain over-collateralized. It continuously monitors the collateral ratios and triggers liquidations when necessary.

  5. Liquidations: When a short position falls below the required collateral ratio, the protocol initiates the liquidation process. Liquidators step in to buy back the stable assets and receive a liquidation fee, while the remaining collateral is used to cover any outstanding debt.

  6. Yield Distribution: The protocol distributes the yield earned by shorters, which includes the staking rewards from the LST collateral and the bidder's collateral. This yield is automatically calculated and distributed to shorters based on their collateral contribution.

  7. Governance: DittoETH incorporates a governance mechanism that allows token holders to participate in decision-making processes. Governance proposals can be submitted, discussed, and voted on by token holders to make changes to the protocol's parameters or upgrade the system.

Report of my findings, including identified vulnerabilities, their potential impact, and recommendations for mitigation.

  1. Vulnerability: Redemption Mechanism - Incorrect Redemption Order Description:

    • The redemption mechanism relies on users proposing a redemption order based on the collateral ratios of short positions.
    • If a user proposes an incorrect redemption order, it could lead to the redemption of short positions in the wrong sequence.

    Potential Impact:

    • Incorrect redemption order could result in the protocol redeeming short positions with higher collateral ratios before those with lower ratios.
    • This could lead to a suboptimal liquidation process and potential losses for the protocol and users.

    Recommendation:

    • Implement strict validation checks to ensure the proposed redemption order is correctly sorted based on collateral ratios.
    • Consider using a more automated and deterministic approach to determine the redemption order, rather than relying solely on user proposals.
    • Conduct thorough testing of the redemption mechanism, including edge cases and scenarios with manipulated or incorrect redemption orders.
  2. Vulnerability: Orderbook Matching Logic - Incorrect Matching of Short Orders Description:

    • The orderbook matching logic for short orders differs from the standard bid/ask matching, as short orders can only be matched at or above the cached oracle price.
    • If the matching logic fails to properly enforce this constraint, it could lead to incorrect matching of short orders.

    Potential Impact:

    • Incorrect matching of short orders could result in trades being executed at prices below the oracle price, leading to potential losses for users and the protocol.
    • It could also disrupt the overall integrity and fairness of the orderbook.

    Recommendation:

    • Thoroughly review and test the orderbook matching logic, especially the handling of short orders and the enforcement of the oracle price constraint.
    • Ensure that the matching algorithm correctly identifies and matches short orders only when the price is at or above the cached oracle price.
    • Implement comprehensive unit tests and integration tests to verify the correctness of the matching logic under various scenarios.
  3. Vulnerability: Oracle Price Caching - Stale Prices and Manipulation Description:

    • The protocol relies on caching the oracle price for a duration of 15 minutes to optimize gas costs and support the hint system for order placement.
    • However, if the market experiences significant volatility within the 15-minute window, the cached price may become stale and deviate from the actual market price.

    Potential Impact:

    • Stale cached prices can lead to incorrect order matching, mispricing of assets, and potential manipulation by malicious actors.
    • It could result in unfair trades, where users buy or sell assets at prices that do not reflect the current market conditions.
    • Malicious actors may exploit the stale prices to profit at the expense of other users.

    Recommendation:

    • Reduce the cache duration to a shorter period, such as 5 minutes, to minimize the window for price deviation and manipulation.
    • Implement price deviation checks to compare the cached price with the current market price and trigger alerts or emergency actions if the deviation exceeds a certain threshold.
    • Consider using multiple oracle price feeds or a decentralized oracle network to reduce the reliance on a single price source and enhance the resilience against price manipulation.
  4. Vulnerability: Dust Amounts - Increased Gas Costs and Orderbook Bloat Description:

    • The protocol aims to prevent the creation of small orders (dust amounts) to avoid skyrocketing gas costs for large orders that match with multiple limit orders.
    • However, if the mechanisms to prevent dust amounts are not properly implemented or enforced, it could lead to the accumulation of small orders on the orderbook.

    Potential Impact:

    • The presence of numerous small orders on the orderbook can significantly increase gas costs for matching and settlement processes.
    • It can also lead to orderbook bloat, reducing the efficiency and performance of the protocol.
    • Malicious actors may exploit this vulnerability by intentionally creating a large number of small orders to congest the orderbook and disrupt normal trading activities.

    Recommendation:

    • Implement strict validation checks to enforce minimum order sizes and prevent the creation of orders below the dust threshold.
    • Regularly monitor the orderbook for the presence of dust amounts and implement mechanisms to clean up and remove such orders.
    • Consider introducing a fee structure that disincentivizes the creation of small orders and encourages users to place orders above the dust threshold.
  5. Vulnerability: Liquidation and Collateral Ratio Manipulation Description:

    • The protocol relies on the concept of minShortErc to ensure that liquidators have sufficient incentive to liquidate risky debt positions.
    • However, if there are loopholes or weaknesses in the implementation of minShortErc or the liquidation process, it could lead to potential manipulation of collateral ratios.

    Potential Impact:

    • If liquidators are not properly incentivized or if there are ways to manipulate the collateral ratios, it could result in delayed or failed liquidations of risky positions.
    • This could expose the protocol to increased risk and potential losses, as undercollateralized positions may remain open for extended periods.
    • Malicious actors may exploit these vulnerabilities to avoid liquidation or maintain positions with insufficient collateral.

    Recommendation:

    • Thoroughly review and test the implementation of minShortErc and the liquidation process to ensure they are robust and free from loopholes.
    • Implement strict validation checks to prevent manipulation of collateral ratios, such as ensuring that positions cannot be maintained below the required collateral threshold.
    • Continuously monitor the liquidation process and collateral ratios to identify any anomalies or suspicious activities.
    • Consider implementing additional safeguards, such as emergency liquidation mechanisms or circuit breakers, to mitigate the impact of manipulation attempts.
  6. Vulnerability: Incorrect Liquidation or Exiting of Short Positions Description:

    • The protocol allows users to liquidate or exit short positions based on certain collateral ratio thresholds.
    • If there are errors or weaknesses in the implementation of these mechanisms, it could lead to incorrect liquidations or improper exiting of positions.

    Potential Impact:

    • Incorrect liquidations could result in the premature closure of positions, causing financial losses for users.
    • Improper exiting of short positions could allow users to avoid liquidation or maintain positions with insufficient collateral.
    • These issues could undermine the stability and fairness of the protocol and erode user trust.

    Recommendation:

    • Conduct thorough testing and auditing of the liquidation and position exiting mechanisms to identify and rectify any potential errors or weaknesses.
    • Implement comprehensive validation checks to ensure that liquidations and position exits are triggered only when the specified conditions are met.
    • Regularly monitor and review the liquidation and exiting processes to detect any anomalies or unexpected behaviors.
    • Consider implementing additional safeguards, such as multi-step confirmation or time-locks, to prevent accidental or malicious liquidations or exits.

Additional Observations and Suggestions:

  • Implement a robust monitoring and alerting system to detect and respond to suspicious activities or anomalies in real-time.
  • Provide clear and comprehensive documentation to help users understand the protocol's functionalities, risks, and best practices.
  • Foster a culture of transparency and open communication with the community to build trust and facilitate the timely resolution of any identified issues.

By addressing these vulnerabilities and implementing the recommended mitigation measures, the DittoETH protocol can enhance its security posture, protect user funds, and maintain the integrity of its economic model.

Analysis of the DittoETH system architecture, code, and interactions between different components.

  1. Order Book Manipulation:

    • Weakness: The order book mechanism relies on the accurate matching of bids and shorts based on price and quantity. If there are vulnerabilities in the order matching logic or if the price oracle can be manipulated, it could lead to potential exploits.
    • Entry Point: An attacker could attempt to manipulate the price oracle or exploit any weaknesses in the order matching algorithm to influence the price and quantity of stable assets minted, potentially leading to unintended consequences or financial losses.
  2. Collateral Management:

    • Weakness: The protocol relies on the accurate tracking and management of collateral provided by shorters. If there are any bugs or errors in the collateral management system, it could result in incorrect collateral ratios or allow shorters to withdraw collateral improperly.
    • Entry Point: An attacker could try to exploit any vulnerabilities in the collateral management system to withdraw collateral without proper authorization or to manipulate the collateral ratios in their favor, potentially leading to undercollateralized positions and risking the stability of the minted assets.
  3. Liquidation Mechanism:

    • Weakness: The liquidation process is crucial for maintaining the stability of the system by handling undercollateralized short positions. If there are any flaws or delays in the liquidation mechanism, it could allow short positions to remain undercollateralized for an extended period, exposing the protocol to increased risk.
    • Entry Point: An attacker could attempt to exploit any weaknesses in the liquidation mechanism to prevent or delay liquidations, potentially allowing them to maintain undercollateralized positions and extract value from the system.
  4. Governance and Upgradability:

    • Weakness: The governance mechanism and upgradability features of the protocol could introduce potential vulnerabilities if not implemented securely. If there are weaknesses in the governance process or if the upgrade mechanism can be hijacked, it could allow malicious actors to make unauthorized changes to the protocol.
    • Entry Point: An attacker could try to manipulate the governance process or exploit any vulnerabilities in the upgrade mechanism to gain control over the protocol, potentially allowing them to make malicious changes or steal funds.
  5. External Dependencies:

    • Weakness: The DittoETH protocol relies on external dependencies, such as price oracles and the Ethereum blockchain. If these dependencies are compromised or experience issues, it could impact the functionality and security of the protocol.
    • Entry Point: An attacker could target the external dependencies, such as manipulating the price oracle data or exploiting vulnerabilities in the Ethereum blockchain, to disrupt the operation of the DittoETH protocol or gain an unfair advantage.

To mitigate these weaknesses and entry points, I'll recommend the DittoETH protocol should:

  1. Implement robust and well-tested order matching logic, with proper validation and checks to prevent manipulation.
  2. Ensure the security and reliability of the price oracle, using multiple sources and implementing safeguards against price manipulation.
  3. Strengthen the liquidation mechanism to ensure timely and accurate liquidations of undercollateralized positions, with appropriate incentives for liquidators.
  4. Implement secure governance processes and upgrade mechanisms, with proper access controls and checks and balances to prevent unauthorized changes.

I believe by addressing these potential weaknesses and entry points, the DittoETH protocol can enhance its security posture and reduce the risk of exploits or attacks.

weaknesses or Potential weak points

Let's dive deeper into the potential weaknesses and weak points of the DittoETH protocol.

1. Dependency on External Oracles: The DittoETH protocol relies heavily on external price oracles for accurate pricing information. If the oracle is compromised, manipulated, or fails to provide timely updates, it can lead to mispricing of assets and potential exploits.

LibOracle.sol::getOraclePrice

Recommendation:

  • Implement a multi-oracle approach to reduce dependency on a single oracle.
  • Introduce a price feed aggregator to combine data from multiple oracles and reduce the impact of individual oracle failures.
  • Implement a fallback mechanism to handle oracle failures or delayed price updates.
  • Regularly monitor oracle performance and have a contingency plan for oracle-related issues.

Conclusion:

The DittoETH protocol presents a novel approach to decentralized stablecoins with its order book design and supercharged staking yield. While the code demonstrates a modular and organized structure, there are areas that require attention to enhance security which i highlighted and described some of them, mitigate centralization risks, and ensure the robustness of the protocol.

The identified risks and vulnerabilities, such as the complexity of the Diamond proxy pattern, potential for admin abuse, and dependency on accurate price oracles, should be carefully addressed through a combination of technical improvements, governance mechanisms, and thorough testing and auditing.

By implementing the recommended mitigation measures, enhancing code quality, and establishing robust governance processes, the DittoETH protocol can strengthen its security posture, protect user funds, and inspire confidence in its users and the wider DeFi ecosystem.

Time spent:

10 hours

#0 - c4-pre-sort

2024-04-07T20:24:03Z

raymondfam marked the issue as sufficient quality report

#1 - c4-judge

2024-04-17T07:06:03Z

hansfriese marked the issue as grade-b

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax © 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter