Is B3 Safe? Smart Contract Security Analysis

Security Findings

1 Med1 Low

Medium

Conditional Initial Supply Minting Based on Chain ID

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)

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

FixClearly 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…

StatusUnresolved

Low

Hardcoded Critical Addresses

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)

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

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

StatusUnresolved

Category Ratings

TechnicalLow8/10

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.

GovernanceMedium4/10

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

UpgradesHigh3/10

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.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Holder Composition

62.2% in top 10

6.8% in wallets55.4% in contracts

Effective Concentration28.9%

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

$555.5K across 12 pairs

AerodromeWETHanalysed$543.3K Alien-baseWETH$10.9K Alien-base V3WETH$1.1K Uniswap v3WETH$145 Uniswap v4ETH$27 Uniswap v4LINK$9

Show 4 more pairsShow less

AerodromeUSDC$8 SushiswapWETH$2 AerodromeAERO$1 PancakeswapWETH$0

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

Top-1 Unlocked Holder43.4%

Top-3 Unlocked98.9%

Key Addresses

6 addresses

Deployer

0x8d91…a455

Unlocked LP Held By

0xfa2b…52bb0x375f…94910x7234…dece0x5c3b…25af0xb111…055c

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

7 factors

Ownership status UNKNOWN (owner could not be resolved)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 20% (62.2% total → 28.9% effective; 6.8% in EOAs, 55.4% in contracts — mild)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top3 unlocked holders = 98.9% (independent LP — depth risk, pool = 98% of DEX liquidity)
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 B3 Safe?