Gas Optimizations

[code423n4]

Unnecessary equals boolean

Boolean variables can be checked within conditionals directly without the use of equality operators to true/false.

Code instance:

    Community.sol, 272: if (_publishFee == 0) _communityProject.publishFeePaid = true;

State variables that could be set immutable

In the following files there are state variables that could be set immutable to save gas.

Code instances:

    builder in Project.sol
    proxyAdmin in HomeFiProxy.sol
    disputes in Project.sol
    lenderFee in Project.sol
    homeFi in Project.sol
    currency in Project.sol
    _decimals in DebtToken.sol

Unused state variables

Unused state variables are gas consuming at deployment (since they are located in storage) and are
a bad code practice. Removing those variables will decrease deployment gas cost and improve code quality.
This is a full list of all the unused storage variables we found in your code base.

Code instances:

    HomeFiV3Mock.sol, newVariable
    Project.sol, VERSION

Prefix increments are cheaper than postfix increments

Prefix increments are cheaper than postfix increments.
Further more, using unchecked {++x} is even more gas efficient, and the gas saving accumulates every iteration and can make a real change
There is no risk of overflow caused by increamenting the iteration index in for loops (the ++i in for (uint256 i = 0; i < numIterations; ++i)).
But increments perform overflow checks that are not necessary in this case.
These functions use not using prefix increments (++x) or not using the unchecked keyword:

Code instances:

    change to prefix increment and unchecked: HomeFiProxy.sol, i, 136
    change to prefix increment and unchecked: Community.sol, i, 624
    change to prefix increment and unchecked: Project.sol, _taskID, 710
    change to prefix increment and unchecked: HomeFiProxy.sol, i, 87
    change to prefix increment and unchecked: Project.sol, i, 322
    change to prefix increment and unchecked: Tasks.sol, i, 181
    change to prefix increment and unchecked: Project.sol, i, 248
    change to prefix increment and unchecked: Project.sol, i, 311

Unnecessary index init

In for loops you initialize the index to start from 0, but it already initialized to 0 in default and this assignment cost gas.
It is more clear and gas efficient to declare without assigning 0 and will have the same meaning:

Code instances:

    Community.sol, 624
    Project.sol, 311
    Tasks.sol, 181
    Project.sol, 322
    HomeFiProxy.sol, 136
    Project.sol, 248
    HomeFiProxy.sol, 87

Storage double reading. Could save SLOAD

Reading a storage variable is gas costly (SLOAD). In cases of multiple read of a storage variable in the same scope, caching the first read (i.e saving as a local variable) can save gas and decrease the
overall gas uses. The following is a list of functions and the storage variables that you read twice:

Code instances:

    Project.sol: builder is read twice in raiseDispute
    Project.sol: taskCount is read twice in allocateFunds
    Project.sol: totalLent is read twice in allocateFunds

Rearrange state variables

You can change the order of the storage variables to decrease memory uses.

Code instances:

In Community.sol,rearranging the storage fields can optimize to: 5 slots from: 6 slots.
The new order of types (you choose the actual variables):
1. IHomeFi
2. uint256
3. address
4. bool
5. address
6. address

In Project.sol,rearranging the storage fields can optimize to: 13 slots from: 14 slots.
The new order of types (you choose the actual variables):
1. IHomeFi
2. IDebtToken
3. uint256
4. uint256
5. uint256
6. uint256
7. uint256
8. uint256
9. uint256
10. uint256
11. address
12. bool
13. bool
14. address
15. address

Use != 0 instead of > 0

Using != 0 is slightly cheaper than > 0. (see code-423n4/2021-12-maple-findings#75 for similar issue)

Code instances:

    Project.sol, 195: change '_cost > 0' to '_cost != 0'
    Community.sol, 764: change '_repayAmount > 0' to '_repayAmount != 0'

Consider inline the following functions to save gas

You can inline the following functions instead of writing a specific function to save gas.
(see https://github.com/code-423n4/2021-11-nested-findings/issues/167 for a similar issue.)


    Tasks.sol, getState, { return uint256(_self.state); }

Inline one time use functions

The following functions are used exactly once. Therefore you can inline them and save gas and improve code clearness.

Code instances:

    Disputes.sol, executeTaskChange
    Disputes.sol, executeTaskPay
    Disputes.sol, resolveHandler
    Project.sol, autoWithdraw
    SignatureDecoder.sol, toEthSignedMessageHash