Celer Network

CertiK23 Oct 2020Files named in the report

Audit

CertiK reviewed Celer Network on 23 Oct 2020: 49 findings, 0 critical; 33 marked fixed, 16 open.

No open critical findings

Open the report Open Celer Network’s security record

Report hosted on skynet.certik.com.

Trustblock does not review code.

Findings49

Statuses are the security firm’s own, from its report.

Severity	Open	Fixed
Critical	0	0
High	0	0
Medium	0	0
Low	16	33

LowAbility of Owner to withdraw at WillOpen

The function on the aforementioned line allows the owner of contract to withdraw celerToken funds at will. Although, it does not compromise the security of the system in any way but the owner has to be trusted to maintain the funds of the contract.

LowAbility of Owner to withdraw at WillOpen

LowIncorrect order of functionsOpen

The structure of the codebase does not conform to the official Solidity style guide of v0.5.x .

LowIneffectual if statementOpen

The if statements on the aforementioned lines have hardcoded false conditional as predicate which makes the if statement and its block ineffectual. As the comment at the top of library indicates that it is a code generated library and the rectification may require changes in the tool used to generate this library. The exhibit is informational and can be safely ignored.

LowInefficient storage ReadOpen

The for-loop on the aforementioned lines makes use of inefficient storage read operations on the lines L767 and L768 with the use of d.intentStartIndex . Although, the enclosing function is a view type and is never called from within the contract but a possible call from another contract will be gas inefficient.

LowInexistence of reason in Require StatementsOpen

The require statements on the aforementioned lines do not specify reason string . The reason string s should be provided to require statements to aid debugging and readability of the code.

LowMissing check for the valid inputOpen

The functions on the aforementioned lines has parameter lock end time . There are no checks in the function to assert against a valid value of it which should be greater than block.number .

LowPotential Overflow of bytes ArrayOpen

The addition of idx and len is Unsafe and can potentially overflow resulting in the followed require check potentially passing despite the overflow. Additionally, The require statements on the aforementioned lines check against that the current read index idx should not exceed the length of buf , which is of type bytes . As the idx starts from 0 and the length of buf starts from 1 , if in any case idx is equal to length of buf , the require statement evaluates to true and the memory read in that case would not be a part of buf as the idx would have oveflown

LowRedundant initialization with default valueOpen

The aforementioned lines declare variables of type uint256 and initialize it with 0 . In Solidity, all un-initialized variables have a default value which for the uint256 variable is 0 , hence the initialization part is redundant and can be removed.

LowStorage Updated after External CallOpen

The code on the aforementioned lines update storage after making an external call which violates the checkseffects-interactions pattern and poses threat for reentrancy attack. Reference the Check Effects Interactions pattern: https://fravoll.github.io/solidity-patterns/checks_effects_interactions.html

Show 6 more

LowStorage Updated after External CallOpen

LowSubstitution of require calls with ModifierOpen

The `require` statement on the aforementioned lines can be converted into a modifier to avoid code duplication and increase the legibility of the code.

LowSubstitution of require calls with ModifierOpen

The require statement on the aforementioned lines can be converted into a modifier to avoid code duplication and increase the legibility of the code.

LowSubstitution of require calls with ModifierOpen

The require statement on the aforementioned lines can be converted into a modifier to avoid code duplication and increase the legibility of the code.

LowUsage of `uint` alias instead of `uint256`Open

LowUsage of uint alias instead of uint256Open

The library is using uint to declare 256-bit unsigned integers. Although, uint is an alias for uint256 and both represent the same underlying integer allocation. It is advisable that for clean coding practices the complete form uint256 should be used instead of the alias uint . As the comment at the top of library indicates that it is a code generated library and the rectification may require changes in the tool used to generate this library. The exhibit is informational and can be safely ignored.