QA Report

[code423n4]

QA

constants should be defined rather than using magic numbers

There are several occurrences of literal values with unexplained meaning .Literal values in the codebase without an explained meaning make the code harder to read, understand and maintain, thus hindering the experience of developers, auditors and external contributors alike.

Developers should define a constant variable for every magic value used , giving it a clear and self-explanatory name.

File: Community.sol Line 394
1000

            (_projectInstance.lenderFee() + 1000);

File: Community.sol Line 686
86400

            _communityProject.lastTimestamp) / 86400; // 24*60*60

File: Community.sol Line 694
365000

                365000;

File: Project.sol Line 907

unnecessary casting

The type of the variable is the same as the type to which the variable is being cast to
File: Project.sol Line 199

        require(
            projectCost() >= uint256(_newTotalLent),
            "Project::value>required"
        );

The variable _newTotalLent is already of type uint256 so no need to convert it again

Lack of event emission after critical initialize() functions

File: Community.sol Line: 102-119

    function initialize(address _homeFi)
        external
        override
        initializer
        nonZero(_homeFi)
    {
        // Initialize pausable. Set pause to false;
        __Pausable_init();


        // Initialize variables
        homeFi = IHomeFi(_homeFi);
        tokenCurrency1 = homeFi.tokenCurrency1();
        tokenCurrency2 = homeFi.tokenCurrency2();
        tokenCurrency3 = homeFi.tokenCurrency3();


        // Community creation is paused for non admin by default paused
        restrictedToAdmin = true;
    }

File: Project.sol Line 94-105

    function initialize(
        address _currency,
        address _sender,
        address _homeFiAddress
    ) external override initializer {
        // Initialize variables
        homeFi = IHomeFi(_homeFiAddress);
        disputes = homeFi.disputesContract();
        lenderFee = homeFi.lenderFee();
        builder = _sender;
        currency = IDebtToken(_currency);
    }

File: DebtToken.sol Line 43-58

    function initialize(
        address _communityContract,
        string memory name_,
        string memory symbol_,
        uint8 decimals_
    ) external override initializer {
        // Revert if _communityContract is zero address. Invalid address.
        require(_communityContract != address(0), "DebtToken::0 address");
        // Initialize ERC20
        __ERC20_init(name_, symbol_);
        // Store details
        _decimals = decimals_;
        communityContract = _communityContract;
    }

File: ProjectFactory.sol Line 45-55

    function initialize(address _underlying, address _homeFi)
        external
        override
        initializer
        nonZero(_underlying)
        nonZero(_homeFi)
    {
        // Store details
        underlying = _underlying;
        homeFi = _homeFi;
    }

File: Disputes.sol Line 74-81

    function initialize(address _homeFi)
        external
        override
        initializer
        nonZero(_homeFi)
    {
        homeFi = IHomeFi(_homeFi);
    }

File: HomeFi.sol Line 92
https://github.com/code-423n4/2022-08-rigor/blob/b17b2a11d04289f9e927c71703b42771dd7b86a4/contracts/HomeFi.sol#L92-L120

Unused named return

Using both named returns and a return statement isn’t necessary in a function.To improve code quality, consider using only one of those.

File: Project.sol Line 716-723

    function getAlerts(uint256 _taskID)
        public
        view
        override
        returns (bool[3] memory _alerts)
    {
        return tasks[_taskID].getAlerts();
    }