Unikura security record

Upon the initialization of the `UnikuraPhygitalCollection` contract, all tokens are minted to the `salesAddress`. Such design is not documented and it is unclear why the `salesAddress` receives max token supply. In case of compromise of this address, a malicious user can have access to a vast majority of the token supply.

Multiple contracts under audit feature privileged roles with special permission. It is also important for project users to be aware of the privileged roles and their permissions so that they are aware of all potential risks. All of the below contracts feature some privileged roles: 1. `UnikuraMembership` 1. `owner` 1. Mint a gold or silver membership NFT to any address: `mint()`. 2. Set the URI for the token metadata: `setURI()`. 3. Set the sales address for the token: `setSalesAddress()`. 4. Set the address which can burn tokens `setBurnAddress()`. 2. `burnAddress`: Can burn any tokens from any address: `burn()`. 3. `salesAddress`: May hold more than one membership token at a time. 2. `UnikuraMothership`: `owner`: 1. Set the fee percentage: `setFeePercentage()`. 2. Set the fee recipient address: `setVelvettFeeRecipient()`. 3. Set the address of the membership contract: `setUnikuraMembershipContract()`. 3. `UnikuraPhygitalCollection`: `owner`: 1. Set the URI for the token metadata: `setBaseURI()`. 2. Set the address of the mothership contract: `setUnikuraMothershipContract()`. 3. Set the sales address: `setSalesAddress()`. 4. Set the mint price per token `setMintPrice()`.

Gas usage is a significant concern for smart contract developers and users, since high gas costs may deter users using the smart contract. Even worse, some gas usage issues may prevent the contract from providing services entirely. For example, if a loop requires too much gas to finish processing, then it may entirely prevent the contract from functioning correctly. We’ve identified the following instance in which unbounded looping may be a cause for concern: * `mint()`

The following key concepts are not mentioned in the documentation: - Membership, particularly the difference between gold and silver membership. - Sales account - Fee percentage - System owner address and related key managements

There is currently no explicit function or modifier implemented to distinguish an address's membership token, beside `balanceOf()`. It is currently unclear whether such functionality may be useful in further development.

By design, the sales address defined by `UnikuraMembership` is supposed to be the only address besides the owner that can hold multiple tokens (as documented in `UnikuraMothership.sol`, *The contract owner or sales address is allowed to own multiple*). However, the `setSalesAddress()` function can change the sales address. If the previous sales address already had multiple tokens, this would allow multiple addresses to hold several tokens.

While upgradability is not a vulnerability in itself, token holders should be aware that the token contract can be upgraded at any given time. This audit does not guarantee the behavior of future contracts that the token may be upgraded to.