Locus Chain - Audit

CertiK1 Dec 20221 address on Ethereum

Audit

CertiK reviewed LOCUS CHAIN (Locus Chain - Audit) on 1 Dec 2022: 14 findings, 0 critical; 1 acknowledged, 13 open.

No open critical findings

Open the report Open LOCUS CHAIN’s security record

Report hosted on skynet.certik.com.

Trustblock does not review code.

Findings14

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

Severity	Open	Acknowledged
Critical	0	0
High	0	1
Medium	0	0
Low	13	0

Low`Approval` Event is not EmittedOpen

The function `transferFrom` deviate from the `ERC20` standard and does not emit `Approval` event for the changed allowance.

LowDeclaration Naming ConventionOpen

Two declarations do not conform to the [Solidity style guide](https://solidity.readthedocs.io/en/v0.7.3/style-guide.html#naming-conventions) with regards to its naming convention. Particularly: - `camelCase`: Should be applied to function names, argument names, local and state variable names, modifiers - `UPPER_CASE`: Should be applied to `constant` variables - `CapWords`: Should be applied to contract names, struct names, event names and enums

LowFunction Should Be Declared ExternalOpen

The functions which are never called internally within the contract should have external visibility for gas optimization.

LowImplicit Return ValueOpen

```solidity=67 function approveAndCall(address _spender, uint _value, bytes _extraData) public returns(bool) { ``` - The function `approveAndCall` implicitly returns a default value.

LowMissing Emit EventsOpen

Functions that update state variables should emit relevant events as notifications.

LowMissing Error MessagesOpen

The **require** statement can be used to check for conditions and throw an exception if the condition is not met. It is better to provide a string message containing details about the error that will be passed back to the caller.

LowMissing Zero Address ValidationOpen

The cited address input is missing a check that it is not `address(0)`.

LowPotential Risk On `approve()`/`transferFrom()` MeOpen

Current Locus implementation is vulnerable to [a known ERC20 race condition issue](https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729), which could lead to token theft. When a user calls `approve()` for a second time on a spender that has already been allowed, the spender could call `transferFrom()` to transfer the previous value and still receive the authorization to transfer the new value. Exploit scenario: 1. Alice calls `approve(Bob, 100)` to allow Bob to spend 100 tokens. 2. Alice changes her mind and calls `approve(Bob, 50)`. 3. Bob observes the second `approve(Bob, 50)` function call and calls `transferFrom(Alice, Bob, 100)` before the second `approve(Bob, 50)` call. 4. The above scenario can be achieved by front-running. In this case, Bob can transfer another 50 tokens from Alice and in total, he transferred 150 tokens from Alice.

LowRedundant `if` StatementOpen

The highlighted `if` statement will always equal `true` because the `approve()` function either reverts or returns true.

LowToo Many DigitsOpen

Literals with many digits are difficult to read and review. ```solidity=15 uint internal constant initialSupply = 7000000000 * (10 ** uint(decimals)); ```

Show 3 more

LowUnlocked and Outdated Compiler VersionOpen

The contracts cited have an unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to differing compiler version numbers. This can lead to ambiguity when debugging, as compiler specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one. Furthermore, the versions of Solidity allowed by the pragma statement are not recommended as they are considered old (0.4.x).

LowUser-Defined GettersOpen

The linked functions are equivalent to the compiler-generated getter functions for the respective variables.

LowVariable Can Be Declared as ImmutableOpen

The variable `tokenOwner` assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation, but will remain constant throughout the lifetime of a deployed contract. An advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they are not located in storage. Please note that `immutable` state variables were introduced in later Solidity releases. Therefore, in order to make use of it, a greater version of Solidity should be used.