Virtualness security record

A mint data signed for one order can be used for another order.If sell.order.trader and sell.order.collection.tokenId are matching with mintData.creators[0].account and mintData.tokenId respectively then other mintData can be used for another order for which that wasn't created. here because other data from the mintData like uri,supply etc is not getting checked ( because the mintData is the way owner/minter provides it) user would be able to change the uri,supply to the other mintData's uri and supply if they use different mintData

isApprovedForAll returns true for all the addresses which have a minter role. This can be problematic where a malicious person with minter role tries to transfer tokens from someone's ( user’s) account to another account using tansferFrom() as the malicious address would be able to transfer even without having approvals.On the other side from the user's perspective users would like to have more control over their token approvals.

isApprovedForAll returns true for all the addresses which have a minter role. This can be problematic where a malicious person with minter role tries to transfer tokens from someone's ( user’s) account to another account using tansferFrom() as the malicious address would be able to transfer even without having approvals.On the other side from the user's perspective users would like to have more control over their token approvals.

base Uri is not getting set in the initialize function , and the contract is doesn't has internal setBaseURI() from ERC1155URIStorageUpgradeable exposed with public function. So that authorized address can call it .While setting uri for tokenIds the _setURI is getting used, where full uri needs to be set.

It can happen that invalid signature may end up recovering invalid signer as the zero address. The used openzeppelin’s ECDSAUpgradeable should revert in the case where it recovers zero address. But it's a good idea to have an extra check in place for handling this situation in lazyMint().

It can happen that invalid signature may end up recovering invalid signer as the zero address. The used openzeppelin’s ECDSAUpgradeable should revert in the case where it recovers zero address. But it's a good idea to have an extra check in place for handling this situation in lazyMint().

In the scenario where address having minter role signs the mintData and later minter role of that address gets removed then while executing the order with that mintData the transaction can revert when lazyMint() checks the signer recovered is owner or the address having minter role, As at that moment the address won’t have the minter role.This scenario should be noted while performing actions such as removing minter role.

In the scenario where address having minter role signs the mintData and later minter role of that address gets removed then while executing the order with that mintData the transaction can revert when lazyMint() checks the signer recovered is owner or the address having minter role, As at that moment the address won’t have the minter role.This scenario should be noted while performing actions such as removing minter role.

(This issue is for information regarding implemented logic and can be acknowledged if this is the intentional logic)Code implements logic for keeping supply limited according to what it gets assigned first. mint_() checks for the case where the amount exceeds the defined supply while minting the tokenId amount.  And because of this in mint(), delegateMint() and in lazyMint() it restricts the supply from exceeding the supply amount that was set earlier.

The team should note that the scenario like this can happen because of the logic of the code, where the user creates a second order while the first order is still there, e.g first user creates an order for 100 tokens and then again for 100 tokens while the old order is still there.