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.
On-chain security analysis — is it a scam or legit?
Is Bluzelle Token Safe?
EthereumNot verified
This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →The Bluzelle Token contract implements a standard ERC-20 token with additional access control mechanisms and a finalization state.
Read the full analysis- Ownership not renounced — owner is an EOA
- Top-10 concentration > 50%
- LP top1 unlocked holder = 90.5%
- LP top3 unlocked holders = 99.1%
- 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
Exact 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
Security Checklist
as of audit · Sep 5Holders
as of audit · Sep 5, 2026- Contractstreasury, vesting, bridge, staking8.4%
- Walletsanonymous holders, free to sell66.5%
- Everyone elsethe rest of the supply25.0%
How holder types affect the score
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 5, 2026
Liquidity
as of audit · Sep 5- 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 LP tokens of the analysed pool are locked or burned.
0xe963…239f0xa0fd…abb30x3ca5…2c0e0xd9c5…b49a0xf7c9…809f0x7637…c02dNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
HighOutdated Solidity Compiler Version
The 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.H-01
Issue
The 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.
Fix
Upgrade 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.
Status
Unresolved
HighCentralized Control Over Transfers Before Finalization
The 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.H-02
Issue
The 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.
Fix
Clearly 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.
Status
Unresolved
MediumERC-20 approve() Race Condition Vulnerability
The 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.M-01
approve() Race Condition VulnerabilityIssue
The 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.
Fix
Advise 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.
Status
Unresolved
MediumMissing Zero-Address Check in approve()
The 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.M-02
approve()Issue
The 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.
Fix
Add a require(_spender != address(0)) check within the approve function to prevent accidental approval of the zero address.
Status
Unresolved
MediumUnprotected Division in Math.div()
The 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.M-03
Math.div()Issue
The 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.
Fix
Add a require(b != 0) check at the beginning of the div function in the Math library to ensure robust safe math operations.
Status
Unresolved
LowLack of increaseAllowance() and decreaseAllowance()
The 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.L-01
increaseAllowance() and decreaseAllowance()Issue
The 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.
Fix
Consider adding increaseAllowance() and decreaseAllowance() functions to provide a safer and more user-friendly way to manage token allowances.
Status
Unresolved
LowOwner Can Reclaim All Contract-Held Tokens
The 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.L-02
Issue
The 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.
Fix
Ensure 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.
Status
Unresolved
InfoRedundant Check in cancelOwnershipTransfer()
The 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.I-01
cancelOwnershipTransfer()Issue
The 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.
Fix
Remove the if (proposedOwner == address(0)) condition, as proposedOwner = address(0) can be executed unconditionally.
Status
Unresolved
Analysis
AI Copilotas of audit · Sep 5The 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.
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.
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.
It is strongly recommended to migrate the contract to a modern Solidity compiler version (e.g., 0.8.x) to benefit from enhanced security features, gas optimizations, and bug fixes.
This migration should be accompanied by a thorough re-audit. Address the centralization risk during the pre-finalization phase by clearly communicating this operational model to users and considering multi-signature wallets for owner/ops addresses. Implement increaseAllowance() and decreaseAllowance() functions to mitigate the approve() race condition and enhance user safety.
Contract & Record
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- Sep 5, 202690Critical
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
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 Is this your token? Publish your own audit on this page