Quantum Audit Logo
Launch App

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

Is Ocean Token Safe?

OCEANEthereum
Not verified This 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 Sep 4, 2026 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance1/10Upgrades8/10Checks passed3 of 5Findings2 High · 1 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The audit of the OceanToken contract, an ERC20 token with minting, capping, and pausing functionalities, identified several high-level risks primarily related to centralized access control and the potential for administrative single points of failure.

Read the full analysis
What raised the score
  • Mintable supply, but capped at 0.0%/year
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 83.1%
  • LP top3 unlocked holders = 98.0%
  • 2 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Mintable supply, but capped at 0.0%/year
  • Top-10 concentration > 70% (90.9% total → 89.2% effective; 88.2% in EOAs, 2.7% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 83.1% (independent LP — depth risk, pool = 98% of DEX liquidity)
  • LP top3 unlocked holders = 98.0% (independent LP — depth risk, pool = 98% of DEX liquidity)
  • 2 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 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 Checklist

as of audit · Sep 43 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
2.7%88.2%Wallets9.1%Everyone else
88.2%Wallets9.1%
ContractsWalletsEveryone elseBubble area = share of supply
90.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking2.7%
  • Walletsanonymous holders, free to sell88.2%
  • Everyone elsethe rest of the supply9.1%
Effective concentrationwhat the score reads89.2%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$1.28M across 3 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$1.25MShare of depth97.7%
Top-1 Unlocked Holder83.1%
Top-3 Unlocked98.0%
Unlocked LP held by
0xfb67…3af10x2a63…1f440x147c…57720x887a…e6270x334f…3a2b0xdc59…e9810x0562…bc420x806c…de0f0xd13a…6aa90x7023…95fd

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

Security Findings

2 High1 Medium1 Low1 Info
High

Centralized Control of Minter and Pauser Roles

The MinterRole and PauserRole contracts implement highly centralized access control. The addMinter and addPauser functions can only be called by existing minters and pausers, respectively. The initial deployer automatically becomes the sole minter and pauser. This concentration of power creates a single point of failure, where a compromise of a single private key could lead to unauthorized minting, pausing of all token transfers, or other malicious actions, severely impacting the token's integrity and value.H-01

Issue

The MinterRole and PauserRole contracts implement highly centralized access control. The addMinter and addPauser functions can only be called by existing minters and pausers, respectively. The initial deployer automatically becomes the sole minter and pauser. This concentration of power creates a single point of failure, where a compromise of a single private key could lead to unauthorized minting, pausing of all token transfers, or other malicious actions, severely impacting the token's integrity and value.

Fix

Implement a multi-signature wallet (e.g., Gnosis Safe) to control the Minter and Pauser roles. This would require multiple trusted parties to approve critical administrative actions, significantly reducing the risk associated with a single compromised key. Alternatively, explore a more decentralized governance model if feasible for the project's roadmap.

Status

Unresolved

High

Risk of Losing Administrative Control

The MinterRole and PauserRole contracts allow an existing role bearer to renounceMinter() or renouncePauser(). If the initial deployer, who is the sole minter and pauser by default, renounces these roles without first assigning them to other trusted addresses (or a multi-signature wallet), the ability to mint new tokens or pause/unpause the contract could be permanently lost. This would render the token unmanageable for these critical functions.H-02

Issue

The MinterRole and PauserRole contracts allow an existing role bearer to renounceMinter() or renouncePauser(). If the initial deployer, who is the sole minter and pauser by default, renounces these roles without first assigning them to other trusted addresses (or a multi-signature wallet), the ability to mint new tokens or pause/unpause the contract could be permanently lost. This would render the token unmanageable for these critical functions.

Fix

Establish clear operational procedures for role management. Before any role bearer renounces their privileges, ensure that new, trusted addresses (preferably a multi-signature wallet) have been successfully assigned the respective roles. Consider adding a mechanism that prevents renouncing a role if it would leave the contract without any active minters or pausers, or at least requires a minimum number of active role holders.

Status

Unresolved

Medium

Outdated Solidity Compiler Version

The contract is compiled with Solidity version 0.5.3. While SafeMath is used to mitigate integer overflow/underflow, newer compiler versions (e.g., 0.8.x and above) include built-in overflow/underflow checks by default, along with numerous other security enhancements, bug fixes, and gas optimizations. Using an older compiler version may expose the contract to known vulnerabilities or inefficiencies that have been addressed in later versions.M-01

Issue

The contract is compiled with Solidity version 0.5.3. While SafeMath is used to mitigate integer overflow/underflow, newer compiler versions (e.g., 0.8.x and above) include built-in overflow/underflow checks by default, along with numerous other security enhancements, bug fixes, and gas optimizations. Using an older compiler version may expose the contract to known vulnerabilities or inefficiencies that have been addressed in later versions.

Fix

Consider upgrading the Solidity compiler version to 0.8.x or higher. This would allow for the removal of SafeMath (as checks are built-in) and leverage the latest security features and best practices. A thorough re-audit would be required after such an upgrade to ensure compatibility and identify any new issues introduced by syntax changes or new compiler behaviors.

Status

Unresolved

Low

Standard ERC20 Approval Race Condition

While the contract provides increaseAllowance and decreaseAllowance functions to mitigate the 'approve race condition', users who directly interact with the approve function are still susceptible to this known ERC20 vulnerability. If a user calls approve(spender, newAmount) while the spender is simultaneously executing transferFrom based on an old allowance, the spender might be able to spend more than newAmount or oldAmount depending on transaction ordering.L-01

Issue

While the contract provides increaseAllowance and decreaseAllowance functions to mitigate the 'approve race condition', users who directly interact with the approve function are still susceptible to this known ERC20 vulnerability. If a user calls approve(spender, newAmount) while the spender is simultaneously executing transferFrom based on an old allowance, the spender might be able to spend more than newAmount or oldAmount depending on transaction ordering.

Fix

Educate users and front-end interfaces to exclusively use increaseAllowance and decreaseAllowance instead of directly calling approve when modifying an existing allowance. While the contract provides the safer functions, off-chain guidance is crucial for user protection.

Status

Unresolved

Info

Event Emission for Mint/Burn from address(0)

The _mint and _burn internal functions emit Transfer events where the from or to address is address(0). Specifically, _mint emits Transfer(address(0), account, value) and _burn emits Transfer(account, address(0), value). This is a common and widely accepted convention in ERC20 tokens to signify token creation or destruction, but it's important for off-chain indexing services to correctly interpret these events.I-01

Issue

The _mint and _burn internal functions emit Transfer events where the from or to address is address(0). Specifically, _mint emits Transfer(address(0), account, value) and _burn emits Transfer(account, address(0), value). This is a common and widely accepted convention in ERC20 tokens to signify token creation or destruction, but it's important for off-chain indexing services to correctly interpret these events.

Fix

No direct code change is required as this is standard practice. Ensure that any off-chain services, such as block explorers or analytics platforms, are aware of and correctly interpret address(0) in Transfer events to represent minting and burning operations.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The audit of the OceanToken contract, an ERC20 token with minting, capping, and pausing functionalities, identified several high-level risks primarily related to centralized access control and the potential for administrative single points of failure. While the contract utilizes SafeMath for arithmetic safety and follows a modular design, the reliance on an older Solidity compiler version and the inherent power of the Minter and Pauser roles introduce significant security considerations. Recommendations focus on strengthening access control, upgrading compiler versions, and implementing robust operational procedures.

Technical6/10Medium risk

The contract demonstrates good architectural practices (7.1) by using a modular design and inheriting from well-established OpenZeppelin patterns. The inclusion of SafeMath (7.2) effectively mitigates integer overflow/underflow vulnerabilities. However, the reliance on Solidity 0.5.3 is a technical concern, as newer versions offer enhanced security features and gas optimizations. Access control (7.3) for Minter and Pauser roles is highly centralized, posing a significant single point of failure risk.

Governance1/10High risk

The economic model (7.4) includes a capped supply and minting functionality, which provides a clear limit but also introduces inflation risk if minters are compromised. The Pausable mechanism (7.4) allows for halting all token transfers, which is a powerful control. Governance (7.5) is highly centralized, with the initial deployer holding both Minter and Pauser roles. This creates a significant operational risk (7.8) where a single compromised or mismanaged key could lead to severe economic consequences, such as uncontrolled minting or permanent pausing of the token.

Upgrades8/10Low risk

The contract is not designed with an upgrade mechanism (7.7), meaning its logic cannot be modified post-deployment. This eliminates upgrade-related risks but also removes flexibility for future enhancements or bug fixes. Any changes would require a new deployment and migration.

Final RecommendationWhat to do about this score

To enhance the security posture of the OceanToken contract, it is strongly recommended to implement a multi-signature wallet for managing the Minter and Pauser roles, thereby decentralizing critical administrative functions and mitigating single points of failure.

Consider upgrading the Solidity compiler to a more recent version (e.g., 0.8.x) to benefit from built-in safety checks and modern best practices. Additionally, establish clear operational procedures for role management, including a process for adding and removing administrators, to prevent the irreversible loss of control over key contract functionalities.

Contract & Record

1 audit on record
TypeOceanToken
NetworkEthereum
Token age5y
Contract0x967d…9f48
Deployer0xe80e…b3a0
Badge for your website
Ocean Token security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202660Medium
  2. Aug 20, 202663Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Related Audits

6 more on the recordAll audits
DeXeEthereum60MediumRadicleRAD · Ethereum60MediumMantleMNT · Ethereum60MediumShuffleSHFL · Ethereum60MediumTajirTJR · Ethereum60MediumToken Prometeus NetworkPROM · Ethereum59Medium

Would You Like a More Detailed Audit of Ocean Token?

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

Get Detailed Audit Is this your token? Publish your own audit on this page