On-chain security analysis — is it a scam or legit?
BNB ChainThe BlueWhaleToken contract is a standard ERC20 implementation leveraging battle-tested OpenZeppelin libraries.
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 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.
0xf949…02980x55a1…be140x1498…d27e0xabe1…e0bf0x5471…c2cf0xa86d…dfc30x29ce…07e40xe8b0…a2bf0x5ca2…d75f0x4cc4…2ee2No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Ownable pattern, which grants a single address (or a multisig, as indicated by the prefill) exclusive control over certain administrative functions, specifically transferOwnership and renounceOwnership. While the prefill indicates a multisig, the contract itself does not enforce this, relying on external operational security. This centralization introduces a single point of control for critical administrative actions.L-01The contract utilizes OpenZeppelin's Ownable pattern, which grants a single address (or a multisig, as indicated by the prefill) exclusive control over certain administrative functions, specifically transferOwnership and renounceOwnership. While the prefill indicates a multisig, the contract itself does not enforce this, relying on external operational security. This centralization introduces a single point of control for critical administrative actions.
While a multisig is used, consider implementing a timelock for ownership transfers to provide a delay for users to react to potentially malicious or accidental changes. For increased decentralization, explore migrating ownership to a community-governed DAO.
Unresolved
The BlueWhaleToken contract does not include a pause mechanism. In the event of a critical vulnerability in the token itself, or in a protocol integrating the token, there is no way to halt transfers or other token operations. This could lead to irreversible loss of funds or exploitation before a fix can be deployed.
Consider implementing a Pausable mechanism (e.g., from OpenZeppelin) to allow the owner (or a designated role) to temporarily halt token transfers in emergencies. This feature should be used judiciously and ideally controlled by a multisig or governance.
Unresolved
initialSupply of tokens is minted to the contract deployer's address during construction. While this is a common pattern for token launches, it means the deployer initially holds 100% of the token supply. This concentration of tokens in a single address could lead to significant selling pressure if not managed carefully, potentially impacting market stability or perceived decentralization.L-03The entire initialSupply of tokens is minted to the contract deployer's address during construction. While this is a common pattern for token launches, it means the deployer initially holds 100% of the token supply. This concentration of tokens in a single address could lead to significant selling pressure if not managed carefully, potentially impacting market stability or perceived decentralization.
Ensure a clear and transparent distribution plan for the initial supply is communicated to the community. Consider distributing a portion of the initial supply to multiple addresses or vesting contracts from the outset to promote broader distribution and mitigate centralization concerns.
Unresolved
decimals() function in the ERC20 contract is hardcoded to return 18. While 18 is the most common decimal value for ERC20 tokens, it is a fixed design choice. This is not a vulnerability but a design characteristic that cannot be changed post-deployment.I-01The decimals() function in the ERC20 contract is hardcoded to return 18. While 18 is the most common decimal value for ERC20 tokens, it is a fixed design choice. This is not a vulnerability but a design characteristic that cannot be changed post-deployment.
No action required, as this is a standard and widely accepted design choice for ERC20 tokens. Ensure all integrations and user interfaces correctly interpret the token's 18 decimals.
Unresolved
The BlueWhaleToken contract is a standard ERC20 implementation leveraging battle-tested OpenZeppelin libraries. It includes basic ownership controls and mints an initial supply to the deployer. The contract is simple and does not introduce complex logic, contributing to its low technical risk. Several minor design considerations and centralization points were identified, but no critical or high-severity vulnerabilities were found.
The BlueWhaleToken contract is a straightforward ERC20 implementation, inheriting from OpenZeppelin's highly audited ERC20 and Ownable contracts. This significantly reduces the likelihood of technical vulnerabilities (7.2 Code Security). The architecture (7.1 Architecture) is simple and well-understood, with no complex external interactions (7.6 External) or novel logic introduced, minimizing the attack surface. The use of Solidity 0.8+ provides default overflow/underflow protection, further enhancing code security.
The contract's economic model (7.4 Economic) is a standard fixed-supply ERC20 token with an initial mint to the deployer. Governance (7.5 Governance) is centralized via the Ownable pattern, allowing the owner (a multisig in this case, as per prefill) to transfer or renounce ownership. While centralized, the use of a multisig for ownership mitigates some single-point-of-failure risks. There is no mechanism for post-deployment minting or burning by the owner, ensuring a fixed supply after initial deployment.
The BlueWhaleToken contract is not designed to be upgradeable (7.7 Upgrades), as it does not implement any proxy patterns. This eliminates risks specifically associated with upgradeability, such as proxy misconfigurations or logic errors during upgrades. Any changes to the token's logic would require a new deployment and migration, which is a known operational consideration (7.8 Operations).
Ensure the private keys for the multisig owner are securely managed and distributed among trusted parties to prevent unauthorized access.
Consider implementing a timelock for critical ownership actions if the project's decentralization goals evolve. For future contracts, evaluate the need for a pause mechanism to handle unforeseen emergencies or integrate with a governance module for broader community control.
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.
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
