Quantum Audit Logo

Is Turtle Safe?

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

Is this your token? Publish your own audit on this page →

Turtle TURTLE
0x66fd…3afd
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

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.

1 Critical1 Medium1 Low1 Informational
Volume 24h
$51.4K
Liquidity
$1.43M
Price
$0.0417
Token Age
6mo
Top 10 Holders
98.1%

Security Findings

1 Crit1 Med1 Low1 Info
Critical

Centralized Control over Token Supply and Transfers

C-01The `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.
IssueThe `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.
FixEliminate 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).
StatusUnresolved
Medium

Dual Access Control Mechanisms

M-01The 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).
IssueThe 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).
FixConsolidate 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.
StatusUnresolved
Low

Initial Mint Recipient Discrepancy

L-01The `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).
IssueThe `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).
FixClarify 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.
StatusUnresolved
Info

Strong Reliance on OpenZeppelin Libraries

I-01The 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).
IssueThe 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).
FixContinue to monitor OpenZeppelin's security advisories and ensure dependencies are kept up-to-date, especially during upgrades.
StatusResolved

Category Ratings

TechnicalMedium5/10

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.

GovernanceHigh1/10

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

UpgradesHigh1/10

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.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

98.1% in top 10
62.7% in wallets35.4% in contracts
Effective Concentration76.8%

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.43M

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

Key Addresses

2 addresses
Deployer
0x11e4…ee44
Unlocked LP Held By
0x64ad…4276

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

What Raised This Score

10 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

Related Audits

6 more on the record
Syrup Token (SYRUP)Critical RiskPortalCritical RiskNillion (NIL)Critical RiskSynapse (SYN)Critical RiskRallyCritical RiskAutonolas (OLAS)Critical Risk

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