Erc20RewardMinterFacetStorage Manual Review Findings

ERS-01M: Inexistent Prevention of Token Re-Configuration

Type	Severity	Location
Input Sanitization		Erc20RewardMinterFacetStorage.sol:L146

Description:

The Erc20RewardMinterFacetStorage::setCampaignTransferRewards function does not prevent the same token from being configured twice, causing it to be duplicated in the tokenAddresses array but retain its last amountPerPacket configuration defined.

Impact:

A campaign configured with the same token multiple times will solely retain the last amount per packet configured which is incorrect.

Example:

Copy
134for (uint256 i = 0; i < length; i++) {
135    address tokenAddress = tokenAddresses_[i];
136    uint256 amountPerPacket = amountOfTokensPerPacket_[i];
137
138    if (tokenAddress == address(0)) {
139        revert InvalidZeroRewardPacketAddressData(campaignId, i);
140    }
141    if (amountPerPacket == 0) {
142        revert InvalidZeroRewardPacketAmountData(campaignId, i);
143    }
144
145    campaignPacketInfo.tokenAddresses[i] = tokenAddress;
146    campaignPacketInfo.amountOfTokensPerPacket[tokenAddress] = amountPerPacket;
147}

Recommendation:

We advise such a case to be prohibited, as the same token being configured once for 20 units and once for 30 units should ultimately require 50 units instead of 60.

Alternatively, we advise such a case to be handled properly by incrementing the amountOfTokensPerPacket by the relevant amountPerPacket required.

Alleviation (b64b659786cf3c84bea52feb3a69f546ba3601f0):

A token's reconfiguration is now prevented by keeping track of an isTokenAddressImported mapping, preventing the scenario outlined in the exhibit.