Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

QA Report #199

Open
code423n4 opened this issue Jul 4, 2022 · 0 comments
Open

QA Report #199

code423n4 opened this issue Jul 4, 2022 · 0 comments
Labels
bug Something isn't working QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax

Comments

@code423n4
Copy link
Contributor

Unused import of OpenZeppelin String.sol in PuttyV2Nft.sol

PuttyV2Nft.sol is importing import "openzeppelin/utils/Strings.sol"; but is never using that library inside the code.

Consider removing it.

PuttyV2Nft.sol miss natspec documentation

Natspec documentation are useful for internal developers that need to work on the project, external developers that need to integrate with the project, auditors that have to review it but also for end users given that Etherscan has officially integrated the support for it directly on their site.

The PuttyV2Nft contract is missing natspec documentation for all the function. A well detailed natspec documentation would be important to describe the current implementation difference for _mint, transferFrom and balanceOf functions.

Consider adding natspec documentation to the contract.

Orders should not be cancellable multiple times or after being filled

The cancelledOrders mapping state variable is only used by fillOrder to prevent to fill an already cancelled order.

To prevent confusion, the protocol should prevent:

  1. the order.maker to cancel order multiple times and as a result emitting multiple time the CancelledOrder event
  2. the order.maker cancel an order after being filled. Even if it does not impact any logic inside the contract, it still could confuse users interacting directly with the contract/websites that use that information or even with monitoring tools that rely on those events/state variables

Consider preventing order.maker to call the cancel order if the order had been filled or have been already cancelled.

Note: If the protocol implement this solution, they should also consider to "skip" the cancel call inside acceptCounterOffer if the originalOrdr has been cancelled, otherwise the acceptCounterOffer tx would revert.

@code423n4 code423n4 added bug Something isn't working QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax labels Jul 4, 2022
code423n4 added a commit that referenced this issue Jul 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax
Projects
None yet
Development

No branches or pull requests

1 participant