On-chain security analysis — is it a scam or legit?
The B3Token contract implements a standard ERC20 token with OpenZeppelin extensions for permit, votes, and access control.
Read the full analysisEach 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
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
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0xfa2b…52bb0x375f…94910x7234…dece0x5c3b…25af0xb111…055cNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
if (block.chainid == BASE_CHAIN_ID) to mint the entire MAX_SUPPLY to _DEPLOYER_ADDRESS. If the contract is deployed on a chain other than BASE_CHAIN_ID (8453), this initial minting will not occur. In such a scenario, the MINTER_ROLE would then be able to mint up to the MAX_SUPPLY to any address, effectively controlling the entire initial distribution. This behavior, while potentially intentional, significantly alters the token's initial supply dynamics based on the deployment environment and could lead to unexpected or undesirable distribution if not fully understood and managed. (7.4 Economic, 7.8 Operations)M-01The contract's constructor includes a conditional statement if (block.chainid == BASE_CHAIN_ID) to mint the entire MAX_SUPPLY to _DEPLOYER_ADDRESS. If the contract is deployed on a chain other than BASE_CHAIN_ID (8453), this initial minting will not occur. In such a scenario, the MINTER_ROLE would then be able to mint up to the MAX_SUPPLY to any address, effectively controlling the entire initial distribution. This behavior, while potentially intentional, significantly alters the token's initial supply dynamics based on the deployment environment and could lead to unexpected or undesirable distribution if not fully understood and managed. (7.4 Economic, 7.8 Operations)
Clearly document the intended deployment strategy and the implications of deploying on chains other than BASE_CHAIN_ID. If the token is strictly intended for Base with a fixed initial distribution, consider adding a require(block.chainid == BASE_CHAIN_ID) in the constructor to prevent accidental deployment on other chains without the intended initial mint. If multi-chain deployment with varied initial distribution is intended, ensure the MINTER_ROLE is appropriately secured and its initia…
Unresolved
_OWNER_ADDRESS (assigned DEFAULT_ADMIN_ROLE) and _DEPLOYER_ADDRESS (recipient of initial supply on Base) are defined as internal constant variables. This means these addresses are fixed at deployment and cannot be changed or updated after the contract is live. While common for initial setup, it introduces a single point of failure: if the private keys for these addresses are lost or compromised, the administrative control (DEFAULT_ADMIN_ROLE) and the initial token holdings (_DEPLOYER_ADDRESS) become permanently inaccessible or vulnerable. (7.3 Access Control, 7.8 Operations)L-01The _OWNER_ADDRESS (assigned DEFAULT_ADMIN_ROLE) and _DEPLOYER_ADDRESS (recipient of initial supply on Base) are defined as internal constant variables. This means these addresses are fixed at deployment and cannot be changed or updated after the contract is live. While common for initial setup, it introduces a single point of failure: if the private keys for these addresses are lost or compromised, the administrative control (DEFAULT_ADMIN_ROLE) and the initial token holdings (_DEPLOYER_ADDRESS) become permanently inaccessible or vulnerable. (7.3 Access Control, 7.8 Operations)
For long-term operational security, consider using a proxy pattern or a mechanism to allow the DEFAULT_ADMIN_ROLE to be transferred to a new address (e.g., a multi-signature wallet or a governance contract). If hardcoding is desired, ensure that the private keys associated with _OWNER_ADDRESS and _DEPLOYER_ADDRESS are secured with the highest level of protection (e.g., hardware wallets, multi-sig setups) and that robust recovery procedures are in place.
Unresolved
The B3Token contract implements a standard ERC20 token with OpenZeppelin extensions for permit, votes, and access control. The contract defines a fixed maximum supply and specific roles for minting and administration. Key design choices include chain-ID dependent initial minting and hardcoded owner/deployer addresses. The overall technical implementation is robust, leveraging well-audited libraries.
The B3Token contract utilizes well-audited OpenZeppelin libraries for its ERC20, ERC20Permit, ERC20Votes, and AccessControl implementations, contributing to a robust foundation (7.1 Architecture, 7.2 Code Security). The burnFrom function correctly handles allowance checks before an unchecked block, preventing underflow. Access control roles (DEFAULT_ADMIN_ROLE, MINTER_ROLE) are clearly defined and enforced for sensitive operations like minting and burning (7.3 Access Control). No reentrancy or integer overflow/underflow vulnerabilities were identified.
The contract establishes a MAX_SUPPLY of 100 billion tokens, enforced by the ERC20Votes extension, preventing over-minting (7.4 Economic). The DEFAULT_ADMIN_ROLE is assigned to a hardcoded _OWNER_ADDRESS, centralizing administrative control (7.5 Governance). A significant design decision is the conditional initial minting of the entire supply to _DEPLOYER_ADDRESS only if deployed on the BASE_CHAIN_ID. If deployed on other chains, the MINTER_ROLE would control the initial distribution up to MAX_SUPPLY, which could lead to unexpected tokenomics if not explicitly intended (7.4 Economic, 7.8 Operations).
The B3Token contract is not designed with an upgrade mechanism (e.g., proxy pattern). This simplifies its architecture by removing upgrade-related complexities and risks (7.7 Upgrades). Any future changes to the contract logic would require a new deployment and migration of assets, which is a standard approach for non-upgradeable tokens.
Ensure the _OWNER_ADDRESS and _DEPLOYER_ADDRESS are secured with robust multi-signature wallets or hardware security modules, given their hardcoded nature and critical roles.
Explicitly document and confirm the intended behavior of the chain-ID dependent initial minting, especially regarding deployments on non-Base chains, to prevent misinterpretations of token distribution. If multi-chain deployment is intended, clearly define the initial distribution strategy for each chain.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Based on automated analysis, B3 scores 63/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.
Our scanner flagged a risk score of 63/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.
The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.
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
