Quantum Audit Logo
Launch App

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

Is Dolphin Safe?

PODBase
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
Technical7/10Governance1/10Upgrades3/10Checks passed2 of 5Findings1 High · 1 Low · 2 Info4
SummaryAI Copilot

The OptimismMintableERC20 contract serves as a standard ERC20 token designed for cross-chain bridging, specifically for the Optimism/Base ecosystem.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 69.6%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

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

Holders

as of audit · Sep 4, 2026
92.5%Contracts6.0%
92.5%Contracts6.0%
ContractsWalletsEveryone elseBubble area = share of supply
94.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking92.5%
  • Walletsanonymous holders, free to sell1.5%
  • Everyone elsethe rest of the supply6.0%
Effective concentrationwhat the score reads38.5%
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$3.67M across 8 pairs
Show 2 more 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$3.44MShare of depth93.7%
Top-1 Unlocked Holder69.6%
Top-3 Unlocked100.0%
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.

Security Findings

1 High1 Low2 Info
High

Critical Dependency on External Bridge Security

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

Issue

The 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).

Fix

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

Status

Unresolved

Low

Immutable Bridge Address Limits Operational Flexibility

The 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).L-01

Issue

The 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).

Fix

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

Status

Unresolved

Info

Redundant Interface Functions

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

Issue

The 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).

Fix

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

Status

Unresolved

Info

Missing NatSpec Documentation

Some 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).I-02

Issue

Some 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).

Fix

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

Status

Unresolved

Analysis

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

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.

Technical7/10Low risk

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

Governance1/10High risk

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

Upgrades3/10High risk

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.

Final RecommendationWhat to do about this score

Prioritize the security of the external bridge contract, as it is the single point of control for this token's supply.

Conduct thorough audits and continuous monitoring of the bridge's codebase and operational procedures. For future iterations, consider adding comprehensive NatSpec documentation to all public and external functions for improved clarity and developer experience. Evaluate the long-term implications of the immutable bridge address, especially concerning potential future bridge upgrades or replacements, and plan for potential token migration strategies if necessary.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age5mo
Contract0xed66…df8f
Deployer0xc706…3e7f
Badge for your website
Dolphin 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. Aug 11, 202662Medium

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

Frequently Asked Questions

What is the POD contract address?

The Dolphin (POD) contract on Base is 0xed664536023d8e4b1640c394777d34abaff1df8f. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Dolphin a scam?

Quantum Audit's risk score for Dolphin is 62/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is POD liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $3.67M.

Who holds POD?

As of Sep 4, 2026, the 10 largest holders own 94.0% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
Jito Staked SOLJITOSOL · Base62Medium0xAgentEVEEVE · Base62MediumWELLBase62MediumBittensorTAO · Base62MediumPalantir Technologies Inc.PLTRC · Base62MediumVelvetBase63Medium

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 Is this your token? Publish your own audit on this page