Quantum Audit Logo

Is Jerry The Turtle By Matt Furie Safe?

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

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

Jerry The Turtle By Matt Furie JYAI
0x4e96…af8c
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The JerryTheTurtleToken contract is an ERC-20 compliant token that leverages battle-tested OpenZeppelin libraries. A key design decision is the immediate renunciation of ownership in the constructor, which significantly enhances decentralization and immutability post-deployment. This also renders several administrative functions uncallable, ensuring no single entity can alter token parameters after launch. The initial token supply is minted entirely to the deployer.

1 Low2 Informational
Volume 24h
$1.7K
Liquidity
$65.8K
Price
$0.000002847
Token Age
1y
Top 10 Holders
33.0%

Security Findings

1 Low2 Info
Low

Centralized Initial Token Distribution

L-01The entire initial supply of 1,000,000,000 tokens is minted to the contract deployer's address in the constructor. While ownership is subsequently renounced, this initial centralized distribution means that the deployer holds 100% of the token supply at launch. This concentration could lead to significant market impact or potential for manipulation if not managed transparently and responsibly post-deployment (7.4 Economic).
IssueThe entire initial supply of 1,000,000,000 tokens is minted to the contract deployer's address in the constructor. While ownership is subsequently renounced, this initial centralized distribution means that the deployer holds 100% of the token supply at launch. This concentration could lead to significant market impact or potential for manipulation if not managed transparently and responsibly post-deployment (7.4 Economic).
FixImplement a clear and transparent plan for the distribution of the initial token supply. This could involve locking a portion of tokens, distributing them via a fair launch mechanism, or vesting schedules to mitigate risks associated with centralized control of a large supply. Communicate this distribution strategy to the community.
StatusUnresolved
Info

Renounced Ownership in Constructor

I-01The contract's `Ownable` ownership is immediately renounced in the constructor via `_transferOwnership(address(0));`. This design choice ensures that no single address retains administrative control over the contract after deployment. While this enhances decentralization and immutability, it also means that any functions protected by `onlyOwner` will become permanently uncallable.
IssueThe contract's `Ownable` ownership is immediately renounced in the constructor via `_transferOwnership(address(0));`. This design choice ensures that no single address retains administrative control over the contract after deployment. While this enhances decentralization and immutability, it also means that any functions protected by `onlyOwner` will become permanently uncallable.
FixThis is a deliberate design choice that promotes decentralization. Ensure that all necessary initializations are completed before deployment, as no owner-specific actions can be taken afterward. Communicate this immutability clearly to the community.
StatusUnresolved
Info

Uncallable Administrative Functions

I-02Due to the immediate renunciation of ownership in the constructor (I-01), several administrative functions such as `_setApprove`, `_setBalance`, and `_setTotalSupply` become permanently uncallable. These functions are intended to be owner-restricted but cannot be invoked as there is no owner. This effectively renders these code paths dead.
IssueDue to the immediate renunciation of ownership in the constructor (I-01), several administrative functions such as `_setApprove`, `_setBalance`, and `_setTotalSupply` become permanently uncallable. These functions are intended to be owner-restricted but cannot be invoked as there is no owner. This effectively renders these code paths dead.
FixWhile this is a direct consequence of the renounced ownership and reinforces immutability, consider removing these functions if they are not intended to be used. This would reduce contract size and improve clarity by removing unused code. Alternatively, if any administrative control was desired, ownership should not be renounced immediately.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The contract demonstrates strong technical security by inheriting from well-audited OpenZeppelin ERC20 and Ownable contracts (7.2 Code Security). Solidity version 0.8.0+ mitigates integer overflow/underflow risks by default. Custom overrides for `_approve` and `_transfer` include zero-address checks, enhancing robustness. However, due to the renounced ownership, several administrative functions like `_setBalance` are effectively uncallable (7.3 Access Control), which, while intended for immutability, means their code is dead.

GovernanceLow10/10

The contract's economic and governance model is highly decentralized due to the immediate renunciation of ownership in the constructor (7.5 Governance). This means no single entity can control or modify the token's parameters post-deployment, ensuring immutability of supply and administrative functions. The initial supply of 1 billion tokens is minted entirely to the deployer (7.4 Economic), which represents a centralized initial distribution point, though subsequent control is decentralized.

UpgradesLow10/10

The JerryTheTurtleToken contract is not designed with any upgradeability mechanisms (7.7 Upgrades). It is a standard, non-proxy implementation, meaning its logic is immutable once deployed. This eliminates upgrade-related risks such as proxy misconfigurations or malicious upgrade paths, but also means no future bug fixes or feature enhancements are possible without a new deployment.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

33.0% in top 10
14.8% in wallets18.2% in contracts
Effective Concentration22.1%

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

$65.8K

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

LP Locked100.0% · Null Address, UNCX
Lock Expiry2281 (verified ≥ 1 year) · UNCX V2

Key Addresses

1 addresses
Deployer
0xdc87…d262

What Raised This Score

2 factors
  • Top-10 concentration > 20% (33.0% total → 22.1% effective; 14.8% in EOAs, 18.2% in contracts — mild)
  • 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
AsteroidLow RiskAmerica Pac (PAC)Low RiskNon-Playable Coin (NPC)Low RiskYee Token (YEE)Low RiskPikachuLow RiskpepeCoinLow Risk

Would You Like a More Detailed Audit of Jerry The Turtle By Matt Furie?

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

Get Detailed Audit