ApeIron - Audit 3

The blacklist feature is designed to prevent the blacklisted users from listing NFT/ERC1155 tokens by validating the following **require** statement. ```solidity require( !blacklist.blacklistedNFT(msg.sender, address(_nftAddress), _nftId), "Nft is blacklisted" ); ``` However, this feature can be bypassed by using the `transferFrom()` function defined in `ERC721.sol` and `ERC1155.sol`. The blacklisted user could transfer NFT/ERC1155 tokens to another account and use that account to list NFTs instead.

If a NFT/ERC1155 token is blacklisted *after* being listed, then an uninformed user can still successfully purchase the blacklisted token.

Boolean constants can be used directly and do not need to be compared to `true` or `false`.

The constant `ANY_TOKEN_ID` is equal to the max `uint256` value. Throughout the contract, `ANY_TOKEN_ID` is used to represent blacklisting *ALL* IDs for an NFT/ERC1155 address for a specific user. However, if a user genuinely owns the ID equal to the max `uint256` value of an NFT/ERC1155 address and that ID is blacklisted by `Blacklist.sol`, then the function `blacklistedNFT()` would mistakenly blacklist all the users other token IDs from also being listed on `MarketPlace.sol` and `MarketPlace1155.sol`. Therefore, blacklisting the ID equal to the max `uint256` value would also incorrectly blacklist all the other IDs for a user.

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

In the current implementation, `platformFeePercent` can be set as much as 2^256-1. This can lead to a revert in functions `buyAuctionItem()` and `buyItem()` if `platformFeePercent` is set to be greater than `10000` because the logic during the `sellerRecieve` calculation attempts to subtract `platformFeePercent` from `percentMaxValue` (A constant set to value `10000`). ```solidity function buyItem(...){ ... uint256 sellerReceive = (targetPrice * (percentMaxValue - platformFeePercent)) / percentMaxValue; ... } ``` This situation will automatically revert due to arithmetic underflow in Solidity Versions `^0.8.0`. As a consequence, a revert in the functions `buyAuctionItem()` and `buyItem()` will prevent users from purchasing any listed NFT/ERC1155 tokens.

Addresses should be checked before assignment or external call to make sure they are not zero addresses. --- `_payoutWalletAddress` in contract `MarketPlace.sol` is not zero-checked before being used. ```solidity=200 payoutWalletAddress = _payoutWalletAddress; ``` --- `_payoutWalletAddress` in contract `MarketPlace1155.sol` is not zero-checked before being used. ```solidity=230 payoutWalletAddress = _payoutWalletAddress; ```

The return value of an external call is not stored in a local or state variable. In both linked locations the function `allowance()` is called, but its return value is never utilized. --- In contract `MarketPlace.sol`: ```solidity=214 token.allowance(msg.sender, address(this)); ``` --- In contract `MarketPlace1155.sol`: ```solidity=244 token.allowance(msg.sender, address(this)); ```

The linked statement compares a `uint256` variable to be less than or equal to 0. Since a unsigned integer cannot be less than 0, it is unnecessary to check if the variable is less than 0.

The return value of the `transfer()`/`transferFrom()` calls is not checked. --- In contract `MarketPlace.sol`: ```solidity=368 token.transferFrom(msg.sender, listedItem.seller, sellerReceive); ``` ```solidity=369 token.transferFrom( msg.sender, payoutWalletAddress, payoutWalletReceive ); ``` --- In contract `MarketPlace1155.sol`: ```solidity=373 token.transferFrom(msg.sender, listedItem.seller, sellerReceive); ``` ```solidity=374 token.transferFrom( msg.sender, payoutWalletAddress, payoutWalletReceive ); ```