On-chain security analysis — is it a scam or legit?
BNB ChainThis audit covers a BEP20 token implementation designed for an upgradeable proxy.
Read the full analysisEach 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
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.
Holder balances as recorded by the audit of Sep 4, 2026
The 20 remaining pairs hold $248.1K between them and are not listed. The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0x556b…d59e0xa53b…22cc0x2ace…c77a0x6ac5…2a770x19bf…62260xc60f…d74c0x3e71…68280x15d6…6c4e0xb01f…50100x3543…5963No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
_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.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.
Consider 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.
Unresolved
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.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.
Educate 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.
Unresolved
initialize Parametersinitialize 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.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.
Emit 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);`
Unresolved
_burnFrom Function in Provided Source_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.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.
Ensure 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.
Unresolved
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.
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.
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.
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.
It is recommended to consider implementing a multi-signature wallet for the owner and proxy admin roles to mitigate the risks associated with centralized control and single points of failure.
Additionally, review the implications of the ERC-20 allowance race condition and ensure users are aware of best practices when interacting with the approve function. For future development, ensure all critical state changes and initializations emit corresponding events for enhanced transparency and off-chain monitoring.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
The SOLANA (SOL) contract on BNB Chain is 0x570a5d26f7765ecb712c0924e4de545b89fd43df. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Quantum Audit's risk score for SOLANA is 74/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Upgradeable. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $3.57M.
As of Sep 4, 2026, the 10 largest holders own 62.6% of the supply. The Holders section on this page shows who they are by holder type.
Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.
Get Detailed Audit Is this your token? Publish your own audit on this page
