Quantum Audit Logo

Is Bluzelle Token Safe?

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

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

Bluzelle Token BLZ
0x5732…d668
Ethereum Not verifiedLast checked 1d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The Bluzelle Token contract implements a standard ERC-20 token with additional access control mechanisms and a finalization state. Key features include a two-step ownership transfer, an operational address, and a pre-finalization phase where token transfers are restricted to owner/ops. The contract utilizes a custom SafeMath library for arithmetic operations. While the core ERC-20 functionality is present, the audit identified several areas for improvement, including the use of an outdated Solidity compiler, significant centralization risk before finalization, and standard ERC-20 vulnerabilities like the `approve()` race condition. The contract's design provides robust access control post-finalization but introduces high centralization risk during its initial phase.

2 High3 Medium2 Low1 Informational
Volume 24h
$225.5K
Liquidity
$208.0K
Price
$0.01234
Token Age
5y
Top 10 Holders
75.0%

Security Findings

2 High3 Med2 Low1 Info
High

Outdated Solidity Compiler Version

H-01The contract uses Solidity `^0.4.18`, which is an extremely old version. Newer compiler versions (e.g., 0.8.x) include critical bug fixes, security enhancements (like default overflow/underflow checks), and gas optimizations that are absent in older versions. Using an outdated compiler increases the risk of undiscovered vulnerabilities and makes the code harder to maintain and integrate with modern tooling.
IssueThe contract uses Solidity `^0.4.18`, which is an extremely old version. Newer compiler versions (e.g., 0.8.x) include critical bug fixes, security enhancements (like default overflow/underflow checks), and gas optimizations that are absent in older versions. Using an outdated compiler increases the risk of undiscovered vulnerabilities and makes the code harder to maintain and integrate with modern tooling.
FixUpgrade the Solidity compiler version to a recent stable release (e.g., 0.8.x). This will require careful testing and potentially minor code adjustments to ensure compatibility and leverage new features. A full re-audit should be performed after the upgrade.
StatusUnresolved
High

Centralized Control Over Transfers Before Finalization

H-02The `validateTransfer` function, active before the `finalize()` function is called, restricts all token transfers such that only the `owner` or `opsAddress` can initiate transfers, unless the recipient is the `owner`. This grants significant centralized control over token movement, posing a high risk if the owner's or ops address's private key is compromised or if the owner acts maliciously. This central point of control could lead to a denial of service for token holders or unauthorized censorship of transfers.
IssueThe `validateTransfer` function, active before the `finalize()` function is called, restricts all token transfers such that only the `owner` or `opsAddress` can initiate transfers, unless the recipient is the `owner`. This grants significant centralized control over token movement, posing a high risk if the owner's or ops address's private key is compromised or if the owner acts maliciously. This central point of control could lead to a denial of service for token holders or unauthorized censorship of transfers.
FixClearly document this centralized control phase and its implications for token holders. Consider implementing a multi-signature wallet for the `owner` and `opsAddress` to distribute control and reduce the risk of a single point of failure. Ensure a robust process for the `finalize()` call to transition to a decentralized transfer state.
StatusUnresolved
Medium

ERC-20 `approve()` Race Condition Vulnerability

M-01The standard ERC-20 `approve()` function is susceptible to a known front-running attack. If a user increases an allowance for a spender, an attacker can front-run the transaction, spend the original allowance, and then the user's new allowance transaction will grant the attacker an additional allowance, effectively doubling the intended allowance. This can lead to unintended token loss if not handled carefully by users.
IssueThe standard ERC-20 `approve()` function is susceptible to a known front-running attack. If a user increases an allowance for a spender, an attacker can front-run the transaction, spend the original allowance, and then the user's new allowance transaction will grant the attacker an additional allowance, effectively doubling the intended allowance. This can lead to unintended token loss if not handled carefully by users.
FixAdvise users to always set an allowance to zero before increasing it. Alternatively, implement `increaseAllowance()` and `decreaseAllowance()` functions, which are safer alternatives to directly setting allowances and mitigate this race condition.
StatusUnresolved
Medium

Missing Zero-Address Check in `approve()`

M-02The `approve` function allows setting an allowance for `address(0)`. While not directly exploitable for token theft, approving the zero address could lead to tokens being permanently inaccessible by the intended spender if this address is used by mistake, as `address(0)` cannot execute transactions. This could result in a loss of functionality or perceived token loss.
IssueThe `approve` function allows setting an allowance for `address(0)`. While not directly exploitable for token theft, approving the zero address could lead to tokens being permanently inaccessible by the intended spender if this address is used by mistake, as `address(0)` cannot execute transactions. This could result in a loss of functionality or perceived token loss.
FixAdd a `require(_spender != address(0))` check within the `approve` function to prevent accidental approval of the zero address.
StatusUnresolved
Medium

Unprotected Division in `Math.div()`

