Resonance Security reviewed Cube3 on 14 Aug 2024: 6 findings, 0 critical; 3 marked fixed, 3 open.
Trustblock does not review code.
Statuses are the security firm’s own, from its report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 0 | 0 | 0 |
| Medium | 0 | 0 | 0 |
| Low | 3 | 0 | 3 |
In several places across the codebase, contracts reference addresses of other contracts. A validation is performed that simply verifies whether these addresses are equal to the zero-address. This assures calling only an existing address in the blockchain, however, it does not ensures that this address is able to properly receive the call. Such validation is performed via ERC165's supportsInterface() function which makes sure that a given address implements an expected interface. Additionally, such a validation indirectly asserts that the the given address is a not a zero-address.
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 Cube3 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 is included in:RouterStorage.sol contract pausability features, 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.
It was observed that in certain scenarios it is possible to bypass one REVOKED integration status via another REGISTERED one. The scenario is as follows:Suppose there are two integrations connected to the protocol, one of them is REGISTERED and another one is REVOKED.The malicious owner of a REVOKED integration colludes with the corruptible owner of a REGISTERED integration.The REGISTERED integration calls the function routeToModule directly, however using the arguments received from the REVOKED integration.This results in a REGISTERED integration using the Cube3 protocol for the REVOKED one's benefit effectively bypassing the REVOKED status.It should be noted that any future modules that do not make use of msg.sender will be more impacted by this finding.
The report names a repository or files. Open the report to see its scope.
18 projects reviewed · 25 reports · latest Aug 2025
See Resonance Security’s auditsSomething wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us