Quantum Audit Logo

Is ANDY Safe?

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

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

ANDY ANDY
0x4c42…4444
BNB Chain Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The `FourERC20` contract implements a standard ERC-20 token using OpenZeppelin libraries. However, it critically lacks a constructor to initialize the token's name and symbol, and no public functions are provided to mint an initial supply or manage the total supply. This renders the token non-functional upon deployment, as it will have zero supply and uninitialized metadata. The core ERC-20 logic is robust due to OpenZeppelin's audited code, but the deployment and initialization strategy is fundamentally flawed.

1 Critical1 High1 Informational
Volume 24h
$17.5K
Liquidity
$132.8K
Price
$0.001432
Token Age
1mo
Top 10 Holders
91.7%

Security Findings

1 Crit1 High1 Info
Critical

Non-Functional Token: Missing Initialization and Supply Mechanism

C-01The `FourERC20` contract, as provided, lacks a constructor to properly initialize essential token metadata (name, symbol) and does not include any public function to mint an initial supply of tokens. The internal `_init` function is never invoked, and the `_mint` function is only internal. Consequently, upon deployment, the token will have an empty name, symbol, and a `_totalSupply` of zero, rendering it completely non-functional and unusable for its intended purpose as an ERC-20 token. (7.1 Architecture, 7.4 Economic)
IssueThe `FourERC20` contract, as provided, lacks a constructor to properly initialize essential token metadata (name, symbol) and does not include any public function to mint an initial supply of tokens. The internal `_init` function is never invoked, and the `_mint` function is only internal. Consequently, upon deployment, the token will have an empty name, symbol, and a `_totalSupply` of zero, rendering it completely non-functional and unusable for its intended purpose as an ERC-20 token. (7.1 Architecture, 7.4 Economic)
FixImplement a constructor in `FourERC20` to: 1) call `_init` with the desired token name and symbol, and 2) mint an initial supply of tokens to a designated address (e.g., the deployer). Alternatively, provide a public, access-controlled minting function if dynamic supply management is intended.
StatusUnresolved
High

Lack of Access Control for Potential Privileged Functions

H-01The contract includes internal `_mint` and `_burn` functions, which are typically associated with privileged operations to manage token supply. However, the contract currently lacks any access control mechanisms (e.g., `Ownable`, `AccessControl`). If public functions are later added to expose these internal minting or burning capabilities, the absence of access control would allow any external caller to manipulate the token supply, leading to severe economic instability and potential rug pulls. (7.3 Access Control, 7.4 Economic)
IssueThe contract includes internal `_mint` and `_burn` functions, which are typically associated with privileged operations to manage token supply. However, the contract currently lacks any access control mechanisms (e.g., `Ownable`, `AccessControl`). If public functions are later added to expose these internal minting or burning capabilities, the absence of access control would allow any external caller to manipulate the token supply, leading to severe economic instability and potential rug pulls. (7.3 Access Control, 7.4 Economic)
FixIf public minting or burning functions are introduced in a derived contract, integrate a robust access control mechanism (e.g., OpenZeppelin's `Ownable` or `AccessControl`) to restrict these sensitive operations to authorized addresses only.
StatusUnresolved
Info

Unused Internal `_contextSuffixLength` Function

I-01The `Context.sol` contract includes an internal virtual function `_contextSuffixLength` which returns 0. While this is part of the OpenZeppelin `Context` standard, it is not utilized or overridden in `FourERC20.sol`. In the context of `FourERC20` being a standalone token, this function adds minor, unnecessary complexity without providing any specific functionality. (7.2 Code Security)
IssueThe `Context.sol` contract includes an internal virtual function `_contextSuffixLength` which returns 0. While this is part of the OpenZeppelin `Context` standard, it is not utilized or overridden in `FourERC20.sol`. In the context of `FourERC20` being a standalone token, this function adds minor, unnecessary complexity without providing any specific functionality. (7.2 Code Security)
FixConsider if `_contextSuffixLength` is truly needed or if a simpler `Context` base could be used if no meta-transaction features are planned. For standard ERC20, it's generally harmless but unused.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract leverages well-audited OpenZeppelin libraries for its core ERC-20 functionality (7.2 Code Security), providing a strong foundation for transfer and allowance mechanisms. However, a critical architectural flaw exists as the contract lacks a constructor to initialize essential token metadata like name and symbol, and no public minting mechanism is provided (7.1 Architecture). This means the token will be non-functional upon deployment, as `_totalSupply` will remain zero and metadata will be empty. The `_init` function is present but never called.

GovernanceMedium6/10

The economic model is severely impacted by the lack of an initial token supply and minting mechanism (7.4 Economic). Without a way to create tokens, the `_totalSupply` will remain zero, making the token economically useless. There are no specific governance mechanisms implemented (7.5 Governance), which is acceptable for a simple token, but the fundamental economic viability is compromised by the inability to create any tokens.

UpgradesLow9/10

The contract is not designed to be upgradeable (7.7 Upgrades), as indicated by `is_proxy: false`. This simplifies the deployment model by removing upgrade-related risks, but also means any discovered issues post-deployment cannot be fixed without a new deployment. Given the current critical functionality issues, this lack of upgradeability is a significant limitation.

Security Checklist

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

Holder Composition

91.7% in top 10
54.8% in wallets36.9% in contracts
Effective Concentration69.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

$132.8K

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

1 addresses
Deployer
0x8828…8828

What Raised This Score

3 factors
  • Top-10 concentration > 50% (91.7% total → 69.5% effective; 54.8% in EOAs, 36.9% in contracts — heavy)
  • 1 Critical finding(s) from audit
  • 1 High 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
ZygoSwap (ZSWAP)Medium RiskSIRENMedium RiskIBSLow RiskCZ Terminal Token (CZT)Low RiskMEET48 Token (IDOL)Medium Riskbinanceus doodles (BOODLES)Medium Risk

Would You Like a More Detailed Audit of ANDY?

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

Get Detailed Audit