Quantum Audit Logo

Is The Stonks Exchange a Scam?

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

The Stonks Exchange STONKEX
0x5ab0…80f5
Base Not verifiedLast checked 3d ago 1 audit on record New Launch · 5d old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The StonkToken contract is an ERC-20 token implementation, inheriting from OpenZeppelin's battle-tested ERC20 standard. The contract's primary custom logic involves a `tokenURI()` function that queries an external `launcher` contract for a base URI. The audit identified a medium-severity risk related to this external dependency, a low-severity architectural quirk, and an informational finding regarding initial token distribution. The core ERC-20 functionality is robust due to OpenZeppelin inheritance.

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

Security Findings

1 Med1 Low1 Info
Medium

External Dependency Risk in tokenURI Function

M-01The `tokenURI()` function makes an external call to `IStonkLauncherBaseURI(launcher).baseTokenURI()`. While a `try/catch` block is used to handle reverts, a compromised or malicious `launcher` contract could return a `baseTokenURI` that points to a phishing site, misleading information, or content that misrepresents the StonkToken. This external dependency (7.6) introduces a risk to users who rely on the token's metadata for display or interaction.
IssueThe `tokenURI()` function makes an external call to `IStonkLauncherBaseURI(launcher).baseTokenURI()`. While a `try/catch` block is used to handle reverts, a compromised or malicious `launcher` contract could return a `baseTokenURI` that points to a phishing site, misleading information, or content that misrepresents the StonkToken. This external dependency (7.6) introduces a risk to users who rely on the token's metadata for display or interaction.
FixEnsure the `launcher` address is controlled by a highly secure multi-signature wallet or a robust governance mechanism. Implement strict controls and auditing procedures for the `launcher` contract, especially for its `baseTokenURI()` function, to prevent it from returning malicious or misleading data. Consider adding a mechanism to update or disable the `launcher` address if it becomes compromised.
StatusUnresolved
Low

Unconventional Use of tokenURI for ERC-20

L-01The `tokenURI()` function is typically associated with ERC-721 or ERC-1155 NFTs, where it provides metadata for a specific `tokenId`. In this ERC-20 contract, `tokenURI()` returns metadata based on the contract's own address, not a token ID. While not a direct security vulnerability, this architectural choice (7.1) is unconventional for an ERC-20 and may lead to confusion or misinterpretation by platforms and users expecting ERC-721/1155 behavior or standard ERC-20 metadata practices.
IssueThe `tokenURI()` function is typically associated with ERC-721 or ERC-1155 NFTs, where it provides metadata for a specific `tokenId`. In this ERC-20 contract, `tokenURI()` returns metadata based on the contract's own address, not a token ID. While not a direct security vulnerability, this architectural choice (7.1) is unconventional for an ERC-20 and may lead to confusion or misinterpretation by platforms and users expecting ERC-721/1155 behavior or standard ERC-20 metadata practices.
FixClearly document the intended purpose and usage of the `tokenURI()` function for the StonkToken. If the goal is general token metadata, consider if a different approach (e.g., off-chain metadata linked to the contract address) would be less ambiguous. If it's intended for specific platform integration, ensure that platform understands this unique implementation.
StatusUnresolved
Info

Centralization of Initial Token Supply

I-01During contract deployment, the entire `totalSupply_` is minted to the `launcher_` address. This design choice (7.4) means that the `launcher` address holds 100% of the initial token supply. While this is a valid design pattern, it implies significant control by the `launcher` over the token's initial distribution and market dynamics. Any compromise of the `launcher` address could lead to a large-scale token dump.
IssueDuring contract deployment, the entire `totalSupply_` is minted to the `launcher_` address. This design choice (7.4) means that the `launcher` address holds 100% of the initial token supply. While this is a valid design pattern, it implies significant control by the `launcher` over the token's initial distribution and market dynamics. Any compromise of the `launcher` address could lead to a large-scale token dump.
FixEnsure the `launcher` address is secured with robust measures, such as a hardware wallet or a multi-signature setup. If the intention is to distribute tokens, a clear and transparent distribution plan should be communicated to the community. Consider implementing time-locks or vesting schedules for large token holdings if appropriate for the project's tokenomics.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The StonkToken contract demonstrates good technical architecture (7.1) by inheriting from OpenZeppelin's ERC20, which provides a robust and audited foundation for token functionality. The custom `_hexAddress()` function is correctly implemented for its purpose. However, the `tokenURI()` function introduces an external dependency (7.6) on the `launcher` address, which could potentially serve malicious metadata if compromised. While `try/catch` is used for error handling, it does not mitigate the risk of malicious but valid data.

GovernanceHigh2/10

The economic model (7.4) of StonkToken is straightforward: a fixed total supply is minted entirely to the `launcher` address during deployment. This design choice centralizes initial token distribution to a single entity. There are no explicit governance mechanisms (7.5) or privileged roles beyond the initial constructor parameters, simplifying the contract's operational footprint (7.8).

UpgradesMedium6/10

The StonkToken contract is not designed with upgradeability in mind (7.7). It is a standard, non-proxy implementation, meaning its logic cannot be altered post-deployment. This reduces complexity and eliminates upgrade-related risks, but also means any discovered vulnerabilities would require a new deployment.

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

29.6% in top 10
13.6% in wallets16.0% in contracts
Effective Concentration20.0%

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

$272.2K across 11 pairs
Uniswap v3WETHanalysed$191.7K70.4%AerodromefBOMB$75.6K27.8%Uniswap v4USDC$2.6K0.9%Uniswap v4STFY$1.4K0.5%Uniswap v4USDC$4810.2%Uniswap v4USDC$4120.2%
Show 4 more pairsShow less
Uniswap v4USDC$90.0%Uniswap v4USDC$70.0%Uniswap v4USDC$70.0%Uniswap v4USDC$00.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 Holder98.5%
Top-3 Unlocked99.8%

Key Addresses

11 addresses
Deployer
0x81dd…e1e1
Unlocked LP Held By
0x71d1…0a7f0x641f…70400x6932…1f9f0x73e3…93d50xb270…9f6f0x2615…a0b40x5a3e…79e30x2992…2ffd0x5810…8eaf0x0020…ff6e

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)
  • Top-10 concentration > 20% (29.6% total → 20.0% effective; 13.6% in EOAs, 16.0% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 98.5% (independent LP — depth risk, pool = 70% of DEX liquidity)
  • LP top3 unlocked holders = 99.8% (independent LP — depth risk, pool = 70% of DEX liquidity)
  • Token age < 7 days (early, volatile)
  • 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
PlayMedium RiskBasehatMedium RiskOpalMedium Riskaixbt by Virtuals (AIXBT)Medium RiskOpenGradient (OPG)Medium RiskZoraMedium Risk

Would You Like a More Detailed Audit of The Stonks Exchange?

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

Get Detailed Audit