Quantum Audit Logo

Is send a Scam?

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

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

send SEND
0x47ac…5999
Ethereum
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.Own this token? Put it under verification →
Last checked 9d ago 1 audit on record New Launch · 2d old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The LaunchToken contract is an ERC20 token implementation designed for a specific launch phase with trading restrictions and a holder reward mechanism. The contract utilizes OpenZeppelin libraries for standard ERC20 functionality and includes custom logic for reward distribution and initial market caps. Key strengths include a robust proxy initialization pattern and reentrancy-safe reward claiming. However, significant centralized control by the 'factory' address introduces high governance and economic risks, including potential for reward manipulation. Several medium and informational findings were identified, primarily related to economic incentives and minor code quality.

1 High2 Medium1 Low3 Informational
! Early-stage analysis. This token has limited on-chain history (2d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$2.36M
Liquidity
$287.4K
Price
$0.001993
Token Age
2d
Top 10 Holders
23.6%

Security Findings

1 High2 Med1 Low3 Info
High

Centralized Control by Factory Address

H-01The `factory` address holds significant power, including the ability to set the market, enable holder fees, and bypass reward source checks for `notifyReward`. A compromise of this address could lead to manipulation of the token's economic parameters and reward system, potentially causing financial loss or unfair distribution. This represents a single point of failure for critical operations (7.3 Access Control, 7.4 Economic).
IssueThe `factory` address holds significant power, including the ability to set the market, enable holder fees, and bypass reward source checks for `notifyReward`. A compromise of this address could lead to manipulation of the token's economic parameters and reward system, potentially causing financial loss or unfair distribution. This represents a single point of failure for critical operations (7.3 Access Control, 7.4 Economic).
FixConsider implementing a multi-signature wallet for the `factory` address or introducing time-locks for critical operations (e.g., `setMarket`, `enableHolderFees`, `notifyReward` calls by `factory`) to mitigate single-point-of-failure risks and provide a window for community reaction.
StatusUnresolved
Medium

Potential for Reward Manipulation by Factory

M-01The `factory` address can call `notifyReward` without requiring a corresponding transfer of `rewardToken` or native ETH to the contract. This allows the `factory` to artificially inflate `accRewardPerToken`, potentially diluting legitimate rewards for other holders or creating a misleading impression of rewards being distributed without actual contributions (7.4 Economic, 7.3 Access Control).
IssueThe `factory` address can call `notifyReward` without requiring a corresponding transfer of `rewardToken` or native ETH to the contract. This allows the `factory` to artificially inflate `accRewardPerToken`, potentially diluting legitimate rewards for other holders or creating a misleading impression of rewards being distributed without actual contributions (7.4 Economic, 7.3 Access Control).
FixRestrict `notifyReward` to only the `rewardSource` address, or modify the `notifyReward` function to explicitly require a corresponding transfer of actual rewards to the contract when called by the `factory`.
StatusUnresolved
Medium

`eligibleSupply` Manipulation Risk

M-02If a malicious actor (e.g., `factory` or `rewardSource`) can significantly reduce `eligibleSupply` (e.g., by excluding most holders), a small `amount` in `notifyReward` could cause a disproportionately large increase in `accRewardPerToken`. This could be exploited to claim a large share of rewards with minimal actual contribution, leading to unfair reward distribution (7.4 Economic).
IssueIf a malicious actor (e.g., `factory` or `rewardSource`) can significantly reduce `eligibleSupply` (e.g., by excluding most holders), a small `amount` in `notifyReward` could cause a disproportionately large increase in `accRewardPerToken`. This could be exploited to claim a large share of rewards with minimal actual contribution, leading to unfair reward distribution (7.4 Economic).
FixImplement safeguards or monitoring for drastic changes in `eligibleSupply` or `accRewardPerToken` relative to actual reward contributions. Consider a minimum `eligibleSupply` threshold for `notifyReward` to prevent extreme dilution, or a mechanism to cap the `accRewardPerToken` increase per `notifyReward` call.
StatusUnresolved
Low

Theoretical Integer Overflow in Reward Calculation

L-01While unlikely given typical values, the intermediate product `balanceOf(account) * accRewardPerToken` in `_settle` and `_rebase` could theoretically overflow if `accRewardPerToken` grows to an extremely large value (e.g., `type(uint256).max / TOTAL_SUPPLY`). Although Solidity 0.8+ checks for this, it would lead to a transaction revert, potentially blocking reward claims for affected users (7.2 Code Security, 7.4 Economic).
IssueWhile unlikely given typical values, the intermediate product `balanceOf(account) * accRewardPerToken` in `_settle` and `_rebase` could theoretically overflow if `accRewardPerToken` grows to an extremely large value (e.g., `type(uint256).max / TOTAL_SUPPLY`). Although Solidity 0.8+ checks for this, it would lead to a transaction revert, potentially blocking reward claims for affected users (7.2 Code Security, 7.4 Economic).
FixMonitor `accRewardPerToken` growth in production. While the risk is low, consider adding a maximum cap to `accRewardPerToken` or implementing a mechanism to reset it if it approaches dangerous levels, though this would require careful economic modeling.
StatusUnresolved
Info

`MarketAlreadySet` Error Misuse

I-01The `enableHolderFees` function uses the `MarketAlreadySet` error when `holderFeesEnabled` is already true. This is a minor inconsistency in error messaging, as the error name does not accurately reflect the condition (7.2 Code Security).
IssueThe `enableHolderFees` function uses the `MarketAlreadySet` error when `holderFeesEnabled` is already true. This is a minor inconsistency in error messaging, as the error name does not accurately reflect the condition (7.2 Code Security).
FixRename the error to `HolderFeesAlreadyEnabled` or create a new specific error for this condition to improve clarity and maintain consistent error semantics.
StatusUnresolved
Info

Unused `metadataURI` Variable

I-02The `metadataURI` state variable is set during `initialize` but is not used anywhere else within the contract logic. If its purpose is solely for off-chain metadata, its presence in the contract might be unnecessary (7.2 Code Security).
IssueThe `metadataURI` state variable is set during `initialize` but is not used anywhere else within the contract logic. If its purpose is solely for off-chain metadata, its presence in the contract might be unnecessary (7.2 Code Security).
FixIf `metadataURI` is not intended for on-chain use, consider removing it to reduce contract size and complexity. If it serves an off-chain purpose, ensure this is clearly documented.
StatusUnresolved
Info

`receive()` function without specific logic

I-03The `receive()` function is present and `payable` but contains no specific logic. While it allows the contract to receive native ETH, its explicit purpose might be unclear if not directly tied to a specific feature beyond `notifyReward` being payable (7.2 Code Security).
IssueThe `receive()` function is present and `payable` but contains no specific logic. While it allows the contract to receive native ETH, its explicit purpose might be unclear if not directly tied to a specific feature beyond `notifyReward` being payable (7.2 Code Security).
FixIf the contract is not intended to directly receive native ETH for purposes other than `notifyReward`, consider removing the `receive()` function or adding a comment explaining its intended use to improve code clarity.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract leverages OpenZeppelin's ERC20 and SafeERC20 for robust token operations, ensuring standard compliance and safe external interactions. The reward distribution mechanism, including `accRewardPerToken` and `eligibleSupply` tracking, is well-structured, and the `claim` function correctly places state updates before external calls, mitigating reentrancy risks (7.2 Code Security). However, a theoretical risk of integer overflow in reward calculations exists under extreme conditions (L-01), and a minor error message inconsistency was noted (I-01). (7.2 Code Security, 7.6 External)

GovernanceHigh1/10

The `factory` address holds significant centralized control, including critical setup functions like `setMarket` and `enableHolderFees`, and the ability to bypass reward source checks for `notifyReward` (H-01). This introduces a single point of failure and a potential for reward manipulation by the `factory` (M-01). Additionally, the `eligibleSupply` mechanism could be exploited if manipulated to disproportionately inflate `accRewardPerToken` (M-02). The token implements specific buy and hold caps during a launch phase, which are bypassed for the `factory` and `creator` as intended. (7.3 Access Control, 7.4 Economic, 7.5 Governance)

UpgradesMedium6/10

The contract is designed as an upgradeable implementation, utilizing a standard `initialize` function with a `factory != address(0)` guard to prevent re-initialization. The constructor sets `factory` to `address(0xdead)`, a common pattern to prevent direct initialization on the implementation contract. This setup aligns with best practices for upgradeable contracts, ensuring safe initialization through a proxy. (7.1 Architecture, 7.7 Upgrades)

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

23.6% in top 10
8.7% in wallets14.9% in contracts
Effective Concentration14.7%

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

$368.3K across 21 pairs
Uniswap v4ETHanalysed$287.4K78.0%Uniswap v4USDC$19.5K5.3%Uniswap v4USDC$10.8K2.9%Uniswap v4USDC$8.6K2.3%Uniswap v4USDC$8.0K2.2%Uniswap v4USDC$5.1K1.4%
Show 4 more pairsShow less
Uniswap v4USDC$5.1K1.4%Uniswap v4USDC$4.8K1.3%Uniswap v4USDC$3.8K1.0%Uniswap v4USDC$3.4K0.9%

The 11 remaining pairs hold $11.8K between them and are not listed.

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 Holder67.4%
Top-3 Unlocked100.0%

Key Addresses

4 addresses
Deployer
0xdfab…ac3d
Unlocked LP Held By
0x3132…6dbd0x8fa8…af6f0x5213…0b5c

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 = 67.4% (independent LP — depth risk, pool = 78% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 78% of DEX liquidity)
  • Token age < 7 days (early, volatile)
  • 1 High finding(s) from audit
  • 2 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
Satellite Doge-1 (DOGE-1)Medium RiskNeiroMedium RiskCurve.Fi USD Stablecoin (CRVUSD)Medium RiskEuro Coin (EURC)Medium RiskWorld Liberty Financial (WLFI)Medium RiskWorldcoin (WLD)Medium Risk

Would You Like a More Detailed Audit of send?

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

Get Detailed Audit