Sequence security record

Events are important for signalling state changes in a contract. This helps debug the contract in the event of any attacks or critical bugs and helps indicate to users any configuration changes in the contract. A non-exhaustive list of functions where events can be useful includes: 1. `ERC20Items.setNameAndSymbol()` 1. `ERC721BaseToken.setNameAndSymbol()` 1. `ERC721BaseToken.setBaseMetadataURI()` 1. `ERC721BaseToken.setContractURI()` 1. `ERC1155BaseToken. setBaseMetadataURI()` 1. `ERC1155BaseToken.setContractName()` 1. `ERC1155BaseToken.setContractURI()`

When a user wants to purchase a given ERC-721 or ERC-1155 token, they can create an order that states the token to purchase and the price they will pay (offer). This is done by creating an order where `isListing` is set to `false`. Then, the owner of the ERC-721 or ERC-1155 token (the maker) can fill the order, if desirable, by calling `acceptOrder()`. When the order is filled, the taker (the order creator) needs to pay the price they stated in their order and the royalty fee accrued from the swap. Therefore, if the order maker also owns the ERC-721 or ERC-1155 contract, they could increase the royalty fee rate and then accept the order. Thus, the order taker will pay the cost of the purchased token and the increased royalty fee.

If the owner renounces their ownership, all ownable contracts will be left without an owner. As a result, any function guarded by the `onlyOwner` modifier will no longer be able to be executed, such as upgrading the `UpgradeableBeacon` implementation contract in `SequenceProxyFactory`. Furthermore, critical role transfers do not follow a two-step pattern. The two-step pattern ensures that there is an additional layer of verification and authorization before transferring critical roles, reducing the risk of unauthorized access or malicious actions. This also applies to contracts inheriting from `AccessControl`. Renouncing `DEFAULT_ADMIN_ROLE` will leave the contract without an administrator.

Every Solidity file specifies in the header a version number of the format `pragma solidity (^)0.8.*`. The caret (`^`) before the version number implies an unlocked pragma, meaning that the compiler will use the specified version and above, hence the term "unlocked". The pragma versions used throughout the codebase should not be unlocked and set to the same version to ensure that they are all compiled by the same compiler version.

While upgradability is not a vulnerability in itself, contract users should be aware that the contracts can be upgraded at any given time by their owner. This audit does not guarantee the behavior of future contracts that the token may be upgraded to. The Sequence team and contract owners should test the new implementation before upgrading to avoid issues such as function selector collisions or storage slot collisions.

`Orderbook` orders accept any address as an ERC-20 token. This token will be used in the offer/listing to pay for the ERC-721 or ERC-1155 tokens. However, special ERC-20 tokens that implement changes in the amount transferred (such as on-transfer fee tokens) can lead to potential issues when accepting the orders (not receiving the expected amount of fees or royalties, or a user not receiving the expected payment). Malicious users can also create orders with tokens implementing transfer functions with malicious code.

When a user creates an offer, `_createOrder()` verifies that enough allowance was provided to cover the new order. However, he can create more offers as long as their total amount is equal or less than the allowance of the contract. `isOrderValid()` can be affected as well, as it verifies each order independently.

Function `isValidSignature ` in `ModuleAuth` is missing a return statement for the else branch. While this does not pose a problem in the current system, a future potential caller attempting to decode the returned byte value may fail.

As pointed by an internal code review of the 0xSequence wallet contributors, there are unhandled possible overflows on lines `LibBytes.sol#146` and `LibBytes.sol#185`. Quantstamp confirmed that the calls currently made to the functions in question cannot reach the overflow state, this does not need to be the case for future uses of these function.