Quantum Audit Logo
Launch App

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

Is Jerry The Turtle By Matt Furie Safe?

JYAIEthereum
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
SummaryAI Copilot

The JerryTheTurtleToken contract is an ERC-20 compliant token that leverages battle-tested OpenZeppelin libraries.

Read the full analysis
What raised the score
  • Top-10 concentration > 20%
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 45 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
18.2%Contracts14.8%Wallets67.0%Everyone else
18.2%Contracts14.8%67.0%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
33.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking18.2%
  • Walletsanonymous holders, free to sell14.8%
  • Everyone elsethe rest of the supply67.0%
Effective concentrationwhat the score reads22.1%
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$65.8K

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$65.8KShare of depth100.0%
LP Locked100.0% · Null Address, UNCX
Lock Expiry2281 (verified ≥ 1 year) · UNCX V2

Security Findings

1 Low2 Info
Low

Centralized Initial Token Distribution

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

Issue

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

Fix

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

Status

Unresolved

Info

Renounced Ownership in Constructor

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

Issue

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

Fix

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

Status

Unresolved

Info

Uncallable Administrative Functions

Due 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.I-02

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical10/10Low risk

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.

Governance10/10Low risk

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.

Upgrades10/10Low risk

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.

Final RecommendationWhat to do about this score

It is recommended to ensure the initial distribution strategy for the 1 billion tokens minted to the deployer is transparent and aligns with the project's decentralization goals.

While ownership is renounced, the initial concentration of tokens could impact market dynamics if not managed carefully. Users should be fully aware that the contract is immutable and no administrative functions can be invoked post-deployment.

Contract & Record

1 audit on record
TypeJerryTheTurtleToken
NetworkEthereum
Token age1y
Contract0x4e96…af8c
Deployer0xdc87…d262
Badge for your website
Jerry The Turtle By Matt Furie 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 4, 20260Low

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

Frequently Asked Questions

What is the JYAI contract address?

The Jerry The Turtle By Matt Furie (JYAI) contract on Ethereum is 0x4e9623b7e5b6438542458f5ee828d65c24d3af8c. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Jerry The Turtle By Matt Furie a scam?

Quantum Audit's risk score for Jerry The Turtle By Matt Furie is 0/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is JYAI liquidity locked?

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

Who holds JYAI?

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

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