Is NEXO Safe? Smart Contract Security Analysis

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Audit History

2 audits on record

Jul 2379

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

The audit of the NexoToken contract revealed several areas for improvement, primarily concerning inconsistent application of SafeMath, the use of an outdated Solidity compiler, and centralized control by the contract owner. While the contract implements basic ERC-20 functionality and a two-step ownership transfer, critical arithmetic operations bypass SafeMath, posing a risk of integer underflow. The vesting logic, though defined, is incomplete in the provided source, limiting a full assessment.

Final Recommendation: It is strongly recommended to update the Solidity compiler to a more recent, stable version (e.g., 0.8.x) to benefit from modern security features and bug fixes. Crucially, all arithmetic operations involving user balances and allowances must consistently utilize the `SafeMath` library to prevent potential integer underflow vulnerabilities. A thorough review of the owner's privileges and the complete vesting logic is also advised to ensure alignment with the project's security and economic requirements.

Category Ratings

TechnicalMedium

6/10

The technical architecture (7.1) is a standard ERC-20 token inheriting from `Owned` and `SafeMath`. Code security (7.2) is a primary concern due to inconsistent SafeMath usage in `_transfer` and `transferFrom` functions, which directly use `-=` for balance and allowance updates, bypassing underflow

GovernanceHigh

1/10

The contract's economic model (7.4) involves fixed allocations for investors, overdraft, and team, with defined vesting parameters, though the full vesting implementation is not provided. Governance (7.5) is highly centralized, with a single owner having significant control, including the abili

UpgradesMedium

6/10

The contract is not designed with any upgradeability mechanism (7.7). It is a standard, non-proxy implementation, meaning its logic cannot be modified after deployment. This eliminates upgrade-specific risks but also removes the possibility of patching vulnerabilities or adding new features without

LP Distribution

Top-1 Unlocked Holder59.2%

Top-3 Unlocked80.3%

What Raised This Score

8 factors

Ownership NOT renounced — owner is an EOA (single private key)
Top-10 concentration > 70% (93.7% total → 93.7% effective; 93.7% in EOAs, 0.0% in contracts — extreme)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 59.2% (independent LP — depth risk, pool = 98% of DEX liquidity)
LP top3 unlocked holders = 80.3% (independent LP — depth risk, pool = 98% of DEX liquidity)
1 High finding(s) from audit
2 Medium finding(s) from audit
2 Low finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Security Findings

6 total

1 High 2 Medium 2 Low 1 Info

H-01HighUnresolved

Inconsistent SafeMath Usage Leading to Potential Underflow

The `StandardToken._transfer` function directly uses `balances[_from] -= _value;` and the `StandardToken.transferFrom` function directly uses `allowed[_from][msg.sender] -= _value;` without utilizing the `SafeMath.sub` function. This bypasses the intended underflow protection provided by the `SafeMath` library, making these operations vulnerable to integer underflow if `_value` exceeds the current balance or allowance.

Recommendation: Ensure all subtraction operations on `uint256` variables, especially those involving user balances or allowances, consistently use `SafeMath.sub`. For example, change `balances[_from] -= _value;` to `balances[_from] = sub(balances[_from], _value);` and `allowed[_from][msg.sender] -= _value;` to `allowed[_from][msg.sender] = sub(allowed[_from][msg.sender], _value);`.

M-01MediumUnresolved

Outdated Solidity Compiler Version

The contract is compiled with Solidity version `0.4.23`. This version is significantly outdated and lacks many security improvements, bug fixes, and best practices introduced in later versions (e.g., 0.5.x, 0.6.x, 0.8.x). Using an old compiler version can expose the contract to known compiler-specific vulnerabilities or less efficient gas usage patterns.

Recommendation: Upgrade the Solidity compiler version to a recent, stable release (e.g., `^0.8.0`). This will provide access to modern security features, improved error handling (e.g., `require` for revert reasons), and better gas optimization. Thoroughly test the contract after upgrading the compiler to ensure compatibility and correct behavior.

M-02MediumUnresolved

Use of `now` for `creationTime`

The `creationTime` variable is set using `now` (an alias for `block.timestamp`). While common, `block.timestamp` can be manipulated by miners within a certain range (up to 900 seconds on Ethereum). If `creationTime` is used in any time-sensitive logic that requires precise, unmanipulable timing, this could be a concern.

Recommendation: Evaluate if the `creationTime` variable is used in any critical, time-sensitive operations. If so, consider alternative, more robust time sources or acknowledge the potential for miner manipulation. For simple informational purposes, `block.timestamp` is generally acceptable.

L-01LowUnresolved

Missing Division by Zero Check in SafeMath.div

The `SafeMath.div` function does not explicitly check if the divisor `b` is zero. While Solidity's default behavior for division by zero is to revert, an explicit `require(b != 0, 'SafeMath: division by zero');` would provide clearer error messaging and adhere to a more robust defensive programming style.

Recommendation: Add an explicit check for division by zero at the beginning of the `div` function: `require(b != 0, 'SafeMath: division by zero');`.

L-02LowUnresolved

Centralized Control by Owner

The `Owned` pattern grants significant control to a single `owner` address. This owner can recover any ERC20 tokens accidentally sent to the contract via `transferERC20Token`. While the `setOwner` and `confirmOwnership` functions provide a two-step transfer mechanism, the owner remains a single point of failure and trust, which could pose a risk if the owner's private key is compromised.

Recommendation: Consider implementing a multi-signature wallet (e.g., Gnosis Safe) for the `owner` address to distribute control and reduce the risk associated with a single point of failure. This enhances security by requiring multiple approvals for critical operations.

I-01InformationalUnresolved

Truncated Vesting Logic

The provided source code for the `NexoToken` contract includes definitions for vesting parameters (e.g., `overdraftCliff`, `overdraftPeriodLength`, `teamPeriodAmount`) but the actual functions responsible for implementing the vesting schedule, such as claiming or distributing vested tokens, are truncated or missing from the provided snippet. This prevents a full security assessment of the vesting mechanism.

Recommendation: Provide the complete source code for all relevant contracts, especially those implementing critical economic logic like vesting, to enable a comprehensive security review.

Is NEXO Safe? NEXO