There are several instances of numbers used in code that are not readable e.g 100000 which is 100,000 Solidity allows
the use of underscore to seperate in 1000's e.g 100_000 and this is not used for these long number literals
Several instances with values that are not readable. This way is error prone and difficult to read
Lender.sol line 59 uint256 public constant MAX_INTEREST_RATE = 100000;
Lender.sol line 63 uint256 public lenderFee = 1000;
Lender.sol line 85 if (_fee > 5000) revert FeeTooHigh();
Lender.sol line 265 uint256 fees = (debt * borrowerFee) / 10000;
Lender.sol line 724 interest = (l.interestRate * l.debt * timeElapsed) / 10000 / 365 days; // and line 725
Fees.sol line 34 fee: 3000,
Informational: Having such numbers in code is prone to error and leads to readability issues which affect maintainability, usability, interpretability, auditability of code. Its very easy to leave out a 0 if using this format.
Manual Analysis
uint256 public constant MAX_INTEREST_RATE = 100000; -> uint256 public constant MAX_INTEREST_RATE = 100_000;
uint256 public lenderFee = 1000; -> uint256 public lenderFee = 1_000;
if (_fee > 5000) revert FeeTooHigh(); -> if (_fee > 5_000) revert FeeTooHigh();
uint256 fees = (debt * borrowerFee) / 10000; -> uint256 fees = (debt * borrowerFee) / 10_000;
interest = (l.interestRate * l.debt * timeElapsed) / 10000 / 365 days; -> interest = (l.interestRate * l.debt * timeElapsed) / 10_000 / 365 days;
fees = (lenderFee * interest) / 10000; -> fees = (lenderFee * interest) / 10_000;
fee: 3000, -> fee: 3_000,
Correct above instances and any other in the project to improve readability of code and reduce chances of errors
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.