[RTU-02C] Redundant Conditional Clause

[dkuppitz]

RTU-02C: Redundant Conditional Clause

Type	Severity	Location
Gas Optimization		RebaseTokenUpgradeable.sol:L78

Description:

The RebaseTokenUpgradeable::_disableRebase function is solely invoked within USTB::disableRebase whereby the new disable state of the account is guaranteed to be different.

Example:

function _disableRebase(address account, bool disable) internal {
    RebaseTokenStorage storage $ = _getRebaseTokenStorage();
    if ($.optOut[account] != disable) {
        uint256 balance = balanceOf(account);
        $.optOut[account] = disable;
        if (balance != 0) {
            if (disable) {
                RebaseTokenUpgradeable._update(account, address(0), balance);
                ERC20Upgradeable._update(address(0), account, balance);
            } else {
                ERC20Upgradeable._update(account, address(0), balance);
                RebaseTokenUpgradeable._update(address(0), account, balance);
            }
        }
        if (disable) emit RebaseDisabled(account);
        else emit RebaseEnabled(account);
    }
}

Recommendation:

We advise the referenced conditional to be omitted from the codebase, optimizing the gas cost of the function.

[dkuppitz]

Thank you for your review and the suggestion made in the audit item RTU-02C regarding the redundant conditional clause in our RebaseTokenUpgradeable contract.

We understand and appreciate the importance of gas optimization and code efficiency. The conditional in question indeed appears redundant within the specific use case of the USTB::disableRebase function. However, we must consider the broader application of the RebaseTokenUpgradeable contract.

The framework we are developing aims to provide a versatile and robust foundation for various projects. The conditional clause within _disableRebase function offers a safeguard against potential misuse and unintended behavior when the function is used in different contexts where the precondition checked by USTB::disableRebase is not guaranteed.

We believe in writing code that is not only efficient but also secure and flexible enough to handle a range of scenarios. Therefore, we've decided to retain the conditional check to ensure that the contract remains resilient and functions correctly across all possible implementations.

While we acknowledge the gas optimizations your suggestion would bring in the current context, we prioritize maintaining the integrity and flexibility of the contract for its future uses.

We are committed to balancing efficiency with versatility and safety in our codebase. We are grateful for your recommendations and will continue to consider them carefully in our ongoing and future development efforts.