Quantum Audit Logo
Launch App

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

Is Turtle Safe?

TURTLEEthereum
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
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical5/10Governance1/10Upgrades1/10Checks passed1 of 5Findings1 Critical · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The Turtle token contract, implemented as an upgradeable ERC-20, demonstrates good adherence to OpenZeppelin standards for core functionalities and upgradeability.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 Critical finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 70% (98.1% total → 76.8% effective; 62.7% in EOAs, 35.4% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 1 Critical 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 41 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
35.4%Contracts62.7%Wallets
35.4%Contracts62.7%Wallets
ContractsWalletsEveryone elseBubble area = share of supply
98.1%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking35.4%
  • Walletsanonymous holders, free to sell62.7%
  • Everyone elsethe rest of the supply1.9%
Effective concentrationwhat the score reads76.8%
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.43M

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.43MShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x64ad…4276

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

Security Findings

1 Critical1 Medium1 Low1 Info
Critical

Centralized Control over Token Supply and Transfers

The mint, burn, and adminTransfer functions are protected by the restricted modifier, which grants the initialAuthority (set during initialization via __AccessManaged_init) the power to mint an arbitrary amount of tokens, burn tokens from msg.sender, and transfer tokens from any user's balance to any other address without their consent. This represents a severe centralization risk (7.3 Access Control, 7.4 Economic), allowing for arbitrary token supply manipulation and potential asset confiscation.C-01

Issue

The mint, burn, and adminTransfer functions are protected by the restricted modifier, which grants the initialAuthority (set during initialization via __AccessManaged_init) the power to mint an arbitrary amount of tokens, burn tokens from msg.sender, and transfer tokens from any user's balance to any other address without their consent. This represents a severe centralization risk (7.3 Access Control, 7.4 Economic), allowing for arbitrary token supply manipulation and potential asset confiscation.

Fix

Eliminate or significantly restrict the adminTransfer function. For mint and burn, consider implementing a timelock, multi-signature, or governance-controlled mechanism. Ensure the initialAuthority is a robust, multi-signature wallet with a high threshold and strong operational security (7.8 Operations).

Status

Unresolved

Medium

Dual Access Control Mechanisms

The contract inherits both OwnableUpgradeable and AccessManagedUpgradeable. While AccessManaged is used for critical functions like mint, burn, adminTransfer, and _authorizeUpgrade, Ownable is initialized but its owner has no specific privileges defined within this contract. This dual inheritance can lead to confusion regarding which role controls what, potentially causing operational errors or misconfigurations (7.1 Architecture, 7.3 Access Control).M-01

Issue

The contract inherits both OwnableUpgradeable and AccessManagedUpgradeable. While AccessManaged is used for critical functions like mint, burn, adminTransfer, and _authorizeUpgrade, Ownable is initialized but its owner has no specific privileges defined within this contract. This dual inheritance can lead to confusion regarding which role controls what, potentially causing operational errors or misconfigurations (7.1 Architecture, 7.3 Access Control).

Fix

Consolidate access control to a single, clear mechanism (e.g., solely AccessManaged or a custom role-based access control). If Ownable is not used, remove it to improve clarity and reduce contract size.

Status

Unresolved

Low

Initial Mint Recipient Discrepancy

The initialize function mints initialMint tokens to msg.sender. This msg.sender is the address that calls the initialize function on the proxy, which may not necessarily be the initialAuthority address that is set for AccessManaged. While not a direct vulnerability, this could lead to an unintended distribution of initial tokens if the deployer/initializer is different from the intended primary authority or treasury (7.1 Architecture, 7.8 Operations).L-01

Issue

The initialize function mints initialMint tokens to msg.sender. This msg.sender is the address that calls the initialize function on the proxy, which may not necessarily be the initialAuthority address that is set for AccessManaged. While not a direct vulnerability, this could lead to an unintended distribution of initial tokens if the deployer/initializer is different from the intended primary authority or treasury (7.1 Architecture, 7.8 Operations).

Fix

Clarify in documentation who is expected to receive the initial mint. If the intention is for the initialAuthority or a specific treasury to receive these tokens, modify the _mint call to target that address explicitly.

Status

Unresolved

Info

Strong Reliance on OpenZeppelin Libraries

The contract heavily relies on battle-tested OpenZeppelin Upgradeable contracts (ERC20Upgradeable, AccessManagedUpgradeable, UUPSUpgradeable, etc.). This significantly reduces the risk of common vulnerabilities like reentrancy, integer overflows, and standard ERC-20 compliance issues (7.2 Code Security).I-01

Issue

The contract heavily relies on battle-tested OpenZeppelin Upgradeable contracts (ERC20Upgradeable, AccessManagedUpgradeable, UUPSUpgradeable, etc.). This significantly reduces the risk of common vulnerabilities like reentrancy, integer overflows, and standard ERC-20 compliance issues (7.2 Code Security).

Fix

Continue to monitor OpenZeppelin's security advisories and ensure dependencies are kept up-to-date, especially during upgrades.

Status

Resolved

Analysis

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

The Turtle token contract, implemented as an upgradeable ERC-20, demonstrates good adherence to OpenZeppelin standards for core functionalities and upgradeability. However, the contract design introduces a critical centralization risk due to the extensive powers granted to the AccessManaged authority, including arbitrary minting, burning, and transferring of user tokens. Additionally, the presence of dual access control mechanisms (Ownable and AccessManaged) creates unnecessary complexity.

Technical5/10Medium risk

The contract leverages battle-tested OpenZeppelin libraries for ERC-20, upgradeability (UUPS), and access control, contributing to robust code security (7.2). The permit function is correctly implemented with SignatureChecker and nonce management. A minor architectural concern (7.1) is the use of both OwnableUpgradeable and AccessManagedUpgradeable, which could lead to confusion.

Governance1/10High risk

The contract presents a critical economic risk (7.4) due to the initialAuthority's ability to mint unlimited tokens, burn tokens, and adminTransfer any user's tokens. This centralized control over token supply and user funds (7.3 Access Control) makes the system highly susceptible to manipulation or malicious actions if the authority's private keys are compromised or misused. The security of the initialAuthority address is paramount (7.8 Operations).

Upgrades1/10High risk

The contract correctly implements the UUPS upgrade pattern (7.7), inheriting UUPSUpgradeable and overriding _authorizeUpgrade. The upgrade authorization is appropriately restricted to the AccessManaged authority, ensuring that only the designated entity can initiate contract upgrades, which is a secure design.

Final RecommendationWhat to do about this score

It is strongly recommended to re-evaluate the necessity and scope of the mint, burn, and adminTransfer functions.

If these functionalities are critical, implement robust governance mechanisms such as a multi-signature wallet with a high threshold, a timelock, or a decentralized autonomous organization (DAO) to control these powerful operations. Additionally, simplify the access control architecture by consolidating to a single, clear mechanism, removing OwnableUpgradeable if it serves no functional purpose.

Contract & Record

1 audit on record
TypeTurtleProxy
NetworkEthereum
Token age6mo
Contract0x66fd…3afd
Deployer0x11e4…ee44
Proxy Upgrade Controls
Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Turtle 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 13, 202678High

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

Frequently Asked Questions

What is the TURTLE contract address?

The Turtle contract on Ethereum is 0x66fd8de541c0594b4dccdfc13bf3a390e50d3afd. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Turtle a scam?

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

Is TURTLE liquidity locked?

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

Who holds TURTLE?

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

Related Audits

6 more on the recordAll audits
Syrup TokenSYRUP · Ethereum78HighMinpentaiPENTA · Ethereum78HighClausEthereum78HighPortalEthereum77HighNillionNIL · Ethereum77HighSynapseSYN · Ethereum76High

Would You Like a More Detailed Audit of Turtle?

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