QA Report

[code423n4]

QA Report

Coding style improvements

• On line Project.sol:579 change _costToAllocate variable name to _allocationBudget since that better reflects that it's the amount the could be used to allocate tasks.

• unnecessary cast to uint256 on Project.sol:200.

Documentation improvements

• Community.sol:849 "Burn" -> "Mint"

• Project.sol:379 If balance is present then it to the builder. Add word: "transfer" or "send"

---

L-01: For a given project, don't allow lendToProject to be called less than 1 day since last call.

It is extremely unlikely that a lender would work against their own interests but if they were to repeatedly call lendToProject within 1 day then this would lead to unfavourable interest calculations.

If we assume that lastTimestamp for the project is less than 86400 seconds ago then:

• on line 779 claimInterest would not claim any interest
• if a builder were to call repayLender zero interest would also be calculated when claimInterest was called inside the call.

This is because claimInterest calls returnToLender which will then cause _interestEarned to be set to 0. When _interestEarned is zero the state of _communityProject is not updated.

This situation is extremely unlikely which is why I have classified this as Low Risk. However, to prevent user error perhaps the lendToProject should revert if lastTimestamp is less than 1 day ago.

---

L-02: No functionality to change contractor

From time to time it might be necessary to fire a contractor or sub-contractor. There does not appear to be any functionality for this.

---

L-03: No time-locks on admin "setter" functions

Various "setter" functions in HomeFi don't have any time locks enabled on them. Consider using the time-lock pattern for those functions that could introduce an admin rug-pull risk.

---

N-01: allocateFunds may need to be called after Project.lendToProject

Function allocateFunds can fail to complete as it can only allocate _maxLoop == 50 tasks at a time. The builder needs to be aware that they need to call allocateFunds multiple times until an IncompleteAllocation event is not emitted.

It might be a good idea to have two events that distinguish between the two reasons that events are not allocated.

1. _maxLoop tasks allocated
2. Not enough funds