M-03The `Math` library's `div` function does not include a check to prevent division by zero. Although this specific `div` function is not directly called in the token's core logic in a way that would immediately cause a critical issue (it's used in `mul` for a check), it represents an incomplete safe math implementation and could lead to runtime errors if used elsewhere or if the `mul` check logic changes.
IssueThe `Math` library's `div` function does not include a check to prevent division by zero. Although this specific `div` function is not directly called in the token's core logic in a way that would immediately cause a critical issue (it's used in `mul` for a check), it represents an incomplete safe math implementation and could lead to runtime errors if used elsewhere or if the `mul` check logic changes.
FixAdd a `require(b != 0)` check at the beginning of the `div` function in the `Math` library to ensure robust safe math operations.
StatusUnresolved
Low

Lack of `increaseAllowance()` and `decreaseAllowance()`

L-01The contract implements the basic `approve()` function but lacks the safer `increaseAllowance()` and `decreaseAllowance()` functions. These functions are considered best practice in modern ERC-20 implementations as they allow atomic adjustments to allowances, reducing the risk associated with the `approve()` race condition.
IssueThe contract implements the basic `approve()` function but lacks the safer `increaseAllowance()` and `decreaseAllowance()` functions. These functions are considered best practice in modern ERC-20 implementations as they allow atomic adjustments to allowances, reducing the risk associated with the `approve()` race condition.
FixConsider adding `increaseAllowance()` and `decreaseAllowance()` functions to provide a safer and more user-friendly way to manage token allowances.
StatusUnresolved
Low

Owner Can Reclaim All Contract-Held Tokens

L-02The `reclaimTokens()` function allows the contract owner to transfer all tokens held by the `BluzelleToken` contract itself to the owner's address. While potentially intended for recovery or specific operational needs, this function could be misused if the contract is ever intended to hold tokens for other purposes (e.g., as part of a liquidity pool or escrow), leading to a loss of funds for those purposes.
IssueThe `reclaimTokens()` function allows the contract owner to transfer all tokens held by the `BluzelleToken` contract itself to the owner's address. While potentially intended for recovery or specific operational needs, this function could be misused if the contract is ever intended to hold tokens for other purposes (e.g., as part of a liquidity pool or escrow), leading to a loss of funds for those purposes.
FixEnsure that the purpose and implications of the `reclaimTokens` function are clearly documented. If the contract is intended to hold tokens for specific functionalities, consider removing or restricting this function, or implementing a more granular withdrawal mechanism.
StatusUnresolved
Info

Redundant Check in `cancelOwnershipTransfer()`

I-01The `cancelOwnershipTransfer()` function includes an `if (proposedOwner == address(0))` check before setting `proposedOwner = address(0)`. This check is redundant as the variable is set to `address(0)` regardless, adding unnecessary complexity without functional benefit.
IssueThe `cancelOwnershipTransfer()` function includes an `if (proposedOwner == address(0))` check before setting `proposedOwner = address(0)`. This check is redundant as the variable is set to `address(0)` regardless, adding unnecessary complexity without functional benefit.
FixRemove the `if (proposedOwner == address(0))` condition, as `proposedOwner = address(0)` can be executed unconditionally.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The technical implementation (7.2 Code Security) benefits from a custom `Math` library to prevent integer overflows/underflows, which is a strong security practice for arithmetic operations. The contract also includes a well-defined two-step ownership transfer mechanism in `Owned.sol`. However, the use of Solidity `^0.4.18` (7.1 Architecture) is a significant technical debt, as this version lacks modern security features and optimizations. Additionally, the `Math.div` function (7.2 Code Security) does not include a zero-divisor check, which is an oversight in the safe math implementation.

GovernanceHigh1/10

The contract exhibits a high degree of centralization (7.3 Access Control, 7.4 Economic) during its initial, non-finalized phase. Before `finalize()` is called, only the owner or ops address can initiate token transfers, unless the recipient is the owner, giving significant control to a single entity. This poses a substantial risk if the controlling keys are compromised. The `reclaimTokens` function (7.4 Economic) also allows the owner to unilaterally withdraw all tokens held by the contract, which could be problematic if the contract is intended to hold tokens for other purposes. Post-finalization, the token operates as a standard ERC-20, decentralizing transfer control.

UpgradesMedium4/10

This contract is not designed as an upgradeable proxy (7.7 Upgrades), so traditional upgrade safety concerns do not apply. However, the `finalized` state acts as a one-way, irreversible state transition, altering the token's transfer mechanics from restricted to unrestricted. This mechanism is clearly defined and controlled by the owner, providing a predictable lifecycle for the token's operational phase.

Security Checklist

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

Holder Composition

75.0% in top 10
66.5% in wallets8.4% in contracts
Effective Concentration69.9%

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

$415.0K across 5 pairs
Uniswap v2USDCanalysed$208.0K50.1%Uniswap v2WETH$206.5K49.8%Uniswap v2WBTC$4600.1%Uniswap v3USDC$00.0%

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 Holder90.5%
Top-3 Unlocked99.1%

Key Addresses

7 addresses
Deployer
0x004a…18ff
Unlocked LP Held By
0xe963…239f0xa0fd…abb30x3ca5…2c0e0xd9c5…b49a0xf7c9…809f0x7637…c02d

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

What Raised This Score

8 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Top-10 concentration > 50% (75.0% total → 69.9% effective; 66.5% in EOAs, 8.4% in contracts — heavy)
  • LP top1 unlocked holder = 90.5% (independent LP — depth risk, pool = 50% of DEX liquidity)
  • LP top3 unlocked holders = 99.1% (independent LP — depth risk, pool = 50% of DEX liquidity)
  • LP claimed locked but only 0.0% actually locked
  • 2 High finding(s) from audit
  • 3 Medium finding(s) from audit
  • 2 Low 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
Caldera (ERA)Critical RiskAllora (ALLO)Critical RiskusocksCritical RiskCOTICritical Riskdmt-natCritical RiskPunkStrategy (PNKSTR)Critical Risk

Would You Like a More Detailed Audit of Bluzelle Token?

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

Get Detailed Audit