The repayOnBehalf will revert if onBehalfOf is set to address(0)
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.
This can cause a DoS if the user expect the protocol to do what it says it does (use the msg.sender as onBehalfOf)
manual review
remove the zero address check and use the msg.sender as the onBehalfOf
YouRevealed upon completion
The protocol calculates fees (protocolFeeRate) but does not track or collect them, leading to unclaimed revenue.
The protocolFeeRate is set by the owner, but fees are never accrued or stored.
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.
manual review
Add a storage variable (eg., accruedFees) to accumulate fees
In StabilityPoolthere is no zero address check to make sure the address of _liquidityPoolisn't set to a zero address
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
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.
Add a zero address checker to revert whenever the _liquidityPool is set to zero address
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.