Quantum Audit Logo

Is Dolphin Safe?

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

Dolphin POD
0xed66…df8f
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The OptimismMintableERC20 contract serves as a standard ERC20 token designed for cross-chain bridging, specifically for the Optimism/Base ecosystem. Its core functionality involves minting and burning tokens, which are strictly controlled by a designated 'BRIDGE' address. The contract is well-structured, utilizes OpenZeppelin standards, and employs immutable variables for critical parameters. The primary risk stems from its inherent dependency on the security and operational integrity of the external bridge contract.

1 High1 Low2 Informational
Volume 24h
$362.6K
Liquidity
$3.44M
Price
$0.3565
Token Age
5mo
Top 10 Holders
94.0%

Security Findings

1 High1 Low2 Info
High

Critical Dependency on External Bridge Security

H-01The `mint` and `burn` functions, which directly control the total supply of the OptimismMintableERC20 token, are exclusively callable by the `BRIDGE` address. This design makes the token's economic integrity entirely reliant on the security and operational robustness of the external bridge contract. A compromise of the bridge contract (e.g., through a vulnerability or private key compromise) would allow an attacker to arbitrarily mint or burn tokens, leading to severe financial loss for token holders and undermining the protocol's trust. This is an inherent architectural risk for bridged tokens (7.6 External, 7.3 Access Control, 7.4 Economic).
IssueThe `mint` and `burn` functions, which directly control the total supply of the OptimismMintableERC20 token, are exclusively callable by the `BRIDGE` address. This design makes the token's economic integrity entirely reliant on the security and operational robustness of the external bridge contract. A compromise of the bridge contract (e.g., through a vulnerability or private key compromise) would allow an attacker to arbitrarily mint or burn tokens, leading to severe financial loss for token holders and undermining the protocol's trust. This is an inherent architectural risk for bridged tokens (7.6 External, 7.3 Access Control, 7.4 Economic).
FixWhile this is an inherent design choice for a bridged token, it is crucial to ensure the highest level of security for the `BRIDGE` contract itself. Implement rigorous security audits, formal verification, multi-signature controls, and continuous monitoring for the bridge. Establish clear incident response plans for potential bridge compromises. Communicate this dependency transparently to users.
StatusUnresolved
Low

Immutable Bridge Address Limits Operational Flexibility

L-01The `BRIDGE` address is declared as `immutable` and set only during contract construction. While this prevents unauthorized modification and enhances security by fixing a critical parameter, it also means that if the underlying bridge contract needs to be upgraded, replaced, or if its address changes for any reason (e.g., due to a critical bug or new architecture), this OptimismMintableERC20 token contract would need to be redeployed. This could lead to complex migration processes for users and potential disruption (7.1 Architecture, 7.8 Operations).
IssueThe `BRIDGE` address is declared as `immutable` and set only during contract construction. While this prevents unauthorized modification and enhances security by fixing a critical parameter, it also means that if the underlying bridge contract needs to be upgraded, replaced, or if its address changes for any reason (e.g., due to a critical bug or new architecture), this OptimismMintableERC20 token contract would need to be redeployed. This could lead to complex migration processes for users and potential disruption (7.1 Architecture, 7.8 Operations).
FixAcknowledge this design trade-off. For future token designs, consider if a controlled, multi-signature-governed mechanism for updating the bridge address (e.g., via a proxy or an `Ownable` pattern for the bridge address itself) might be beneficial, weighing the added complexity against the operational flexibility. For the current contract, ensure clear communication and a well-defined migration strategy in case of a bridge address change.
StatusUnresolved
Info

Redundant Interface Functions

I-01The contract implements both `ILegacyMintableERC20` and `IOptimismMintableERC20` interfaces. This results in redundant functions like `l1Token()` and `remoteToken()` both returning `REMOTE_TOKEN`, and `l2Bridge()` and `bridge()` both returning `BRIDGE`. While not a vulnerability, this introduces slight redundancy in the contract's external interface and could potentially lead to confusion for integrators (7.1 Architecture, 7.2 Code Security).
IssueThe contract implements both `ILegacyMintableERC20` and `IOptimismMintableERC20` interfaces. This results in redundant functions like `l1Token()` and `remoteToken()` both returning `REMOTE_TOKEN`, and `l2Bridge()` and `bridge()` both returning `BRIDGE`. While not a vulnerability, this introduces slight redundancy in the contract's external interface and could potentially lead to confusion for integrators (7.1 Architecture, 7.2 Code Security).
FixConsider consolidating the interfaces if possible, or clearly documenting the purpose of each redundant function if they are intended for different integration paths (e.g., legacy vs. modern). If the legacy interface is no longer strictly required, it could be removed to streamline the contract.
StatusUnresolved
Info

