Description

The leaf nodes of the Merkle tree contain only the user addresses and do not include the tokenId or the address of mnERC1155 to be minted. As a result, a user can potentially use a Merkle proof expected for minting tokens with tokenId x to mint tokens with tokenId y, or even mint tokens on an entirely different mnERC1155 contract.

Here is an example. In this scenario, we will consider tokenId y to be more valuable than tokenId x, and the claimWhitelist array contains a Merkle root where the user is eligible to mint n number of tokens with tokenId x.

The potential issue arises from the fact that even though it might be expected for the user to call claim using the correct Merkle proof to mint their x tokens, they might choose not to do so and instead wait for the admin to change the tokenId using the function setTokenId. If the admin later changes the tokenId from x to y, the user can now simply call claim to claim n number of y tokens instead of x tokens.

This behavior could lead to unintended economic consequences, as the user could take advantage of the situation to obtain more valuable y tokens rather than the originally intended x tokens.

Impact

If either setTokenId or setMightyNetERC1155Address is called to change the tokenId or mnERC1155 address before all the tokens are claimed, and the claimWhitelist is not fully cleared out, it could potentially result in the minting of different tokens than originally expected.

Recommendations

To address this issue, it is recommended to ensure that claimWhitelist is completely cleared out before invoking setTokenId or setMightyNetERC1155Address. By doing so, any potential misuse of old Merkle proofs to mint new tokens can be prevented. Alternatively, you can consider including the tokenId and the address of ERC-1155 in the Merkle trees, which can also help mitigate the problem.

Remediation

Mighty Bear Games provided the following response:

We acknowledge the concerns related to the possibility of unintended token minting. However, it's important to note that this contract is designed for a specific use case, where only one item from one collection can be claimed. We assure you that we will not reuse the same contract for multiple claim or mint events. Instead, for each new event, a fresh contract will be deployed.

The reason for implementing the SetTokenId function is to maximize flexibility in case we encounter any misconfigurations or issues after deployment. Should any problems arise, we will be able to pause the contract, make the necessary adjustments, and then resume its functionality.