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
The logic of the contract will be compared to the business logic provided in the materials provided below:
  • 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
The contract was provided on 26th June 2023 and audit was delivered on 4th July 2023. It was given in the following formats:

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

Audited by:
ZooperDooper
Contract has been audited and cleared to have no clear issues; upon discussion with the lead developer - the context for the contract is to be deployed on a L2 network where gas optimisation is less of a concern. The Suitability for L1 and gas optimisations contains information for how to optimise the contract if deployed on L1; but client has recommended to deploy on L2 instead.
FINDINGS
0 Critical Issues
0 Medium Issues
0 Low Issues
6 Suitability for L1 and gas optimisations
KEY
Critical Issues
Medium Issues
Low Issues
Suitability for L1 and gas optimisations

Issues

Medium Issue
(Addressed) Summary - Potential Issue with directSale

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

Medium Issue
(Addressed) Summary - Potential Issue with bid

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

Nits
Redundant storing per bidIndex

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

Nits
PrimaryAuctionRegistrationFacet

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

Nits
Gas Optimisation

saleToSaleKind[auctionId] is implicitly true when startTimestamp and endTimestamps are set

gbm/saletosale

Suitability for L1 and gas optimisations

Nits
(Addressed) Summary - Gas Optimisation

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

Nits
Gas Optimisation

block.timestamp is emitted in event so dont need to store in to save gas

gbm/timestamp

Suitability for L1 and gas optimisations

Nits
Code readability

alot of duplicated code; e.g. sendbaseCurrency, onlyAdmin; extract it into an inheritable contract

gbm/duplicate

Suitability for L1 and gas optimisations

Nits
Redundant code

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