Is Ocean Token (OCEAN) Safe? Smart Contract Security Analysis

Security Findings

2 High1 Med1 Low1 Info

High

Centralized Control of Minter and Pauser Roles

H-01The `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.

IssueThe `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.

FixImplement 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.

StatusUnresolved

High

Risk of Losing Administrative Control

H-02The `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.

IssueThe `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.

FixEstablish 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.

StatusUnresolved

Medium

Outdated Solidity Compiler Version

M-01The 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.

IssueThe 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.

FixConsider 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.

StatusUnresolved

Low

Standard ERC20 Approval Race Condition

L-01While 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.

IssueWhile 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.

FixEducate 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.

StatusUnresolved

Info

Event Emission for Mint/Burn from `address(0)`

I-01The `_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.

IssueThe `_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.

FixNo 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.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

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.

GovernanceHigh1/10

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.

UpgradesLow8/10

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.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Holder Composition

90.9% in top 10

88.2% in wallets2.7% in contracts

Effective Concentration89.2%

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.28M across 3 pairs

Uniswap v2WETHanalysed$1.25M SushiswapWETH$21.6K Uniswap v4ETH$7.4K

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 Holder83.1%

Top-3 Unlocked98.0%

Key Addresses

11 addresses

Deployer

0xe80e…b3a0

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.

What Raised This Score

8 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

Final Recommendation

AI Copilot

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.…

Read the verdictHide

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

TypeOceanToken

Audit History

1 audit on record

Aug 2063Sep 460

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

Is Ocean Token Safe?

Security Findings

Centralized Control of Minter and Pauser Roles

Risk of Losing Administrative Control

Outdated Solidity Compiler Version

Standard ERC20 Approval Race Condition

Event Emission for Mint/Burn from `address(0)`

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Ocean Token?