Core Contracts
Regnum Aurum Acquisition Corp
HardhatReal World AssetsNFT
77,280 USDC
View results
Previous Next
Submission Details
Severity: low
Invalid

Repay Will Revert If `onBehalfOf` is Set to Address(0)

kobbyeugene

Summary

The repayOnBehalf will revert if onBehalfOf is set to address(0)

Vulnerability Details

In the NatSpec, it says is onBehalfOf is set to address(0) it should use the msg.sender as the onBehalfOf but there is a check in the function that will cause the repayOnBehalf to revert.

function repayOnBehalf(uint256 amount, address onBehalfOf) external nonReentrant whenNotPaused onlyValidAmount(amount) {
if (!canPaybackDebt) revert PaybackDebtDisabled();
!-> if (onBehalfOf == address(0)) revert AddressCannotBeZero();
_repay(amount, onBehalfOf);
}
​
​
/**
* @notice Internal function to repay borrowed reserve assets
* @param amount The amount to repay
* @param onBehalfOf The address of the user whose debt is being repaid. If address(0), msg.sender's debt is repaid.
* @dev This function allows users to repay their own debt or the debt of another user.
* The caller (msg.sender) provides the funds for repayment in both cases.
@-> * If onBehalfOf is set to address(0), the function defaults to repaying the caller's own debt.
*/
function _repay(uint256 amount, address onBehalfOf) internal {
if (amount == 0) revert InvalidAmount();
// @audit info natspec says if address(0) it should set onbehalfOf to the caller's address but this revert
!-> if (onBehalfOf == address(0)) revert AddressCannotBeZero();
//...
}

Impact

This can cause a DoS if the user expect the protocol to do what it says it does (use the msg.sender as onBehalfOf)

Tools Used

manual review

Recommendations

remove the zero address check and use the msg.sender as the onBehalfOf

Fees are Accrued In the `LendingPool.sol` But Claimed

YouRevealed upon completion

Summary

The protocol calculates fees (protocolFeeRate) but does not track or collect them, leading to unclaimed revenue.

Vulnerability Details

The protocolFeeRate is set by the owner, but fees are never accrued or stored.

Impact

  • Unclaimed Revenue: Fees accumulate in the contract but are never collected, reducing protocol sustainability.

  • Missed Incentives: No way to reward maintainers or fund future development.

Tools Used

manual review

Recommendations

Add a storage variable (eg., accruedFees) to accumulate fees

No zero address check which can lead to great loss

Summary

In StabilityPoolthere is no zero address check to make sure the address of _liquidityPoolisn't set to a zero address

Vulnerability Details

In the code below, this is a curial set function that is used to set the address of the liquidity pool. If the owner mistakenly sets this to a zero address it can cause great harm to the protocol

/**
* @notice Sets the liquidity pool address.
* @param _liquidityPool Address of the liquidity pool.
*/
function setLiquidityPool(address _liquidityPool) external onlyOwner {
// @audit no zero address check
liquidityPool = _liquidityPool;
emit LiquidityPoolSet(_liquidityPool);
}

Impact

  • Setting the address of liquidity pool to zero address can lead to users losing their funds as they will transfer funds to the LP to either lend of borrow against it

  • If _liquidityPool is set to a zero address, any contract relying on the liquidity pool for deposits or withdrawals will fail to execute properly.

Recommendation

Add a zero address checker to revert whenever the _liquidityPool is set to zero address

function setLiquidityPool(address _liquidityPool) external onlyOwner {
+ if(_liquidityPool == address(0)) revert ZeroAddress();
liquidityPool = _liquidityPool;
emit LiquidityPoolSet(_liquidityPool);
}
Updates

Lead Judging Commences

inallhonesty Lead Judge about 2 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.