Cube3

Floating pragmas is a feature of Solidity that allows developers to specify a range of compiler versions that can be used to compile the smart contract code. For security purposes specifically, the usage of floating pragmas is discouraged and not recommended. Contracts should be compiled and deployed with a strict pragma, the one which was thoroughly tested the most by developers. Locking the pragma helps ensure that contracts do not accidentally get deployed using too old or too recent compiler versions that might introduce security issues that impact the contract negatively.It should be noted however that, pragma statements can be allowed to float when a contract is intended for consumption by other developers, as in the case with contracts in a library or EthPM package.The smart contracts of Cube3's core protocol make use of floating pragmas. These are not intended for use as libraries for other developers and, as such, should be locked of their pragma.

The functions transferIntegrationAdmin(), acceptIntegrationAdmin(), updateFunctionProtectionStatus(), and initiateIntegrationRegistration() are capable of modifying the storage of the Router smart contract, yet they do not validate whether the protocol is paused via the function getIsProtocolPaused().

The ProtocolManagement contract defines an installModule() function that saves new module's address into the storage. It was observed that it performs a zero-address check that is then followed by ERC165's supportsInterface() verification. Because the ERC165 standard is used, the zero-address check is redundant as the supportsInterface() function will fail if called on the zero-address. Effectively, the zero-address check is performed twice which incurs a higher gas costs.