Halborn Logo
← Back to Audits

Ethereum Reserve Dollar - ERD

Prepared by:

Halborn Logo

HALBORN

Last Updated 04/25/2024

Date of Engagement by: June 7th, 2023 - July 12th, 2023

Summary

100% of all REPORTED Findings have been addressed

All findings

6

Critical

0

High

0

Medium

1

Low

1

Informational

4

Table of Contents

1. INTRODUCTION

ERD is a decentralized protocol that allows Ether/LSD (Liquid Staking Derivatives) holders to obtain maximum liquidity against their collateral while paying low interest. After locking up ETH/wrapper ETH as collateral in a smart contract and creating an individual position called a trove, the user can get instant liquidity by minting EUSD, a USD-pegged stablecoin. Each trove is required to be collateralized at a minimum of 110%. Any owner of EUSD can redeem their stablecoins for the underlying collateral at any time. The redemption mechanism along with algorithmically adjusted fees guarantee a minimum stablecoin value of USD 1.

ERD engaged Halborn to conduct a security assessment on their smart contracts beginning on 2023-06-07 and ending on 2023-07-12. The security assessment was scoped to the smart contracts provided to the Halborn team.

2. ASSESSMENT SUMMARY

The team at Halborn was provided five weeks for the engagement and assigned a full-time security engineer to verify the security of the smart contract. The security engineer is a blockchain and smart-contract security expert with advanced penetration testing, smart-contract hacking, and deep knowledge of multiple blockchain protocols.

The purpose of this assessment is to:

    • Ensure that smart contract functions operate as intended.

    • Identify potential security issues with the smart contracts.

In summary, Halborn identified some security risks that were successfully addressed by the ERD team.

3. SCOPE

1. IN-SCOPE:

