Freename

OpenZeppelin implements several standards for the blockchain and EVM development, some of them pertaining to access control over smart contracts. The two major approaches provided by OpenZeppelin are Ownable and AccessControl. While similar in goals, they are built differently for different use cases.The Ownable standard implements a single owner of smart contracts with a single role that can be used to completely control the child contract. The AccessControl standard builds on top of Ownable and additionally implements a more granular approach with the possibility of having multiple roles that can be assigned to multiple addresses.The MinterRole smart contract implements both access control standards unnecessarily, which may lead to an increased difficulty to maintain different access control mechanisms altogether.

The functions related to minting a second-level domain on MintingManager do not validate if the associated top-level domain already exists. This enables a loophole to exist where a second-level domain is not hierarchically attached to a top-level domain. In the context of the system, this fact should not be true.

OpenZeppelin implements several standards used all across blockchain development, especially in Solidity and the Ethereum Virtual Machine. These standards primary goal is to unify and normalize development patterns so that the entire blockchain may be more understandable and readily usable.The Freename smart contracts implement source code that mimics or is very similar to components already implemented by OpenZepellin, and could therefore, be switched with the more the standard well-known approach. Such source code includes:Pausable.sol contract, can be substituted with OpenZeppellin's implementation of PausableUpgradeable.It should be noted that the usage of bigger libraries does not constitute an overuse of gas, since only the functions that are used are included on the bytecode of the smart contract.

The function _beforeMinting() performs a call to the function isBlocklistDisabled() on line 125. This same call is already performed inside the function isBlocked() that occurs on line 126. Therefore, one of these calls becomes unnecessary and redundant.

The smart contracts RecordStorage and PropertyStorage, KeyStorage and PropertyKeyStorage have similar implementations between them and can be aggregated to decrease code reuse across the system.

The state variables _tokenKeys and _tokenPropertiesKeys, on the RecordStorage and PropertyStorage respectively, are being used as a container for already used key hashes. An EnumerableMap is being used for this state variable, however, an EnumerableSet is sufficient for this purpose.