Is BEM Safe? Smart Contract Security Analysis

Security Findings

1 Med1 Low2 Info

Medium

Centralized Minter Role

M-01The `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)

IssueThe `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)

FixConsider 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.

StatusUnresolved

Low

Minter Key Management Considerations

L-01If 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)

IssueIf 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)

FixIt 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.

StatusUnresolved

Info

Non-Standard Decimals

I-01The `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)

IssueThe `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)

FixEnsure 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.

StatusUnresolved

Info

Fixed Supply and Immutability

I-02The 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)

IssueThe 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)

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

StatusUnresolved

Category Ratings

TechnicalLow8/10

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.

GovernanceMedium6/10

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).

UpgradesMedium4/10

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.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedPass

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

17.8% in top 10

9.5% in wallets8.3% in contracts

Effective Concentration12.8%

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

$121.9K across 6 pairs

Pancakeswap v3USDTanalysed$62.3K Pancakeswap v3USDT$48.7K Pancakeswap v3WBNB$10.8K Pancakeswap v2wGENENAND$95 Pancakeswap v3USDT$45

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

LP Burned99.0% · ≈ permanent lock

LP Locked99.0% · Dead Address

Key Addresses

9 addresses

Deployer

0x571d…af15

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.

What Raised This Score

5 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

Is BEM Safe?

Security Findings

Centralized Minter Role

Minter Key Management Considerations

Non-Standard Decimals

Fixed Supply and Immutability

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of BEM?