Quantum Audit Logo
Launch App

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

Is Marlin POND Safe?

PONDEthereum
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
Technical5/10Governance2/10Upgrades1/10Checks passed4 of 7Findings2 High · 1 Medium · 1 Low · 2 Info6
SummaryAI Copilot

The audit of the Token contract (implementation logic for a proxy) identified several high-severity issues related to centralized access control for minting and potential proxy initialization vulnerabilities.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply, but capped at 0.0%/year
  • Proxy contract
  • Top-10 concentration > 30%
  • LP top3 unlocked holders = 80.8%
  • LP claimed locked but only 0.0% actually locked
  • 2 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply, but capped at 0.0%/year
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 30% (72.2% total → 33.6% effective; 7.8% in EOAs, 64.4% in contracts — moderate)
  • LP top3 unlocked holders = 80.8% (independent LP — depth risk, pool = 87% of DEX liquidity)
  • LP claimed locked but only 0.0% actually locked
  • 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 44 of 7 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockLocked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
64.4%Contracts7.8%Wallets27.8%Everyone else
64.4%Contracts7.8%27.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
72.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking64.4%
  • Walletsanonymous holders, free to sell7.8%
  • Everyone elsethe rest of the supply27.8%
Effective concentrationwhat the score reads33.6%
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$143.8K across 2 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$125.1KShare of depth87.0%
Top-1 Unlocked Holder43.7%
Top-3 Unlocked80.8%
Unlocked LP held by
0x2b3f…0daa0x5b03…08e90x3320…84900xe1a3…687f0xae38…64e90x257e…e35d0x5a27…24be

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

Security Findings

2 High1 Medium1 Low2 Info
High

Centralized Minting Control

The MinterRole contract implements a highly centralized access control mechanism for minting. The initial minter, set during initialization, has the sole ability to add or remove other minters. This creates a single point of failure, as a compromise or malicious action by this single entity could lead to uncontrolled token minting and significant economic damage through dilution. (7.3 Access Control, 7.4 Economic, 7.5 Governance)H-01

Issue

The MinterRole contract implements a highly centralized access control mechanism for minting. The initial minter, set during initialization, has the sole ability to add or remove other minters. This creates a single point of failure, as a compromise or malicious action by this single entity could lead to uncontrolled token minting and significant economic damage through dilution. (7.3 Access Control, 7.4 Economic, 7.5 Governance)

Fix

Implement a more decentralized or robust access control mechanism for the MinterRole. This could involve a multi-signature wallet (e.g., Gnosis Safe) for the minter role, a time-locked governance mechanism, or a DAO vote for adding/removing minters. This distributes control and reduces the risk associated with a single point of failure.

Status

Unresolved

High

Proxy Initialization Vulnerability

The initialize functions in ERC20Detailed, MinterRole, and ERC20Mintable are public and use the initializer modifier. If the proxy's initialize function does not correctly call all necessary initialize functions on the implementation, or if the implementation's initialize functions are called directly before proxy setup, it can lead to state corruption, re-initialization, or bypassing critical setup logic. The isConstructor() check helps prevent direct initialization on the implementation *after* deployment, but the proxy itself must correctly orchestrate initialization. (7.7 Upgrades, 7.3 Access Control)H-02

Issue

The initialize functions in ERC20Detailed, MinterRole, and ERC20Mintable are public and use the initializer modifier. If the proxy's initialize function does not correctly call all necessary initialize functions on the implementation, or if the implementation's initialize functions are called directly before proxy setup, it can lead to state corruption, re-initialization, or bypassing critical setup logic. The isConstructor() check helps prevent direct initialization on the implementation *after* deployment, but the proxy itself must correctly orchestrate initialization. (7.7 Upgrades, 7.3 Access Control)

Fix

Ensure that the proxy contract's initialize function is meticulously designed to call all required initialize functions on the implementation contract exactly once and in the correct order. Implement robust testing for the proxy deployment and initialization process. Consider adding an onlyProxy modifier to the initialize functions if the proxy address is known and immutable, or ensure the initializer modifier's logic is fully understood in the context of the proxy pattern.

Status

Unresolved

Medium

ERC20 Approval Race Condition

The standard ERC20 approve() function is susceptible to a known front-running attack. If a user approves an amount for a spender, and then attempts to approve a different amount, a malicious spender could front-run the second transaction by spending the original approved amount, and then again spending the newly approved amount, effectively spending double the intended amount. (7.2 Code Security)M-01

Issue

The standard ERC20 approve() function is susceptible to a known front-running attack. If a user approves an amount for a spender, and then attempts to approve a different amount, a malicious spender could front-run the second transaction by spending the original approved amount, and then again spending the newly approved amount, effectively spending double the intended amount. (7.2 Code Security)

Fix

Implement the 'approve(0)' pattern to mitigate this risk. Before changing an existing allowance, the owner should first set the allowance to zero with a transaction, wait for it to be mined, and then issue a second transaction to set the new allowance. Alternatively, use increaseAllowance and decreaseAllowance functions, which are present in the contract and inherently safer against this specific race condition.

Status

Unresolved

Low

Inconsistent Pragma Directives

The contract uses multiple pragma directives (>=0.4.24 <0.7.0 and ^0.5.0). While ^0.5.0 is compatible with 0.5.x versions, and the broader range covers it, it is best practice to use a single, specific pragma (e.g., pragma solidity 0.5.17; or pragma solidity ^0.5.0;) for clarity and to avoid unexpected compiler behavior with future Solidity versions. (7.2 Code Security)L-01