The security assessment was scoped to the following smart contracts:

    • contracts/Dependencies/*

    • contracts/Interfaces/*

    • contracts/Oracles/*

    • contracts/ActivePool.sol

    • contracts/BorrowerOperations.sol

    • contracts/CollSurplusPool.sol

    • contracts/CollateralManager.sol

    • contracts/CommunityIssuance.sol

    • contracts/DataTypes.sol

    • contracts/DefaultPool.sol

    • contracts/EToken.sol

    • contracts/EUSDToken.sol

    • contracts/Errors.sol

    • contracts/GasPool.sol

    • contracts/HintHelpers.sol

    • contracts/LiquidityIncentive.sol

    • contracts/Migrations.sol

    • contracts/MultiTroveGetter.sol

    • contracts/PriceFeed.sol

    • contracts/SortedTroves.sol

    • contracts/StabilityPool.sol

    • contracts/Treasury.sol

    • contracts/TroveDebt.sol

    • contracts/TroveInterestRateStrategy.sol

    • contracts/TroveLogic.sol

    • contracts/TroveManager.sol

    • contracts/TroveManagerDataTypes.sol

    • contracts/TroveManagerLiquidations.sol

    • contracts/TroveManagerRedemptions.sol

Commit ID: c46e664f30a3ed28a0420afd11788b045527a39a

2. REMEDIATION PR/COMMITS:

4. TEST APPROACH & METHODOLOGY

Halborn performed a combination of manual and automated security testing to balance efficiency, timeliness, practicality, and accuracy in regard to the scope of this assessment. While manual testing is recommended to uncover flaws in logic, process, and implementation; automated testing techniques help enhance coverage of the bridge code and can quickly identify items that do not follow security best practices. The following phases and associated tools were used throughout the term of the assessment:

    • Research into architecture and purpose.

    • Smart contract manual code review and walkthrough.

    • Graphing out functionality and contract logic/connectivity/functions. (solgraph)

    • Manual assessment of use and safety for the critical Solidity variables and functions in scope to identify any arithmetic related vulnerability classes.

    • Manual testing by custom scripts.

    • Scanning of solidity files for vulnerabilities, security hotspots or bugs. (MythX)

    • Static Analysis of security for scoped contract, and imported functions. (Slither)

    • Testnet deployment. (Foundry)

5. RISK METHODOLOGY

Every vulnerability and issue observed by Halborn is ranked based on two sets of Metrics and a Severity Coefficient. This system is inspired by the industry standard Common Vulnerability Scoring System.
The two Metric sets are: Exploitability and Impact. Exploitability captures the ease and technical means by which vulnerabilities can be exploited and Impact describes the consequences of a successful exploit.
The Severity Coefficients is designed to further refine the accuracy of the ranking with two factors: Reversibility and Scope. These capture the impact of the vulnerability on the environment as well as the number of users and smart contracts affected.
The final score is a value between 0-10 rounded up to 1 decimal place and 10 corresponding to the highest security risk. This provides an objective and accurate rating of the severity of security vulnerabilities in smart contracts.
The system is designed to assist in identifying and prioritizing vulnerabilities based on their level of risk to address the most critical issues in a timely manner.

5.1 EXPLOITABILITY

Attack Origin (AO):
Captures whether the attack requires compromising a specific account.
Attack Cost (AC):
Captures the cost of exploiting the vulnerability incurred by the attacker relative to sending a single transaction on the relevant blockchain. Includes but is not limited to financial and computational cost.
Attack Complexity (AX):
Describes the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability. Includes but is not limited to macro situation, available third-party liquidity and regulatory challenges.
Metrics:
EXPLOITABILIY METRIC (mem_e)METRIC VALUENUMERICAL VALUE
Attack Origin (AO)Arbitrary (AO:A)
Specific (AO:S)		1
0.2
Attack Cost (AC)Low (AC:L)
Medium (AC:M)
High (AC:H)		1
0.67
0.33
Attack Complexity (AX)Low (AX:L)
Medium (AX:M)
High (AX:H)		1
0.67
0.33
Exploitability EE is calculated using the following formula:

E=∏meE = \prod m_e

5.2 IMPACT

Confidentiality (C):
Measures the impact to the confidentiality of the information resources managed by the contract due to a successfully exploited vulnerability. Confidentiality refers to limiting access to authorized users only.
Integrity (I):
Measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of data stored and/or processed on-chain. Integrity impact directly affecting Deposit or Yield records is excluded.
Availability (A):
Measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. This metric refers to smart contract features and functionality, not state. Availability impact directly affecting Deposit or Yield is excluded.
Deposit (D):
Measures the impact to the deposits made to the contract by either users or owners.
Yield (Y):
Measures the impact to the yield generated by the contract for either users or owners.
Metrics:
IMPACT METRIC (mIm_I)METRIC VALUENUMERICAL VALUE
Confidentiality (C)None (I:N)
Low (I:L)
Medium (I:M)
High (I:H)
Critical (I:C)		0
0.25
0.5
0.75
1
Integrity (I)None (I:N)
Low (I:L)
Medium (I:M)
High (I:H)
Critical (I:C)		0
0.25
0.5
0.75
1
Availability (A)None (A:N)
Low (A:L)
Medium (A:M)
High (A:H)
Critical (A:C)		0
0.25
0.5
0.75
1
Deposit (D)None (D:N)
Low (D:L)
Medium (D:M)
High (D:H)
Critical (D:C)		0
0.25
0.5
0.75
1
Yield (Y)None (Y:N)
Low (Y:L)
Medium (Y:M)
High (Y:H)
Critical (Y:C)		0
0.25
0.5
0.75
1
Impact II is calculated using the following formula:

I=max(mI)+∑mI−max(mI)4I = max(m_I) + \frac{\sum{m_I} - max(m_I)}{4}

5.3 SEVERITY COEFFICIENT

Reversibility (R):
Describes the share of the exploited vulnerability effects that can be reversed. For upgradeable contracts, assume the contract private key is available.
Scope (S):
Captures whether a vulnerability in one vulnerable contract impacts resources in other contracts.
Metrics:
SEVERITY COEFFICIENT (CC)COEFFICIENT VALUENUMERICAL VALUE
Reversibility (rr)None (R:N)
Partial (R:P)
Full (R:F)		1
0.5
0.25
Scope (ss)Changed (S:C)
Unchanged (S:U)		1.25
1
Severity Coefficient CC is obtained by the following product:

C=rsC = rs

The Vulnerability Severity Score SS is obtained by:

S=min(10,EIC∗10)S = min(10, EIC * 10)

The score is rounded up to 1 decimal places.
SeverityScore Value Range
Critical9 - 10
High7 - 8.9
Medium4.5 - 6.9
Low2 - 4.4
Informational0 - 1.9

6. SCOPE

Out-of-Scope: New features/implementations after the remediation commit IDs.

7. Assessment Summary & Findings Overview

Critical

0

High

0

Medium

1

Low

1

Informational

4

Security analysisRisk levelRemediation Date
PRICE MANIPULATION RISK IN STETHORACLE CONTRACTMediumSolved - 07/17/2023
NON-TRANSFERABLE OWNER IN MIGRATIONS CONTRACTLowSolved - 07/17/2023
POSSIBLE DOS DUE TO COLLATERALMANAGER.COLLATERALSUPPORT SIZEInformationalSolved - 07/17/2023
MISSING A CAP FOR EUSD GAS COMPENSATIONInformationalSolved - 07/17/2023
LONG LITERAL UINT256 USED IN COLLATERALMANAGERInformationalSolved - 07/17/2023
MISSING REQUIREISCONTRACT CHECK IN COLLATERALMANAGER.SETADDRESSES()InformationalSolved - 07/18/2023

8. Findings & Tech Details

8.1 PRICE MANIPULATION RISK IN STETHORACLE CONTRACT

// Medium

Description

If the owner's private key of the contract StETHOracle.sol gets stolen, or the owner himself acts maliciously, it is possible to directly manipulate the price oracle by calling the setPrice() function and updating the lastGoodPrice storage variable without using Chainlink. Hence, all parts of the protocol using fetchPrice_view() would get as a result an incorrect price for the token.

Code Location

StETHOracle.sol

function setPrice(uint _price) external onlyOwner {
    lastGoodPrice = _price;
    emit LastGoodPriceUpdated(_price);
}

StETHOracle.sol

function fetchPrice_view() external view override returns (uint256) {
    return lastGoodPrice;
}
  1. The owner calls setPrice() and significantly decreases the token price.
  2. All active troves now have ICR < MCR, hence can be liquidated.
  3. Liquidate all troves and distribute all the rewards.
  4. Set the correct token price again.
BVSS
Recommendation

SOLVED: The ERD team solved the issue with the following commit ID.

Commit ID : 6657817edcc30b48e41836756a3f41fa34ef779d

8.2 NON-TRANSFERABLE OWNER IN MIGRATIONS CONTRACT

// Low

Description

The owner of the Migrations.sol contract is set in the constructor() and cannot be changed anymore. If there is any issue with the owner account, the contract can be left useless without being able to change the ownership to a new address.

Code Location

Migrations.sol

constructor() {
    owner = msg.sender;
}

Migrations.sol

modifier restricted() {
    if (msg.sender == owner) _;
}
BVSS
Recommendation

SOLVED: The ERD team solved the issue with the following commit ID.

Commit ID : 95ad8f438291ec082f34dab97dc57ecf2494209c

8.3 POSSIBLE DOS DUE TO COLLATERALMANAGER.COLLATERALSUPPORT SIZE

// Informational

Description

The owner of the CollateralManager.sol contract can add new collateral tokens which will be supported by the protocol. When adding support for new collaterals, there is no limit for the current amount of collaterals supported, and as the addresses of the collaterals are pushed to an array (collateralSupport), the size of this array can grow considerably over time.

Hence, when the protocol calls priceUpdate() to update the price of all collaterals supported by the protocol, it iterates over all the collaterals fetching their price from their oracles. In the case the size of the array has grown significantly, it could be possible the price update will revert due to reaching the transaction gas limit.

Code Location

CollateralManager.sol

function addCollateral(
    address _collateral,
    address _oracle,
    address _eTokenAddress,
    uint256 _ratio
) external override onlyOwner {
    require(!getIsSupport(_collateral), Errors.CM_COLL_EXISTS);
    _requireRatioLegal(_ratio);

    collateralParams[_collateral] = DataTypes.CollateralParams(
        _ratio,
        _eTokenAddress,
        _oracle,
        DataTypes.CollStatus(1),
        collateralsCount
    );
    collateralSupport.push(_collateral);
    collateralsCount = collateralsCount.add(1);
}

CollateralManager.sol

function priceUpdate() public override {
    if (collateralsCount < 2) {
        return;
    }
    for (uint256 i = 1; i < collateralsCount; ) {
        IOracle(collateralParams[collateralSupport[i]].oracle).fetchPrice();
        unchecked {
            i++;
        }
    }
}
BVSS
Recommendation

SOLVED: The ERD team solved the issue with the following commit ID.

Commit ID : 93c803ae22a7676e05a1fa6ec884589de28fd619

8.4 MISSING A CAP FOR EUSD GAS COMPENSATION

// Informational

Description

The owner of the CollateralManager.sol contract, when setting the EUSD_GAS_COMPENSATION protocol parameter within setGasCompensation() function, there are no checks regarding the quantity being set.

Code Location

CollateralManager.sol

function setGasCompensation(uint256 _gas) external override onlyOwner {
    EUSD_GAS_COMPENSATION = _gas;
}
Score
Recommendation

SOLVED: The ERD team solved the issue with the following commit ID.

Commit ID : 1961c7fc04181f770468d575b5b402a07b8ab239

8.5 LONG LITERAL UINT256 USED IN COLLATERALMANAGER

// Informational

Description

Critical protocol parameters are set within the initialize() function of CollateralManager.sol contract. Specifically, MCR (minimum collateral ratio) and CCR (critical collateral ratio) are set using a long literal. This can lead to confusion on the percentages configured for the correct functionality of the whole protocol.

Code Location

CollateralManager.sol

function initialize() public initializer {
    __Ownable_init();
    BOOTSTRAP_PERIOD = 14 days;
    MCR = 1100000000000000000; // 110%
    CCR = 1300000000000000000; // 130%
    EUSD_GAS_COMPENSATION = 200e18;
    MIN_NET_DEBT = 1800e18;
    BORROWING_FEE_FLOOR = (DECIMAL_PRECISION / 10000) * 75; // 0.75%

    REDEMPTION_FEE_FLOOR = (DECIMAL_PRECISION / 10000) * 75; // 0.75%
    RECOVERY_FEE = (DECIMAL_PRECISION / 10000) * 25; // 0.25%
    MAX_BORROWING_FEE = (DECIMAL_PRECISION / 100) * 5; // 5%
}
Score
Recommendation

SOLVED: The ERD team solved the issue with the following commit ID.

Commit ID : 0aaf1539e5897aca96034f20f82a0ec1a8d45182

8.6 MISSING REQUIREISCONTRACT CHECK IN COLLATERALMANAGER.SETADDRESSES()

// Informational

Description

In the CollateralManager.sol contract, when setting the contract addresses using setAddresses(), the _requireIsContract() check is missing for _troveManagerRedemptionsAddress.

Code Location

CollateralManager.sol

function setAddresses(
    address _activePoolAddress,
    address _borrowerOperationsAddress,
    address _defaultPoolAddress,
    address _priceFeedAddress,
    address _troveManagerAddress,
    address _troveManagerRedemptionsAddress,
    address _wethAddress
) external override onlyOwner {
    _requireIsContract(_activePoolAddress);
    _requireIsContract(_borrowerOperationsAddress);
    _requireIsContract(_defaultPoolAddress);
    _requireIsContract(_priceFeedAddress);
    _requireIsContract(_wethAddress);
    _requireIsContract(_troveManagerAddress);

    borrowerOperationsAddress = _borrowerOperationsAddress;
    activePool = IActivePool(_activePoolAddress);
    defaultPool = IDefaultPool(_defaultPoolAddress);
    priceFeed = IPriceFeed(_priceFeedAddress);
    wethAddress = _wethAddress;

    troveManager = ITroveManager(_troveManagerAddress);

    troveManagerRedemptionsAddress = _troveManagerRedemptionsAddress;

    emit ActivePoolAddressChanged(_activePoolAddress);
    emit BorrowerOperationsAddressChanged(_borrowerOperationsAddress);
    emit DefaultPoolAddressChanged(_defaultPoolAddress);
    emit PriceFeedAddressChanged(_priceFeedAddress);
    emit TroveManagerAddressChanged(_troveManagerAddress);
    emit TroveManagerRedemptionsAddressChanged(
        _troveManagerRedemptionsAddress
    );
    emit WETHAddressChanged(_wethAddress);
}
Score
Recommendation

SOLVED: The ERD team solved the issue with the following commit ID.

Commit ID : f77899108075aef9f90e1e31ab4e1ab22c20d89c

9. Review Notes

The main goal of the manual testing performed during this assessment was to test all the functionalities regarding the ERD stablecoin overall protocol, focusing on the following points/scenarios:

  1. Tests focused on borrowing EUSD and adding collateral to the troves (as a borrower of the protocol and using multiple collateral tokens)

  2. Open a new trove with ERC20 tokens as collateral.

  3. Open a new trove with ETH as collateral.
  4. Add more collateral to the troves.
  5. Check how the new ICR is calculated.
  6. Check how the new index of the trove is calculated and reinserted.

  1. Tests focused on repaying EUSD and withdrawing collateral from the troves (as a borrower of the protocol and using multiple collateral tokens)

  2. Repay 50% of the trove debt.

  3. Withdraw some collateral from the trove.
  4. Check how the new ICR is calculated.
  5. Check how the new index of the trove is calculated and reinserted.
  6. Check if exist a situation where the borrower cannot repay the debt.

  1. Tests focused on providing liquidity to the stability pool (as an SP depositor of the protocol)

  2. Only one depositor on the system as liquidity provider to the stability pool.

  3. More than one depositor as liquidity providers in the protocol.
  4. Check the flow of the EUSD and collaterals tokens when active troves are updated.
  5. Check the flow of the EUSD and collaterals tokens when a trove is liquidated.

  1. Tests focused on withdrawing liquidity from the stability pool (as an SP depositor of the protocol)

  2. Depositor of EUSD withdrawing liquidity from the stability pool.

  3. Check how the TCR is being affected.
  4. Check how the shares of depositors are being recalculated.

  1. Tests focused on liquidations (checking the mode of the protocol and the different scenarios for closing the troves and distributing the rewards)

  2. Basic checks when ICR < MCR, the trove can be liquidated.

  3. Basic checks when ICR > MCR and TCR < CCR, the trove can be liquidated as well.

  1. Tests depending on the current mode of the protocol (normal or recovery mode, to check which protocol actions are permitted and not permitted during recovery mode)

  2. Check if actions that mint EUSD are not permitted during recovery mode.

  3. Check if actions that burn EUSD are incentivized for users during recovery mode.

  1. Combine and perform integration tests with all the critical functionalities within the protocol (borrowers, depositors, liquidators, redeemers)

  2. Set 4 depositors as liquidity providers to the stability pool.

  3. Set 4 borrowers of EUSD.
  4. Set 2 redeemers of EUSD.
  5. Change the price of the collateral in the oracle.
  6. Redeemers redeem collateral.
  7. Troves being liquidated.
  8. Check the flow of EUSD and collateral tokens and check the priority collateral logic is properly working.

  1. Deeply test all the possible cases of the system state and a specific trove being liquidated to ensure distributions of collaterals and rewards are correctly done as explained within the documentation (between depositors, active troves and the different pools).

  2. ICR < MCR & SP.EUSD >= trove.debt & TCR >= 130%

  3. ICR < MCR & SP.EUSD < trove.debt & TCR >= 130%
  4. ICR < MCR & SP.EUSD = 0 & TCR >= 130%
  5. ICR <=100% & TCR < 130%
  6. 100% < ICR < MCR & SP.EUSD > trove.debt & TCR < 130%
  7. 100% < ICR < MCR & SP.EUSD < trove.debt & TCR < 130%
  8. MCR <= ICR < TCR & SP.EUSD >= trove.debt & TCR < 130%

  1. Tests focused on using multiple collaterals instead of just one type, and analyze how the protocol handles the different user actions involved

  2. Add support for multiple collateral tokens.

  3. Check how the system handles when priority collateral logic is executed.
  4. Check how collaterals are calculated when opening a trove.
  5. Check how collaterals are recalculated when adding a specific collateral to an already active trove.
  6. Check how the system merges the ETH with collaterals into the protocol collaterals array.
  1. Moreover, and very importantly, theoretically review all cases to make sure contracts have the correct business logic for the proper functionality of the stablecoin overall protocol

10. Automated Testing

STATIC ANALYSIS REPORT

Description

Halborn used automated testing techniques to enhance the coverage of certain areas of the scoped contracts. Among the tools used was Slither, a Solidity static analysis framework. After Halborn verified all the contracts in the repository and was able to compile them correctly into their ABI and binary formats, Slither was run on the all-scoped contracts. This tool can statically verify mathematical relationships between Solidity variables to detect invalid or inconsistent usage of the contracts' APIs across the entire code-base.

Slither results

contracts/ActivePool.sol contracts/BorrowerOperations.sol contracts/CollateralManager.sol contracts/PriceFeed.sol contracts/StabilityPool.sol

contracts/TroveManagerLiquidations.sol contracts/TroveManagerRedemptions.sol

  • As a result of the tests carried out with the Slither tool, some results were obtained and reviewed by Halborn. Based on the results reviewed, some vulnerabilities were determined to be false positives. The actual vulnerabilities found by Slither are already included in the report findings.

AUTOMATED SECURITY SCAN

Description

Halborn used automated security scanners to assist with detection of well-known security issues, and to identify low-hanging fruits on the targets for this engagement. Among the tools used was MythX, a security analysis service for Ethereum smart contracts. MythX performed a scan on all the contracts and sent the compiled results to the analyzers to locate any vulnerabilities.

MythX results

1.png

  • No major issues found by Mythx.

Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.

// Download the full report

* Use Google Chrome for best results

** Check "Background Graphics" in the print settings if needed

© Halborn 2024. All rights reserved.