Quantum Audit Logo
Launch App

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

Is BEM Safe?

BNB Chain
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 →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance6/10Upgrades4/10Checks passed5 of 7Findings1 Medium · 1 Low · 2 Info4
SummaryAI Copilot

The PodToken contract is an ERC-20 token implementation based on OpenZeppelin's battle-tested libraries.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Token age < 30 days
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Token age < 30 days (still settling)
  • 1 Medium finding(s) from audit
  • 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 45 of 7 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockLocked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
8.3%Contracts9.5%Wallets82.2%Everyone else
8.3%9.5%82.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
17.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking8.3%
  • Walletsanonymous holders, free to sell9.5%
  • Everyone elsethe rest of the supply82.2%
Effective concentrationwhat the score reads12.8%
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$121.9K across 6 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$62.3KShare of depth51.1%
LP Burned99.0% · ≈ permanent lock
LP Locked99.0% · Dead Address
Unlocked LP held by
0x1368…88880x6375…6a980x6eb0…438e0xf178…0fd20x571d…af150xfec8…e9230x9b82…81c60x5f99…e5ac

A privileged address — the deployer, the owner, or the token contract itself — is among these holders, so that party can withdraw liquidity.

Security Findings

1 Medium1 Low2 Info
Medium

Centralized Minter Role

The minter address, set during contract deployment, has exclusive control over the mint function. This allows the minter to issue new tokens up to the MAX_SUPPLY (21,000,000 tokens with 8 decimals). This centralized control introduces a single point of failure; if the minter's private key is compromised or if the minter acts maliciously, the entire remaining supply could be minted and potentially dumped, impacting token value and user trust. (7.3 Access Control, 7.4 Economic)M-01

Issue

The minter address, set during contract deployment, has exclusive control over the mint function. This allows the minter to issue new tokens up to the MAX_SUPPLY (21,000,000 tokens with 8 decimals). This centralized control introduces a single point of failure; if the minter's private key is compromised or if the minter acts maliciously, the entire remaining supply could be minted and potentially dumped, impacting token value and user trust. (7.3 Access Control, 7.4 Economic)

Fix

Consider implementing a multi-signature wallet (e.g., Gnosis Safe) or a time-locked contract for the minter role. This would require multiple approvals or introduce a delay for minting operations, significantly reducing the risk associated with a single compromised key or malicious actor. Alternatively, if the minter is intended to be a DAO, ensure the DAO's governance is robust.

Status

Unresolved

Low

Minter Key Management Considerations

If the minter address is an Externally Owned Account (EOA), it is inherently susceptible to private key compromise through phishing, malware, or poor key management practices. While the contract's logic is secure, the operational security of the minter's private key is critical to the overall security of the token supply. (7.8 Operations)L-01

Issue

If the minter address is an Externally Owned Account (EOA), it is inherently susceptible to private key compromise through phishing, malware, or poor key management practices. While the contract's logic is secure, the operational security of the minter's private key is critical to the overall security of the token supply. (7.8 Operations)

Fix

It is strongly recommended that the minter address be controlled by a secure mechanism such as a hardware wallet, a multi-signature wallet, or a smart contract with robust access control and recovery features. Regular security audits and best practices for key management should be followed for the entity controlling the minter address.

Status

Unresolved

Info

Non-Standard Decimals

The PodToken contract explicitly sets DECIMALS to 8, overriding the default 18 used by many ERC-20 tokens and OpenZeppelin's base ERC20 contract. While this is a valid design choice and correctly implemented, it deviates from the common standard. This requires all interacting dApps, exchanges, and wallets to correctly interpret the token's decimal places to prevent display errors, incorrect calculations, or user confusion. (7.1 Architecture)I-01

Issue

The PodToken contract explicitly sets DECIMALS to 8, overriding the default 18 used by many ERC-20 tokens and OpenZeppelin's base ERC20 contract. While this is a valid design choice and correctly implemented, it deviates from the common standard. This requires all interacting dApps, exchanges, and wallets to correctly interpret the token's decimal places to prevent display errors, incorrect calculations, or user confusion. (7.1 Architecture)