Issue

The contract uses multiple pragma directives (>=0.4.24 <0.7.0 and ^0.5.0). While ^0.5.0 is compatible with 0.5.x versions, and the broader range covers it, it is best practice to use a single, specific pragma (e.g., pragma solidity 0.5.17; or pragma solidity ^0.5.0;) for clarity and to avoid unexpected compiler behavior with future Solidity versions. (7.2 Code Security)

Fix

Consolidate all pragma solidity directives to a single, consistent version, preferably pragma solidity ^0.5.0; or the exact compiler version used for deployment, pragma solidity 0.5.17;.

Status

Unresolved

Info

Unused Internal Function (_burnFrom)

The internal function _burnFrom(address account, uint256 amount) is defined within the ERC20 contract but is never called by any other function in the provided code. This constitutes dead code, which can increase contract size and potentially lead to confusion during future audits or maintenance. (7.2 Code Security)I-01

Issue

The internal function _burnFrom(address account, uint256 amount) is defined within the ERC20 contract but is never called by any other function in the provided code. This constitutes dead code, which can increase contract size and potentially lead to confusion during future audits or maintenance. (7.2 Code Security)

Fix

Remove the _burnFrom function if it is not intended to be used, or integrate it into a public burnFrom function if that functionality is desired.

Status

Unresolved

Info

Unnecessary this; statement

The _msgData() function in the Context contract contains an unnecessary this; statement. This statement is a no-op and does not affect the contract's logic or state. (7.2 Code Security)I-02

Issue

The _msgData() function in the Context contract contains an unnecessary this; statement. This statement is a no-op and does not affect the contract's logic or state. (7.2 Code Security)

Fix

Remove the this; statement from the _msgData() function for cleaner and more concise code.

Status

Unresolved

Analysis

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

The audit of the Token contract (implementation logic for a proxy) identified several high-severity issues related to centralized access control for minting and potential proxy initialization vulnerabilities. Medium and low-severity findings include a standard ERC20 approval race condition and minor code quality issues. The contract utilizes OpenZeppelin's Initializable pattern and SafeMath, demonstrating good foundational practices, but critical operational and upgrade risks remain.

Technical5/10Medium risk

The contract leverages battle-tested OpenZeppelin libraries like SafeMath and standard ERC20 patterns, enhancing code security and reliability. The use of storage gaps (______gap) is a good practice for upgradeability (7.1 Architecture, 7.2 Code Security). However, a significant concern is the potential for proxy initialization vulnerabilities, where initialize functions could be called directly on the implementation or incorrectly by the proxy (7.7 Upgrades, 7.3 Access Control). Additionally, the standard ERC20 approve function is susceptible to front-running attacks (7.2 Code Security).

Governance2/10High risk

Role-based access for minting is implemented, separating concerns and allowing for controlled token supply increases (7.3 Access Control). However, the MinterRole is highly centralized, posing a single point of failure if the minter's key is compromised or misused (7.4 Economic, 7.5 Governance). The truncation of ERC20Capped means the token's supply cap, a critical economic parameter, is not fully auditable from the provided code, potentially leading to uncontrolled dilution if not properly configured or if the cap is excessively high (7.4 Economic).

Upgrades1/10High risk

The contract is designed for upgradeability using OpenZeppelin's Initializable pattern and includes storage gap variables (______gap), which are crucial for preventing storage collisions during upgrades (7.7 Upgrades). A critical vulnerability exists if the proxy's initialize function does not correctly call all necessary initialize functions on the implementation, or if the implementation's initialize functions are called directly before proxy setup. This could lead to state corruption or re-initialization, compromising the contract's integrity (7.7 Upgrades, 7.3 Access Control).

Final RecommendationWhat to do about this score

It is crucial to implement robust multi-signature or time-locked governance for the MinterRole to mitigate centralization risks.

A thorough review of the proxy's initialization logic is required to ensure all implementation initialize functions are correctly called only once and exclusively through the proxy. Consider implementing the approve(0) pattern to mitigate ERC20 approval race conditions. Finally, ensure the ERC20Capped functionality is fully implemented and configured with a reasonable and transparent cap to manage token supply and prevent unexpected dilution.

Contract & Record

1 audit on record
TypeTokenProxy
NetworkEthereum
Token age5y
Contract0x57b9…d26c
Deployer0xe661…ea19
Proxy Upgrade Controls
Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Marlin POND 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 31, 202663Medium

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

Frequently Asked Questions

What is the POND contract address?

The Marlin POND (POND) contract on Ethereum is 0x57b946008913b82e4df85f501cbaed910e58d26c. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Marlin POND a scam?

Quantum Audit's risk score for Marlin POND is 63/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: Mintable; Liquidity lock: Locked; Upgradeability: Upgradeable; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is POND liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $143.8K.

Who holds POND?

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

Related Audits

6 more on the recordAll audits
SPACE IDID · Ethereum63MediumUSDS StablecoinUSDS · Ethereum63MediumSushiTokenSUSHI · Ethereum63MediumEspressoESP · Ethereum64MediumSEIEthereum62MediumDolomiteDOLO · Ethereum62Medium

Would You Like a More Detailed Audit of Marlin POND?

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