Gas Optimizations

[code423n4]

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:

    StakingStorage.sol, COW_RELAYER
    StakingStorage.sol, affiliateFee
    StakingStorage.sol, curvePoolFrom
    YieldyStorage.sol, creditBalances
    YieldyStorage.sol, ADMIN_ROLE
    StakingStorage.sol, COW_SETTLEMENT
    StakingStorage.sol, warmUpPeriod
    StakingStorage.sol, lastTokeCycleIndex
    ERC20PermitUpgradeable.sol, __gap
    YieldyStorage.sol, rebasingCreditsPerToken
    YieldyStorage.sol, stakingContract
    LiquidityReserveStorage.sol, MINIMUM_LIQUIDITY
    StakingStorage.sol, BASIS_POINTS
    StakingStorage.sol, warmUpInfo
    StakingStorage.sol, withdrawalAmount
    YieldyStorage.sol, MAX_SUPPLY
    StakingStorage.sol, TOKE_MANAGER
    YieldyStorage.sol, index
    YieldyStorage.sol, rebases
    StakingStorage.sol, LIQUIDITY_RESERVE
    StakingStorage.sol, coolDownPeriod
    YieldyStorage.sol, MAX_UINT256
    LiquidityReserveStorage.sol, isReserveEnabled
    StakingStorage.sol, TOKE_TOKEN
    StakingStorage.sol, timeLeftToRequestWithdrawal
    LiquidityReserveStorage.sol, BASIS_POINTS
    StakingStorage.sol, YIELDY_TOKEN
    StakingStorage.sol, TOKE_POOL
    StakingStorage.sol, coolDownInfo
    StakingStorage.sol, curvePoolTo
    YieldyStorage.sol, WAD
    StakingStorage.sol, STAKING_TOKEN
    StakingStorage.sol, requestWithdrawalAmount
    StakingStorage.sol, CURVE_POOL
    ERC20PermitUpgradeable.sol, _PERMIT_TYPEHASH_DEPRECATED_SLOT
    StakingStorage.sol, TOKE_REWARD
    StakingStorage.sol, isInstantUnstakingPaused
    StakingStorage.sol, FEE_ADDRESS
    StakingStorage.sol, isStakingPaused
    YieldyStorage.sol, decimal
    LiquidityReserveStorage.sol, stakingContract
    LiquidityReserveStorage.sol, rewardToken
    StakingStorage.sol, isUnstakingPaused

Rearrange state variables

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

Code instances:

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

Short the following require messages

The following require messages are of length more than 32 and we think are short enough to short
them into exactly 32 characters such that it will be placed in one slot of memory and the require
function will cost less gas.
The list:

Code instances:

    Solidity file: ERC20Upgradeable.sol, In line 281, Require message length to shorten: 38, The message: ERC20: transfer amount exceeds balance
    Solidity file: ERC20Upgradeable.sol, In line 362, Require message length to shorten: 36, The message: ERC20: approve from the zero address
    Solidity file: ERC20Upgradeable.sol, In line 363, Require message length to shorten: 34, The message: ERC20: approve to the zero address
    Solidity file: ERC20Upgradeable.sol, In line 245, Require message length to shorten: 37, The message: ERC20: decreased allowance below zero
    Solidity file: ERC20Upgradeable.sol, In line 275, Require message length to shorten: 37, The message: ERC20: transfer from the zero address
    Solidity file: ERC20Upgradeable.sol, In line 189, Require message length to shorten: 40, The message: ERC20: transfer amount exceeds allowance
    Solidity file: ERC20Upgradeable.sol, In line 333, Require message length to shorten: 34, The message: ERC20: burn amount exceeds balance
    Solidity file: ERC20Upgradeable.sol, In line 328, Require message length to shorten: 33, The message: ERC20: burn from the zero address
    Solidity file: ERC20Upgradeable.sol, In line 276, Require message length to shorten: 35, The message: ERC20: transfer to the zero 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:

    ERC20Upgradeable.sol, 333: change 'balance > 0' to 'balance != 0'
    Staking.sol, 572: change '_amount > 0' to '_amount != 0'
    LiquidityReserve.sol, 171: change 'balance > 0' to 'balance != 0'
    Yieldy.sol, 286: change 'balance > 0' to 'balance != 0'
    Staking.sol, 604: change '_amount > 0' to '_amount != 0'

Use unchecked to save gas for certain additive calculations that cannot overflow

You can use unchecked in the following calculations since there is no risk to overflow:

Code instance:

    Staking.sol (L#361) - block.timestamp + timeLeftToRequestWithdrawal >= nextCycleStart &&

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:

    Staking.sol, _sendAffiliateFee
    Yieldy.sol, _setIndex
    ERC20Upgradeable.sol, __ERC20_init_unchained
    Yieldy.sol, _mint
    Staking.sol, contractBalance
    Staking.sol, _getTokemakBalance
    Yieldy.sol, _storeRebase
    LiquidityReserve.sol, _calculateReserveTokenValue
    Staking.sol, _isClaimWithdrawAvailable
    Yieldy.sol, _burn
    ERC20PermitUpgradeable.sol, _useNonce