Quantum Audit Logo

Is SOLANA Safe?

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

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

SOLANA SOL
0x570a…43df
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

This audit covers a BEP20 token implementation designed for an upgradeable proxy. The contract utilizes standard OpenZeppelin patterns for upgradeability, safe math, and access control. Key findings include centralized control by an EOA owner, a known ERC-20 allowance race condition, and informational observations regarding event emissions and incomplete source code.

1 High1 Medium2 Informational
Volume 24h
$1.69M
Liquidity
$1.30M
Price
$103.9000
Token Age
2y
Top 10 Holders
62.6%

Security Findings

1 High1 Med2 Info
High

Centralized Control by EOA Owner

H-01The contract's `_owner` is a single External Owned Account (EOA) that has significant control over the token. This includes the ability to mint new tokens (if `_mintable` is true), transfer ownership, and renounce ownership. Furthermore, the proxy's admin, also an EOA, controls contract upgrades. This centralization introduces a single point of failure, where compromise of this EOA could lead to unauthorized minting, malicious upgrades, or loss of control over the token.
IssueThe contract's `_owner` is a single External Owned Account (EOA) that has significant control over the token. This includes the ability to mint new tokens (if `_mintable` is true), transfer ownership, and renounce ownership. Furthermore, the proxy's admin, also an EOA, controls contract upgrades. This centralization introduces a single point of failure, where compromise of this EOA could lead to unauthorized minting, malicious upgrades, or loss of control over the token.
FixConsider migrating the `_owner` and proxy admin roles to a multi-signature wallet (e.g., Gnosis Safe) to distribute control and reduce the risk associated with a single point of compromise. This enhances security by requiring multiple approvals for critical operations.
StatusUnresolved
Medium

ERC-20 Allowance Race Condition

M-01The standard `approve` function is susceptible to a known ERC-20 allowance race condition. If a user approves an amount, and then attempts to change that allowance to a different value, a malicious spender could front-run the second transaction. This allows the spender to spend the original allowance, and then also spend the new allowance, effectively doubling the amount they can spend. While `increaseAllowance` and `decreaseAllowance` mitigate this for changes, the initial `approve` is still vulnerable.
IssueThe standard `approve` function is susceptible to a known ERC-20 allowance race condition. If a user approves an amount, and then attempts to change that allowance to a different value, a malicious spender could front-run the second transaction. This allows the spender to spend the original allowance, and then also spend the new allowance, effectively doubling the amount they can spend. While `increaseAllowance` and `decreaseAllowance` mitigate this for changes, the initial `approve` is still vulnerable.
FixEducate users about the risks of the `approve` function and recommend using `increaseAllowance` and `decreaseAllowance` when modifying existing allowances. For initial approvals, users should be cautious and verify transactions. While this is a standard ERC-20 behavior, awareness is key.
StatusUnresolved
Info

Missing Event for `initialize` Parameters

I-01The `initialize` function sets critical parameters such as `name`, `symbol`, `decimals`, `initial amount`, `mintable` status, and `owner`. However, it does not emit an event to log these initial configurations on-chain. This makes it harder for off-chain systems, block explorers, and monitoring tools to reliably track the token's initial setup and verify its properties without parsing transaction input data.
IssueThe `initialize` function sets critical parameters such as `name`, `symbol`, `decimals`, `initial amount`, `mintable` status, and `owner`. However, it does not emit an event to log these initial configurations on-chain. This makes it harder for off-chain systems, block explorers, and monitoring tools to reliably track the token's initial setup and verify its properties without parsing transaction input data.
FixEmit an event within the `initialize` function that logs all the significant parameters set during the contract's initial setup. For example, `event Initialized(string name, string symbol, uint8 decimals, uint256 initialSupply, bool mintable, address owner);`
StatusUnresolved
Info

Incomplete `_burnFrom` Function in Provided Source

I-02The provided source code for the internal `_burnFrom` function is truncated, ending with `_allowances[account][_msgSender()].sub(am...`. This prevents a full security review of its logic. While it is an internal function, its complete implementation is necessary to ensure no vulnerabilities exist within its scope, especially concerning allowance management.
IssueThe provided source code for the internal `_burnFrom` function is truncated, ending with `_allowances[account][_msgSender()].sub(am...`. This prevents a full security review of its logic. While it is an internal function, its complete implementation is necessary to ensure no vulnerabilities exist within its scope, especially concerning allowance management.
FixEnsure that the complete and verified source code for all functions, including internal ones, is available for a comprehensive security audit. This allows for a thorough review of all code paths and logic.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The technical architecture (7.1 Architecture) is a standard BEP20 token implementation designed for upgradeability using the Initializable pattern. Code security (7.2 Code Security) is enhanced by the use of SafeMath for all arithmetic operations, mitigating integer overflow/underflow risks. However, the standard ERC-20 `approve` function remains susceptible to a known allowance race condition. Access control (7.3 Access Control) for core token functions like `transfer` and `approve` is standard, while `mint` is restricted to the owner.

GovernanceHigh1/10

The economic model (7.4 Economic) allows for optional minting, controlled by a single owner EOA, which introduces significant centralization risk if the `_mintable` flag is true. This centralized control extends to governance (7.5 Governance), as there is no decentralized governance mechanism; all critical administrative functions, including ownership transfer and minting, are managed by a single EOA. This creates a single point of failure and trust for the token's supply and administrative actions.

UpgradesHigh1/10

The contract is designed for upgradeability (7.7 Upgrades) using the `Initializable` pattern, correctly preventing re-initialization. The proxy admin, a single EOA, controls the upgrade process, which presents a high risk due to the single point of compromise. While `Initializable` helps, careful management of storage layout is crucial during upgrades to prevent storage collisions, especially with the Transparent proxy pattern. The empty constructor is correctly implemented for upgradeable contracts.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminEOA (single key controls upgrades)
ImplementationVerified source

Holder Composition

62.6% in top 10
61.6% in wallets1.1% in contracts
Effective Concentration62.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

$3.57M across 30 pairs
Pancakeswap v3WBNBanalysed$1.30M36.3%Pancakeswap v3USDT$647.2K18.1%Pancakeswap v3WBNB$477.1K13.4%UniswapWBNB$282.6K7.9%BabyswapWBNB$167.5K4.7%BabyswapUSDT$161.3K4.5%
Show 4 more pairsShow less
Uniswap比特币$93.8K2.6%Pancakeswap v3ETH$66.8K1.9%BiswapWBNB$65.7K1.8%Pancakeswap v3BTCB$64.0K1.8%

The 20 remaining pairs hold $248.1K 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 Holder99.7%
Top-3 Unlocked100.0%

Key Addresses

11 addresses
Deployer
0x08ad…b9b7
Unlocked LP Held By
0x556b…d59e0xa53b…22cc0x2ace…c77a0x6ac5…2a770x19bf…62260xc60f…d74c0x3e71…68280x15d6…6c4e0xb01f…50100x3543…5963

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

What Raised This Score

10 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Admin is EOA (single key controls upgrades)
  • Top-10 concentration > 50% (62.6% total → 62.0% effective; 61.6% in EOAs, 1.1% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.7% (independent LP — depth risk, pool = 36% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 36% of DEX liquidity)
  • 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
elizaOSCritical Risk金蟾 (JIN)Critical RiskbStocks Never Sleep (BSTOCKS)Critical RiskZypher Token (POP)Critical RiskPancakeSwap Token (CAKE)Critical RiskSubsquid (SQD)Critical Risk

Would You Like a More Detailed Audit of SOLANA?

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

Get Detailed Audit