Quantum Audit Logo

Is An Amazon Box Safe?

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

An Amazon Box BOX
0x4d2e…1fc2
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 10d ago 1 audit on record
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 contracts. It features a custom `tokenURI` function that retrieves metadata from an external `launcher` contract. The primary risks identified relate to the high centralization of initial token supply and the reliance on an external contract for metadata, which could impact user experience or present a vector for misleading information.

1 High1 Medium2 Informational
Volume 24h
$167.4K
Liquidity
$68.5K
Price
$0.0003285
Token Age
11d
Top 10 Holders
24.9%

Security Findings

1 High1 Med2 Info
High

Centralization of Initial Token Supply

H-01The `StonkToken` contract mints the entire `totalSupply_` to the `launcher_` address during construction. This design choice places all initial tokens under the control of a single address. If the `launcher` address were to be compromised, all tokens could be stolen or misused, representing a significant single point of failure for the token's initial distribution and ecosystem.
IssueThe `StonkToken` contract mints the entire `totalSupply_` to the `launcher_` address during construction. This design choice places all initial tokens under the control of a single address. If the `launcher` address were to be compromised, all tokens could be stolen or misused, representing a significant single point of failure for the token's initial distribution and ecosystem.
FixConsider distributing the initial token supply across multiple addresses, such as a multi-signature wallet, a timelock contract, or a vesting schedule, to reduce the risk associated with a single point of failure. If a single `launcher` address is necessary, ensure it is secured with the highest possible operational security measures.
StatusUnresolved
Medium

Reliance on External Contract for Token Metadata

M-01The `tokenURI()` function relies on an external call to `IStonkLauncherBaseURI(launcher).baseTokenURI()` to retrieve the base URI for token metadata. While a `try/catch` block handles reverts, a malicious or buggy `launcher` contract could return misleading or inappropriate metadata, impacting how the token is displayed in user interfaces. Additionally, a poorly implemented external contract could return an excessively long string, increasing gas costs for off-chain services attempting to retrieve the URI.
IssueThe `tokenURI()` function relies on an external call to `IStonkLauncherBaseURI(launcher).baseTokenURI()` to retrieve the base URI for token metadata. While a `try/catch` block handles reverts, a malicious or buggy `launcher` contract could return misleading or inappropriate metadata, impacting how the token is displayed in user interfaces. Additionally, a poorly implemented external contract could return an excessively long string, increasing gas costs for off-chain services attempting to retrieve the URI.
FixEnsure the `launcher` address points to a highly secure and trusted contract that is specifically designed to provide reliable metadata. Implement monitoring for the `launcher` contract's behavior. Consider adding a mechanism to update the `launcher` address in a controlled manner (e.g., via governance) if the current `launcher` becomes compromised or unreliable, although this would introduce upgradeability considerations.
StatusUnresolved
Info

Unused `creator` Address Variable

I-01The `creator` address is set as an immutable variable in the constructor but is never referenced or utilized within any other function of the `StonkToken` contract. While not a vulnerability, it represents dead code or a potentially intended feature that was not fully implemented.
IssueThe `creator` address is set as an immutable variable in the constructor but is never referenced or utilized within any other function of the `StonkToken` contract. While not a vulnerability, it represents dead code or a potentially intended feature that was not fully implemented.
FixIf the `creator` address is intended to have a role, implement the corresponding logic. Otherwise, consider removing the `creator` variable to reduce contract size and improve clarity, or document its intended off-chain purpose.
StatusUnresolved
Info

Custom `_hexAddress` Function

I-02The contract implements a custom `_hexAddress` function to convert `address(this)` to a hexadecimal string. While functionally correct and efficient, OpenZeppelin's `Strings.toHexString` provides similar functionality and is a widely adopted, audited utility. Using standard library functions can improve code readability and maintainability.
IssueThe contract implements a custom `_hexAddress` function to convert `address(this)` to a hexadecimal string. While functionally correct and efficient, OpenZeppelin's `Strings.toHexString` provides similar functionality and is a widely adopted, audited utility. Using standard library functions can improve code readability and maintainability.
FixConsider replacing the custom `_hexAddress` function with `Strings.toHexString(address(this))` from OpenZeppelin's `utils/Strings.sol` for consistency with common practices and leveraging audited library code.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The StonkToken contract is built upon OpenZeppelin's ERC-20 implementation, providing a solid foundation for code security (7.2) and standard compliance. The custom `_hexAddress` function is well-implemented for converting the contract address to a hex string. However, the `tokenURI` function introduces an external dependency (7.6) on the `launcher` address, which could potentially return misleading metadata or incur high gas costs if the external contract is compromised or poorly implemented, despite the use of `try/catch` for error handling.

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 the initial distribution of all tokens to a single address, presenting a significant single point of failure if the `launcher` address is compromised. While the `creator` address is stored, it has no governance or economic control (7.5) within the contract, limiting its utility.

UpgradesMedium6/10

The StonkToken contract is not designed with upgradeability in mind (7.7), as indicated by the absence of proxy patterns or upgrade-related modules. This simplifies the architecture by removing upgrade-specific risks, but also means that any future changes to the contract's logic would require a new deployment and migration of assets, which can be a complex and costly operation.

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

24.9% in top 10
5.2% in wallets19.7% in contracts
Effective Concentration13.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

$68.6K across 4 pairs
Uniswap v3AMZNcanalysed$68.5K99.9%Uniswap v4USDC$310.0%Uniswap v4USDC$300.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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0xabe1…029e
Unlocked LP Held By
0xe6fc…71f1

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

What Raised This Score

7 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 = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • Token age < 30 days (still settling)
  • 1 High finding(s) from audit
  • 1 Medium 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 RiskThe Stonks Exchange (STONKEX)Medium RiskBasehatMedium RiskOpalMedium Riskaixbt by Virtuals (AIXBT)Medium RiskOpenGradient (OPG)Medium Risk

Would You Like a More Detailed Audit of An Amazon Box?

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

Get Detailed Audit