Quantum Audit Logo

Is NEXO Safe?

On-chain security analysis — is it a scam or legit?

Is this your token? Publish your own audit on this page →

NEXO NEXO
0xb621…5206
Ethereum
Not verifiedThis record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked 18d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

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.

1 High2 Medium2 Low1 Informational
Volume 24h
$5.7K
Liquidity
$1.38M
Price
$0.844
Token Age
5y
Top 10 Holders
93.6%

Security Findings

1 High2 Med2 Low1 Info
High

Inconsistent SafeMath Usage Leading to Potential Underflow

H-01The `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.
IssueThe `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.
FixEnsure 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);`.
StatusUnresolved
Medium

Outdated Solidity Compiler Version

M-01The 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.
IssueThe 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.
FixUpgrade 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.
StatusUnresolved
Medium

Use of `now` for `creationTime`

M-02The `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.
IssueThe `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.
FixEvaluate 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.
StatusUnresolved
Low

Missing Division by Zero Check in SafeMath.div

L-01The `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.
IssueThe `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.
FixAdd an explicit check for division by zero at the beginning of the `div` function: `require(b != 0, 'SafeMath: division by zero');`.
StatusUnresolved
Low

Centralized Control by Owner

L-02The `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.
IssueThe `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.
FixConsider 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.
StatusUnresolved
Info

Truncated Vesting Logic

I-01The 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.
IssueThe 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.
FixProvide the complete source code for all relevant contracts, especially those implementing critical economic logic like vesting, to enable a comprehensive security review.
StatusUnresolved

Category Ratings

TechnicalMedium6/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 protection. The contract also uses an outdated Solidity compiler (0.4.23), which may expose it to known compiler bugs and lacks modern security features. The use of `now` for `creationTime` (7.8 Operations) is also noted.

GovernanceHigh1/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 ability to recover any ERC20 tokens sent to the contract via `transferERC20Token`. While the `Owned` pattern includes a two-step ownership transfer, the owner remains a single point of trust and potential failure.

UpgradesMedium6/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 a full redeployment and migration.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

93.6% in top 10
93.6% in wallets0.0% in contracts
Effective Concentration93.6%

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Liquidity Depth

$1.40M across 4 pairs
Uniswap v3WETHanalysed$1.38M98.3%Uniswap v4ETH$11.5K0.8%Uniswap v2WETH$7.3K0.5%Uniswap v4USDC$4.4K0.3%

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

Top-1 Unlocked Holder34.5%
Top-3 Unlocked83.2%

Key Addresses

10 addresses
Deployer
0xa218…10d8
Unlocked LP Held By
0xf3f1…b6620xd476…c85d0x6502…f1660x8b40…7aa80xe7ab…ea6c0x877c…5c110xa8c0…94fe0x5d47…9c8b0x9eef…f7c8

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

7 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Top-10 concentration > 70% (93.6% total → 93.6% effective; 93.6% in EOAs, 0.0% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top3 unlocked holders = 83.2% (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

Related Audits

6 more on the record
Cronos (CRO)Critical RiskEpic Chain (EPIC)Critical RiskAZTECCritical RiskCoW Protocol Token (COW)Critical RiskMetronome Synth ETH (MSETH)Critical RiskMetronome Synth USD (MSUSD)Critical Risk

Would You Like a More Detailed Audit of NEXO?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit