Quantum Audit Logo

Is Everybody Safe?

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

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

Everybody HOLD
0x68b3…78f3
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 today 1 audit on record
Executive SummaryAI Copilot

The audited contract is a standard ERC-20 token implementation. It utilizes the SafeMath library to prevent integer overflow/underflow vulnerabilities. The core token functionalities adhere to the ERC-20 standard. No critical or high-severity issues were identified, indicating a robust and well-implemented token contract.

4 Informational
Volume 24h
$144.8K
Liquidity
$438.6K
Price
$0.0002179
Token Age
2y
Top 10 Holders
77.0%

Security Findings

Info

Redundant SafeMath Usage in Solidity 0.8.x

I-01The contract uses the `SafeMath` library for arithmetic operations. While this is a good practice for older Solidity versions, Solidity 0.8.0 and later versions (like 0.8.9 used here) include native overflow and underflow checks by default, making explicit `SafeMath` usage redundant.
IssueThe contract uses the `SafeMath` library for arithmetic operations. While this is a good practice for older Solidity versions, Solidity 0.8.0 and later versions (like 0.8.9 used here) include native overflow and underflow checks by default, making explicit `SafeMath` usage redundant.
FixConsider removing the `SafeMath` library to slightly reduce gas costs and simplify the code, relying on the compiler's built-in overflow/underflow checks.
StatusUnresolved
Info

Internal Mint/Burn Functions Require External Access Control

I-02The `_mint` and `_burn` functions are declared as `internal virtual`. This design allows inheriting contracts to extend or expose these functionalities. However, if an inheriting contract exposes these functions externally without proper access control (e.g., `onlyOwner`), it could lead to unauthorized token creation or destruction, impacting the token's supply and value.
IssueThe `_mint` and `_burn` functions are declared as `internal virtual`. This design allows inheriting contracts to extend or expose these functionalities. However, if an inheriting contract exposes these functions externally without proper access control (e.g., `onlyOwner`), it could lead to unauthorized token creation or destruction, impacting the token's supply and value.
FixAny contract inheriting from this `ERC20` base should implement robust access control mechanisms (e.g., `Ownable` pattern) for any externally callable functions that wrap `_mint` or `_burn` to prevent unauthorized supply manipulation.
StatusUnresolved
Info

ERC-20 `approve` Race Condition

I-03The standard ERC-20 `approve` function is susceptible to a known front-running vulnerability. If a user increases an allowance for a spender, and the spender has already spent part of the previous allowance but the transaction has not yet been mined, the spender might be able to spend the original allowance again before the new allowance takes effect, leading to a double-spend scenario up to the original allowance amount.
IssueThe standard ERC-20 `approve` function is susceptible to a known front-running vulnerability. If a user increases an allowance for a spender, and the spender has already spent part of the previous allowance but the transaction has not yet been mined, the spender might be able to spend the original allowance again before the new allowance takes effect, leading to a double-spend scenario up to the original allowance amount.
FixWhile this is a standard ERC-20 limitation, users should be aware of it. For critical operations, consider using `increaseAllowance` and `decreaseAllowance` functions, which mitigate this specific race condition by requiring the current allowance to be known.
StatusUnresolved
Info

Truncated SafeMath Library

I-04The provided `SafeMath` library code is truncated, specifically missing the `div` and `mod` functions. While these functions are not explicitly used in the visible `ERC20` contract code, their absence or incomplete implementation could pose a risk if they were to be used in future extensions or if the full `SafeMath` library was intended to be included.
IssueThe provided `SafeMath` library code is truncated, specifically missing the `div` and `mod` functions. While these functions are not explicitly used in the visible `ERC20` contract code, their absence or incomplete implementation could pose a risk if they were to be used in future extensions or if the full `SafeMath` library was intended to be included.
FixEnsure the complete and verified `SafeMath` library (or remove it entirely in favor of native checks) is used if arithmetic operations beyond `add`, `sub`, and `mul` are required.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The contract implements a standard ERC-20 token, demonstrating good practices such as the use of the SafeMath library to prevent integer overflows and underflows (7.2 Code Security). The architecture is straightforward, adhering to the ERC-20 standard (7.1 Architecture). While SafeMath is used, Solidity 0.8.0+ includes native overflow checks, making explicit SafeMath usage redundant and slightly increasing gas costs. Internal `_mint` and `_burn` functions require careful access control in any inheriting contract (7.3 Access Control).

GovernanceMedium6/10

This base ERC-20 contract does not include any specific governance or economic mechanisms (7.5 Governance, 7.4 Economic). Its functionality is limited to standard token transfers and approvals. Any economic or governance risks would stem from how this token is integrated into a broader protocol, which is outside the scope of this contract.

UpgradesLow10/10

The contract is not designed to be upgradeable and does not implement any proxy patterns (7.7 Upgrades). Therefore, there are no upgrade-specific risks associated with this contract. Any future changes or enhancements would require a new deployment of the contract.

Security Checklist

Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

74.5% in wallets2.5% in contracts
Effective Concentration75.5%

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

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

LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

Deployer
0x49ef…e88f
Unlocked LP Held By
0x1f2f…f387

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

What Raised This Score

  • Top-10 concentration > 70% (77.0% total → 75.5% effective; 74.5% in EOAs, 2.5% in contracts — extreme)

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

AsteroidLow RiskAmerica Pac (PAC)Low RiskJerry The Turtle By Matt Furie (JYAI)Low RiskNon-Playable Coin (NPC)Low RiskYee Token (YEE)Low RiskPikachuLow Risk

Would You Like a More Detailed Audit of Everybody?

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

Get Detailed Audit