Fix

Ensure that all documentation, user interfaces, and integrations clearly communicate and correctly handle the 8-decimal precision of the PodToken. Thoroughly test all external systems that interact with the token to confirm they correctly interpret and display token amounts.

Status

Unresolved

Info

Fixed Supply and Immutability

The PodToken contract is designed with a fixed MAX_SUPPLY of 21,000,000 tokens (with 8 decimals) and an immutable minter address set during construction. This design ensures that the total token supply cannot exceed a predefined limit and that the minting authority cannot be changed after deployment. This provides predictability and transparency regarding the token's economic model. (7.1 Architecture, 7.4 Economic)I-02

Issue

The PodToken contract is designed with a fixed MAX_SUPPLY of 21,000,000 tokens (with 8 decimals) and an immutable minter address set during construction. This design ensures that the total token supply cannot exceed a predefined limit and that the minting authority cannot be changed after deployment. This provides predictability and transparency regarding the token's economic model. (7.1 Architecture, 7.4 Economic)

Fix

No recommendation needed as this is a design feature. Maintain clear documentation of these immutable parameters for users and integrators.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The PodToken contract is an ERC-20 token implementation based on OpenZeppelin's battle-tested libraries. It features a fixed maximum supply and a single, immutable minter address responsible for issuing tokens up to this cap. The contract's logic is straightforward, primarily extending standard ERC-20 functionality with a controlled minting mechanism. While technically sound, the centralized minter role introduces a medium economic risk due to its significant control over token supply.

Technical8/10Low risk

The technical implementation of PodToken is robust, leveraging OpenZeppelin's ERC-20 standard for core token functionalities (7.2 Code Security). The contract's custom logic for minting is minimal and correctly implements access control, ensuring only the designated minter can issue new tokens (7.3 Access Control). The MAX_SUPPLY check prevents over-minting and potential integer overflows (7.2 Code Security). No complex external interactions or novel mechanisms were identified that could introduce reentrancy or other common technical vulnerabilities.

Governance6/10Medium risk

The primary economic consideration is the centralized control over token minting (7.4 Economic). The minter address holds exclusive power to issue tokens up to the MAX_SUPPLY, which is a significant authority. While the minter is immutable and the supply is capped, a compromise of this single address could lead to the full issuance of tokens by an unauthorized entity. The fixed MAX_SUPPLY provides predictability for tokenomics (7.4 Economic). There is no explicit governance mechanism within the contract (7.5 Governance).

Upgrades4/10Medium risk

The PodToken contract is not designed to be upgradeable (7.7 Upgrades). It is a standard, non-proxy implementation, meaning its logic is immutable once deployed. This eliminates any risks associated with upgrade mechanisms, such as proxy pattern vulnerabilities or upgrade path complexities.

Final RecommendationWhat to do about this score

It is recommended to implement robust operational security for the minter address, ideally using a multi-signature wallet or a time-locked contract to mitigate the risk of a single point of failure.

Ensure all integrations and user interfaces are aware of the 8-decimal standard to prevent display or calculation errors. Conduct thorough testing of any external systems interacting with the token to confirm correct handling of its specific decimal configuration.

Contract & Record

1 audit on record
TypePodToken
NetworkBNB Chain
Token age8d
Contract0x5ce0…695a
Deployer0x571d…af15
Badge for your website
BEM security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202618Low
  2. Aug 30, 202642Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the BEM contract address?

The BEM contract on BNB Chain is 0x5ce033b2bfca3af30b3e8c8457deaf776a8b695a. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is BEM a scam?

Quantum Audit's risk score for BEM is 18/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: Mintable; Liquidity lock: Locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is BEM liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $121.9K.

Who holds BEM?

As of Sep 4, 2026, the 10 largest holders own 17.8% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
BENBNB Chain18LowBREWBNB Chain18LowCZ Terminal TokenCZT · BNB Chain19LowDBURNBNB Chain17LowThe ChampCoinTCC · BNB Chain17LowEverlyn TokenLYN · BNB Chain19Low

Would You Like a More Detailed Audit of BEM?

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