WEBTHREE
®Scope of Work
The scope of this audit is based on the material provided by the client. The goal of this audit is to ensure the following:
- Find potential exploits for the contract
- Find issues in the contract that will affect the integrity of the mint
- Ensure the contract adheres to the business logics provided by the client
- Bidders are rewarded when outbid
- GBM auction supports direct sales of the NFTs
- Supports ERC1155 and ERC721
- Owners of NFTs of contracts needs to call explicit withdraw to receive funds
- Auction is extended when bids are placed last minute
- MinBid is configured in the contract
- Each bid has a minimum step increase
Disclaimer
This is a limited report based on our analysis of the Smart Contract audit and performed in accordance with best practices as of the date of this report, in relation to cybersecurity vulnerabilities and issues in the smart contract source code analyzed, the details of which are set out in this report, (hereinafter “Source Code”) and the Source Code compiling, deploying and performing the intended functions. In order to get a full view of our findings and the scope of our analysis, it is crucial for you to read the full report. While we have done our best in conducting our analysis and producing this report, it is important to note that you should not rely on this report and cannot claim against us on the basis of what it says or doesn’t say, or how we produced it, and it is important for you to conduct your own independent investigations before making any decisions.
By reading this report or any part of it, you agree to the terms of this disclaimer. If you do not agree to the terms, then you must immediately cease reading this report, and delete and destroy any and all copies of this report downloaded and/or printed by you. This report is provided for information purposes only and on a non-reliance basis and does not constitute investment advice. No one shall have any right to rely on the report or its contents and the individuals and/or team providing this report owe no duty of care towards you or any other person, nor does the individuals and/or team make any warranty or representation to any person on the accuracy or completeness of the report. The report is provided “as is” without any conditions, warranties, or other terms of any kind except as set out in this disclaimer and the individuals and/or team hereby exclude all representations, warranties, conditions and other terms (including without limitations, the warranties implied by law of satisfactory quality, fitness for purpose and the use of reasonable care and skill) which, but for this clause might have effect in relation to the report.
Except and only to the extend that it is prohibited by law, the individuals and/or team hereby exclude all liability and responsibility, and neither you nor any other person shall have any claim against the individuals and/or team for any amount of kind of loss or damage that may result to you or any other person including without limitation, any direct, indirect, special, punitive, consequential, or pure economic loss or damages, or any loss of income, profits, goodwill, data, contracts, use of money, or business interruption and whether in delict, tort (including without limitation negligence), contract, breach of statutory duty, misrepresentation (whether innocent or negligent) or otherwise under any claim of any nature whatsoever in any jurisdiction) in any way arising from or connected with this report and the use, inability to use or the results of use of this report and an reliance on this report.
Summary

Issues
once setApprovedForAll, there is issues when users are able to call safeTransferFrom as token does not exist in the address that was stored in the write or setApprovedForAll to be false. Opensea negates this by removing the listing, not sure it will be handled it here; but seems like it makes more sense to track movements offchain for each token and negate the auction OR move token directly to the auction contract. Biggest issue is if someone has made an direct sale, they sell it on opensea. New owner tries to create auction and setsApprovalForAll; but old auction executes. Old owner receives the currency and new owner loses their token.
gbm/approval
Issues
When bidAmount is the same at lower gwei values, e.g. 2 (is greater than 1, but the stepIncrease is 10%, so therefore is 2.2 - rounds down to 2 and therefore passes _calculateIncentives require) - this will cause issues with the auction and the user will be able to bid on the same amount and become the highest bidder. Issues are at lower decimal points where it was rounded down.
Suitability for L1 and gas optimisations
instead of incrementing bidIndex and doing a new write to storage, update existing mapping to reduce costs. This will reduce 4 new mapping writes, each first write is 47k gas, overwrites are around 27k Gas. So every new bid = 4 * 47k = 188k gas, every new bid after that is 4 * 27k = 108k gas.
gbm/bidIndex
Suitability for L1 and gas optimisations
Breaks when deployed with no tracking, since escrow mappings are not being updated. Seems far more advantageous to have one variant and use the mappings that already being updated. Or update docs with specifications
Suitability for L1 and gas optimisations
saleToSaleKind[auctionId] is implicitly true when startTimestamp and endTimestamps are set
gbm/saletosale
Suitability for L1 and gas optimisations
For any of the loops, cache tokenIDs.length under a variable to avoid storage reads and use unchecked { i++ }; rather than i++
gbm/loop
Suitability for L1 and gas optimisations
block.timestamp is emitted in event so dont need to store in to save gas
gbm/timestamp
Suitability for L1 and gas optimisations
alot of duplicated code; e.g. sendbaseCurrency, onlyAdmin; extract it into an inheritable contract
gbm/duplicate
Suitability for L1 and gas optimisations
safeRegister721Auction, safeRegister1155auction, safeRegister721DirectSale_User, safeRegister1155DirectSale_User_Batch can be replaced by its batch counterparts; reducing the bytesize of the code and also duplications of code. Concerns are around when maintaining only specific parts of the contract are changed and the rest are not