[BTE-01C] Inefficient `mapping` Lookups

[chasebrownn]

BTE-01C: Inefficient mapping Lookups

Type	Severity	Location
Gas Optimization		Basket.sol:L296, L297, L348, L351, L673, L687, L786, L790, L798, L799, L860, L1044, L1076, L1077

Description:

The linked statements perform key-based lookup operations on mapping declarations from storage multiple times for the same key redundantly.

Example:

/**
 * @notice This method is executed upon the callback of vrf for entropy. This method will use the randomWord to select
 *         a ranom index from the `depositedTnfts` array to be next redeemable NFT.
 * @param randomWord Random uint seed received from vrf.
 */
function fulfillRandomSeed(uint256 randomWord) external onlyBasketVrfConsumer {

    // choose a nft to be next redeemable

    uint256 index;
    index = randomWord % depositedTnfts.length;

    address tnft = depositedTnfts[index].tnft;
    uint256 tokenId = depositedTnfts[index].tokenId;

    nextToRedeem = RedeemData(tnft, tokenId);
    emit RedeemableChosen(tnft, tokenId);

    seedRequestInFlight = false;
    pendingSeedRequestId = 0;
}

Recommendation:

As the lookups internally perform an expensive keccak256 operation, we advise the lookups to be cached wherever possible to a single local declaration that either holds the value of the mapping in case of primitive types or holds a storage pointer to the struct contained.

[chasebrownn]

Acknowledged