Missing NatSpec Documentation

I-02Some functions and parameters within the contract, such as the constructor parameters and the `supportsInterface` function, lack comprehensive NatSpec documentation. While the code is relatively straightforward, adding detailed NatSpec comments improves readability, maintainability, and clarity for developers integrating with the contract or auditing it (7.2 Code Security).
IssueSome functions and parameters within the contract, such as the constructor parameters and the `supportsInterface` function, lack comprehensive NatSpec documentation. While the code is relatively straightforward, adding detailed NatSpec comments improves readability, maintainability, and clarity for developers integrating with the contract or auditing it (7.2 Code Security).
FixAdd complete NatSpec documentation for all public and external functions, including descriptions for parameters, return values, and events. This enhances code clarity and facilitates easier integration and understanding for external parties.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The technical implementation of the OptimismMintableERC20 contract is robust, leveraging OpenZeppelin's battle-tested ERC20 library (7.2 Code Security). Access control for critical `mint` and `burn` functions is correctly implemented via an `onlyBridge` modifier, ensuring only the designated bridge can manipulate token supply (7.3 Access Control). The contract uses immutable variables for `REMOTE_TOKEN`, `BRIDGE`, and `DECIMALS`, enhancing security by preventing unauthorized changes post-deployment (7.1 Architecture). Minor issues include redundant interface functions and some missing NatSpec documentation (7.2 Code Security).

GovernanceHigh1/10

The economic security of this token is critically dependent on the external `BRIDGE` contract (7.4 Economic). All supply manipulation (minting and burning) is exclusively controlled by this bridge, meaning any vulnerability or compromise in the bridge would directly impact the integrity and value of this token (7.6 External). The contract itself has no internal governance mechanisms (7.5 Governance), relying entirely on the governance and security of the broader Optimism/Base bridging infrastructure. The immutability of the `BRIDGE` address, while preventing unauthorized changes, also means that if the bridge needs to be upgraded or replaced, this token contract would require redeployment, potentially complicating operational continuity (7.8 Operations).

UpgradesHigh3/10

The OptimismMintableERC20 contract is not designed as an upgradeable proxy (7.7 Upgrades). Its implementation is fixed upon deployment, which eliminates risks associated with proxy patterns such as storage collisions or upgrade path vulnerabilities. However, this also means that any future changes or bug fixes to this specific token contract would necessitate a complete redeployment and potential migration of token holders.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

94.0% in top 10
1.5% in wallets92.5% in contracts
Effective Concentration38.5%

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

$3.67M across 8 pairs
Uniswap v4ETHanalysed$3.44M93.7%AerodromeUSDC$227.2K6.2%AerodromeREI$2.2K0.1%AerodromeWETH$8810.0%Uniswap v4USDC$4910.0%AerodromeAERO$750.0%
Show 2 more pairsShow less
Uniswap v3WETH$440.0%PancakeswapUSDC$430.0%

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 Holder69.6%
Top-3 Unlocked100.0%

Key Addresses

4 addresses
Deployer
0xc706…3e7f
Unlocked LP Held By
0x575e…fe980x58ab…66240xbd3b…b376

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

What Raised This Score

8 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (94.0% total → 38.5% effective; 1.5% in EOAs, 92.5% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 69.6% (independent LP — depth risk, pool = 94% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 94% of DEX liquidity)
  • 1 High 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

Related Audits

6 more on the record
Jito Staked SOL (JITOSOL)High Risk0xAgentEVE (EVE)High RiskWELLHigh RiskBittensor (TAO)High RiskVelvetHigh RiskLayerZero (ZRO)High Risk

Would You Like a More Detailed Audit of Dolphin?

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

Get Detailed Audit