Quantum Audit Logo

Is iStonks a Scam?

Early-stage security check — honeypot & rug-pull analysis

iStonks ISTONKS
0xcb2b…e267
Base
Not verifiedThis 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.
Last checked 9d ago 1 audit on record New Launch · 1d old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The StonkToken contract is an ERC20 token implementation inheriting from OpenZeppelin's secure ERC20 standard. Key features include an immutable 'launcher' address receiving the total supply and a 'tokenURI' function that queries an external contract for metadata. The primary risk identified is the high centralization of the token supply to the 'launcher' address, which holds all initial tokens. Additionally, the 'tokenURI' function introduces an external dependency, and the 'creator' address is stored but unused.

1 Critical1 Medium1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (1d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$254.0K
Liquidity
$73.1K
Price
$0.0003686
Token Age
1d
Top 10 Holders
30.9%

Security Findings

1 Crit1 Med1 Low1 Info
Critical

Centralized Token Supply

C-01The `StonkToken` contract mints its entire `totalSupply` to a single `launcher` address during construction. This grants the `launcher` address complete control over the token's initial distribution, liquidity, and potential market manipulation. This high degree of centralization poses a significant economic and access control risk (7.4 Economic, 7.3 Access Control).
IssueThe `StonkToken` contract mints its entire `totalSupply` to a single `launcher` address during construction. This grants the `launcher` address complete control over the token's initial distribution, liquidity, and potential market manipulation. This high degree of centralization poses a significant economic and access control risk (7.4 Economic, 7.3 Access Control).
FixImplement a more decentralized and transparent token distribution mechanism. If the `launcher` is an operational entity, consider securing the address with a multi-signature wallet. Clearly communicate the `launcher`'s role and the planned distribution strategy to the community to manage expectations and build trust.
StatusUnresolved
Medium

External Call Dependency in `tokenURI`

M-01The `tokenURI()` function makes an external call to the `launcher` contract to retrieve `baseTokenURI()`. While a `try/catch` block handles reverts, a compromised or malicious `launcher` contract could return unexpected or misleading metadata, or cause excessive gas consumption, potentially impacting dApps or interfaces that rely on this function for token information (7.2 Code Security, 7.6 External).
IssueThe `tokenURI()` function makes an external call to the `launcher` contract to retrieve `baseTokenURI()`. While a `try/catch` block handles reverts, a compromised or malicious `launcher` contract could return unexpected or misleading metadata, or cause excessive gas consumption, potentially impacting dApps or interfaces that rely on this function for token information (7.2 Code Security, 7.6 External).
FixEnsure the `launcher` contract is highly secure and trustworthy. Consider implementing a mechanism to update the `launcher` address in case of compromise or inactivity, or a fallback to a default URI. Document the implications of this external dependency for users and integrators, highlighting the reliance on the `launcher`'s availability and integrity.
StatusUnresolved
Low

Unused `creator` Address Variable

L-01The `creator` address is stored as an immutable state variable in the constructor but is not utilized anywhere else within the contract's logic. This indicates either an incomplete feature, a design oversight, or unnecessary storage, consuming gas for deployment and state (7.1 Architecture, 7.3 Access Control).
IssueThe `creator` address is stored as an immutable state variable in the constructor but is not utilized anywhere else within the contract's logic. This indicates either an incomplete feature, a design oversight, or unnecessary storage, consuming gas for deployment and state (7.1 Architecture, 7.3 Access Control).
FixIf the `creator` variable serves no functional purpose, remove it to optimize contract size and gas costs. If it is intended for a future feature, clearly define its role and implement the corresponding logic.
StatusUnresolved
Info

Non-Standard `tokenURI` for ERC20

I-01The `StonkToken` contract implements a `tokenURI()` function, which is typically associated with ERC721 or ERC1155 tokens for metadata. While technically permissible for an ERC20, its presence is non-standard and might lead to confusion for integrators or users expecting standard ERC20 behavior without such metadata functions (7.1 Architecture).
IssueThe `StonkToken` contract implements a `tokenURI()` function, which is typically associated with ERC721 or ERC1155 tokens for metadata. While technically permissible for an ERC20, its presence is non-standard and might lead to confusion for integrators or users expecting standard ERC20 behavior without such metadata functions (7.1 Architecture).
FixClearly document the purpose and expected behavior of the `tokenURI()` function for this ERC20 token. Ensure dApps integrating with `StonkToken` are aware of this non-standard extension and how to interpret its output.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract leverages OpenZeppelin's robust ERC20 implementation, ensuring standard token functionalities are secure (7.2 Code Security). The custom `_hexAddress` function is correctly implemented. However, the `tokenURI` function introduces an external call dependency to the `launcher` contract, which, despite a `try/catch` block, could be a point of failure or manipulation if the `launcher` contract is compromised or misbehaves (7.6 External). The `creator` address is stored but unused, indicating potential dead code or an incomplete feature (7.1 Architecture).

GovernanceHigh1/10

The contract's economic model is straightforward, being a standard ERC20 token without complex DeFi primitives. A significant concern is the initial minting of the entire `totalSupply` to a single `launcher` address (7.4 Economic). This grants the `launcher` complete control over the token's distribution and supply, posing a critical centralization risk (7.3 Access Control). There are no governance mechanisms implemented within this contract (7.5 Governance).

UpgradesMedium5/10

The StonkToken contract is implemented as a standard, non-upgradeable contract (7.7 Upgrades). This design choice eliminates risks associated with proxy patterns, such as upgradeability bugs or proxy administration vulnerabilities. However, it also means that no fixes or feature enhancements can be deployed to the contract after deployment, requiring a new deployment for any changes (7.8 Operations).

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

30.9% in top 10
0.0% in wallets30.9% in contracts
Effective Concentration12.4%

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

$76.4K across 9 pairs
Uniswap v3AAPLcanalysed$73.1K95.7%Uniswap v4USDC$1.5K2.0%Uniswap v4USDC$4890.6%Uniswap v4USDC$4760.6%Uniswap v4ETH$4320.6%Uniswap v4ETH$2170.3%
Show 3 more pairsShow less
Uniswap v4USDC$960.1%Uniswap v4USDC$920.1%Uniswap v4USDC$60.0%

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

Key Addresses

3 addresses
Deployer
0x048e…cef5
Unlocked LP Held By
0x044e…6bc70xf939…3535

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

What Raised This Score

8 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 90.1% (independent LP — depth risk, pool = 96% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 96% of DEX liquidity)
  • Token age < 7 days (early, volatile)
  • 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
ViciCoin (VCNT)High RiskgitlawbHigh RiskWrapped liquid staked Ether 2.0 (WSTETH)High RiskSuperform (UP)High RiskaeonHigh RiskCoinbase Wrapped Staked ETH (CBETH)High Risk

Would You Like a More Detailed Audit of iStonks?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit