The Beat Token contract is a standard ERC20 implementation with an owner-controlled minting function. Based on the provided deployment information, the contract's ownership has been renounced, effectively disabling the minting capability and fixing the total supply at its current level. The contract utilizes Solidity 0.8.0+, benefiting from native overflow/underflow protection.

On-chain security analysis — is it a scam or legit?
Is Beat Token Safe?
Not 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 Beat Token contract is a standard ERC20 implementation with an owner-controlled minting function.
Read the full analysis- Mintable supply — no cap found, dilution unbounded
- Top-10 concentration > 20%
- LP lock status UNKNOWN — the pool's LP could not be read
- 1 Low finding(s) from audit
Exact factors
- Mintable supply — no cap found, dilution unbounded
- Top-10 concentration > 20% (57.4% total → 29.4% effective; 10.7% in EOAs, 46.7% in contracts — mild)
- LP lock status UNKNOWN — the pool's LP could not be read
- 1 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 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking46.7%
- Walletsanonymous holders, free to sell10.7%
- Everyone elsethe rest of the supply42.6%
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 4, 2026
Liquidity
as of audit · Sep 4- UniswapUSDTAnalysed$69.9K81.2%
- UniswapLUCKY$14.0K16.3%
- Pancakeswap v2WBNB$1.6K1.8%
- UniswapUSDT$5070.6%
- Pancakeswap v3USDT$840.1%
- Pancakeswap v3JPF$120.0%
The risk score reads depth across every pair.
Whether the LP tokens are locked could not be determined.
Security Findings
LowLack of Public Burn Mechanism
The Beat token contract does not expose a public function to allow token holders or the contract owner to burn tokens. While an internal _burn function exists in the inherited ERC20 contract, it is not callable externally. This limits the flexibility of supply management, as tokens can only be minted (up to MAX_SUPPLY before ownership renunciation) and transferred, but never permanently removed from circulation.L-01
Issue
The Beat token contract does not expose a public function to allow token holders or the contract owner to burn tokens. While an internal _burn function exists in the inherited ERC20 contract, it is not callable externally. This limits the flexibility of supply management, as tokens can only be minted (up to MAX_SUPPLY before ownership renunciation) and transferred, but never permanently removed from circulation.
Fix
Consider adding an onlyOwner or public burn function if future supply reduction mechanisms are desired. Document the current fixed supply policy clearly.
Status
Unresolved
InfoRedundant SafeMath Library Usage
The Beat.sol contract imports and uses the SafeMath library. However, the contract is compiled with Solidity ^0.8.0, which includes built-in overflow and underflow checks for all arithmetic operations by default. Explicitly using SafeMath for uint256 operations is redundant and adds unnecessary code complexity without providing additional security benefits in this Solidity version.I-01
Issue
The Beat.sol contract imports and uses the SafeMath library. However, the contract is compiled with Solidity ^0.8.0, which includes built-in overflow and underflow checks for all arithmetic operations by default. Explicitly using SafeMath for uint256 operations is redundant and adds unnecessary code complexity without providing additional security benefits in this Solidity version.
Fix
Remove the SafeMath.sol import and the using SafeMath for uint256; statement. Rely on Solidity 0.8.0's native overflow/underflow protection.
Status
Unresolved
InfoCentralized Initial Token Supply
The Beat token contract includes an onlyOwner mint function, allowing the deployer to mint tokens up to a MAX_SUPPLY of 1 billion tokens. While the provided information indicates that ownership has been renounced, implying the mint function is no longer callable, the initial distribution of tokens (if any occurred before renunciation) was entirely at the discretion of the contract owner. This represents a centralized point of control for the initial token supply.I-02
Issue
The Beat token contract includes an onlyOwner mint function, allowing the deployer to mint tokens up to a MAX_SUPPLY of 1 billion tokens. While the provided information indicates that ownership has been renounced, implying the mint function is no longer callable, the initial distribution of tokens (if any occurred before renunciation) was entirely at the discretion of the contract owner. This represents a centralized point of control for the initial token supply.
Fix
For future projects, consider implementing decentralized distribution mechanisms or transparent vesting schedules to reduce reliance on a single entity for initial token allocation.
Status
Unresolved
InfoUnchecked Arithmetic Blocks
The ERC20.sol contract utilizes unchecked blocks in the transferFrom, decreaseAllowance, and _burn functions. While these unchecked blocks are preceded by require statements that ensure the safety of the arithmetic operations (e.g., currentAllowance >= amount), their explicit use can be confusing. In Solidity 0.8.0+, arithmetic operations revert on overflow/underflow by default, making unchecked blocks only necessary when intentionally allowing such behavior.I-03
Issue
The ERC20.sol contract utilizes unchecked blocks in the transferFrom, decreaseAllowance, and _burn functions. While these unchecked blocks are preceded by require statements that ensure the safety of the arithmetic operations (e.g., currentAllowance >= amount), their explicit use can be confusing. In Solidity 0.8.0+, arithmetic operations revert on overflow/underflow by default, making unchecked blocks only necessary when intentionally allowing such behavior.
Fix
Review the necessity of unchecked blocks. If the preceding require statements guarantee safety, the unchecked blocks can be removed, relying on the default 0.8.0 behavior for clarity, or retained if the intent is to explicitly optimize gas by skipping redundant checks. Ensure thorough documentation of the rationale if retained.
Status
Unresolved
Analysis
AI Copilotas of audit · Sep 4The technical architecture is straightforward, implementing a standard ERC20 token with an Ownable pattern (7.1 Architecture). The code benefits from Solidity 0.8.0's built-in arithmetic safety checks. However, the explicit use of the SafeMath library is redundant given the compiler version (7.2 Code Security). Additionally, some unchecked blocks are used in ERC20.sol, though they are appropriately guarded by require statements (7.2 Code Security).
The economic model is based on a fixed maximum supply of 1 billion tokens, with an owner-controlled minting function (7.4 Economic). Crucially, the provided deployment information indicates that ownership has been renounced, which effectively disables further minting and fixes the total supply (7.5 Governance). The absence of a public burn function means the token supply cannot be reduced post-renunciation (7.4 Economic).
The contract is not designed with an upgradeability pattern (7.7 Upgrades). This means its logic is immutable once deployed, providing certainty but preventing future modifications or bug fixes without a new deployment and migration. This design choice inherently carries a low risk for upgrade-related issues.
It is recommended to remove the redundant SafeMath library usage to streamline the codebase and align with Solidity 0.8.0+ best practices.
Thoroughly document the implications of renounced ownership, particularly regarding the fixed token supply and the inability to mint or burn tokens. Ensure all operational procedures related to the token's lifecycle are clearly defined and communicated.
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.
- Aug 11, 202632Low
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Frequently Asked Questions
What is the BEAT contract address?
The Beat Token (BEAT) contract on BNB Chain is 0xcf3232b85b43bca90e51d38cc06cc8bb8c8a3e36. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Is Beat Token a scam?
Quantum Audit's risk score for Beat Token is 32/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: Mintable; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Who holds BEAT?
As of Sep 4, 2026, the 10 largest holders own 57.4% of the supply. The Holders section on this page shows who they are by holder type.
Would You Like a More Detailed Audit of Beat 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