The B2Token contract is an ERC-20 token leveraging battle-tested OpenZeppelin libraries for its core functionality, including burnable, permit, capped, pausable, and access control features. The contract exhibits a robust technical foundation with minimal custom logic. However, the design incorporates significant centralization through the DEFAULT_ADMIN_ROLE, which controls critical functions like pausing and role management. The MINTER_ROLE is defined but not initially assigned, requiring careful post-deployment management. The contract is not upgradeable, necessitating redeployment for any future modifications.

On-chain security analysis — is it a scam or legit?
Is BSquared 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 B2Token contract is an ERC-20 token leveraging battle-tested OpenZeppelin libraries for its core functionality, including burnable, permit, capped, pausable, and access control features.
Read the full analysis- Ownership status UNKNOWN
- Mintable supply, but capped at 1.2%/year
- Top-10 concentration > 30%
- Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
- LP top1 unlocked holder = 100.0%
- LP top3 unlocked holders = 100.0%
- 1 High finding(s) from audit
- 1 Medium finding(s) from audit
- 1 Low finding(s) from audit
Exact factors
- Ownership status UNKNOWN (owner could not be resolved)
- Mintable supply, but capped at 1.2%/year
- Top-10 concentration > 30% (74.6% total → 35.8% effective; 9.9% in EOAs, 64.6% in contracts — moderate)
- Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
- LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 100% of DEX liquidity)
- LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 100% of DEX liquidity)
- 1 High finding(s) from audit
- 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 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking64.6%
- Walletsanonymous holders, free to sell9.9%
- Everyone elsethe rest of the supply25.4%
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- Pancakeswap v3WBNBAnalysed$728.2K99.8%
- Pancakeswap v3USDT$4690.1%
- MdexUSDT$3980.1%
- Squadswap v2WBNB$2290.0%
- Pancakeswap v3USDT$750.0%
- Pancakeswap v2CAT$120.0%
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.
0x1730…27f60xa54b…5a000x6642…1a33No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
HighCentralized Control of Critical Functions
The DEFAULT_ADMIN_ROLE holds extensive power over the B2Token contract. This role, assigned to a single admin address in the constructor, can pause/unpause token transfers and grant/revoke any other role, including the MINTER_ROLE. This centralization creates a single point of failure; if the admin address is compromised, an attacker could halt all token operations, mint tokens up to the cap (by granting themselves the MINTER_ROLE), or manipulate access permissions, leading to severe economic and operational consequences (7.3 Access Control, 7.5 Governance, 7.8 Operations).H-01
Issue
The DEFAULT_ADMIN_ROLE holds extensive power over the B2Token contract. This role, assigned to a single admin address in the constructor, can pause/unpause token transfers and grant/revoke any other role, including the MINTER_ROLE. This centralization creates a single point of failure; if the admin address is compromised, an attacker could halt all token operations, mint tokens up to the cap (by granting themselves the MINTER_ROLE), or manipulate access permissions, leading to severe economic and operational consequences (7.3 Access Control, 7.5 Governance, 7.8 Operations).
Fix
Assign the DEFAULT_ADMIN_ROLE to a multi-signature wallet (e.g., Gnosis Safe) requiring multiple trusted parties to approve critical actions. This significantly reduces the risk associated with a single point of compromise and enhances the security and decentralization of control.
Status
Unresolved
MediumUnassigned MINTER_ROLE Post-Deployment
The MINTER_ROLE is defined in the B2Token contract, allowing authorized accounts to mint new tokens up to the ERC20Capped limit. However, this role is not granted to any address in the constructor. This means that immediately after deployment, no entity will be able to mint tokens. The DEFAULT_ADMIN_ROLE must explicitly grant the MINTER_ROLE to an address post-deployment for minting functionality to be enabled. If this step is overlooked or delayed, the token's supply mechanism will be non-functional (7.3 Access Control, 7.8 Operations).M-01
Issue
The MINTER_ROLE is defined in the B2Token contract, allowing authorized accounts to mint new tokens up to the ERC20Capped limit. However, this role is not granted to any address in the constructor. This means that immediately after deployment, no entity will be able to mint tokens. The DEFAULT_ADMIN_ROLE must explicitly grant the MINTER_ROLE to an address post-deployment for minting functionality to be enabled. If this step is overlooked or delayed, the token's supply mechanism will be non-functional (7.3 Access Control, 7.8 Operations).
Fix
Ensure a clear operational plan for granting the MINTER_ROLE immediately after deployment. Consider granting it to a multi-signature wallet or a dedicated, audited minting contract to enhance security. Document this crucial post-deployment step to avoid operational delays or errors.
Status
Unresolved
LowNo Emergency Renouncement for MINTER_ROLE
While the DEFAULT_ADMIN_ROLE can revoke the MINTER_ROLE, the MINTER_ROLE itself cannot be renounced by the account holding it. In a scenario where the MINTER_ROLE's private key is compromised, the compromised account cannot voluntarily relinquish the role to prevent further malicious minting. This means the DEFAULT_ADMIN_ROLE must be vigilant and act swiftly to revoke the role if a compromise is detected (7.3 Access Control).L-01
Issue
While the DEFAULT_ADMIN_ROLE can revoke the MINTER_ROLE, the MINTER_ROLE itself cannot be renounced by the account holding it. In a scenario where the MINTER_ROLE's private key is compromised, the compromised account cannot voluntarily relinquish the role to prevent further malicious minting. This means the DEFAULT_ADMIN_ROLE must be vigilant and act swiftly to revoke the role if a compromise is detected (7.3 Access Control).
Fix
While AccessControl's renounceRole function is typically for self-revocation, for critical roles like MINTER_ROLE, it's generally safer that the role cannot be renounced by the holder. The primary mitigation is to secure the MINTER_ROLE with a multi-signature wallet. If a single EOA is used, implement robust monitoring and an emergency response plan for the DEFAULT_ADMIN_ROLE to revoke the MINTER_ROLE if compromise is suspected.
Status
Unresolved
InfoImmutability / No Upgradeability
The B2Token contract is deployed as a standard, non-upgradeable contract. This means that once deployed, its logic cannot be modified. Any future bug fixes, feature enhancements, or changes to the token's parameters would necessitate deploying an entirely new contract and migrating existing token holders, which can be a complex, costly, and disruptive process (7.7 Upgrades).I-01
Issue
The B2Token contract is deployed as a standard, non-upgradeable contract. This means that once deployed, its logic cannot be modified. Any future bug fixes, feature enhancements, or changes to the token's parameters would necessitate deploying an entirely new contract and migrating existing token holders, which can be a complex, costly, and disruptive process (7.7 Upgrades).
Fix
For projects that anticipate future changes or require the flexibility to fix potential bugs, consider implementing an upgradeability pattern (e.g., UUPS or Transparent Proxy) in future contract designs. This allows for controlled and secure updates to the contract logic without requiring a token migration.
Status
Unresolved
InfoReliance on OpenZeppelin Libraries
The contract heavily relies on OpenZeppelin's battle-tested and widely used smart contract libraries (e.g., ERC20, AccessControl, ERC20Capped, ERC20Pausable). While this is a significant strength, reducing the likelihood of common vulnerabilities, it also means the contract inherits any potential, albeit unlikely, vulnerabilities discovered in these external dependencies (7.6 External).I-02
Issue
The contract heavily relies on OpenZeppelin's battle-tested and widely used smart contract libraries (e.g., ERC20, AccessControl, ERC20Capped, ERC20Pausable). While this is a significant strength, reducing the likelihood of common vulnerabilities, it also means the contract inherits any potential, albeit unlikely, vulnerabilities discovered in these external dependencies (7.6 External).
Fix
Continue to monitor OpenZeppelin's security advisories and updates. Ensure that the specific versions of OpenZeppelin contracts used are up-to-date and free from known vulnerabilities. This is a standard practice for projects leveraging external libraries.
Status
Unresolved
Analysis
AI Copilotas of audit · Sep 4The B2Token contract is built upon well-audited OpenZeppelin ERC-20 standards, incorporating extensions for burnability, permits, capping, pausing, and access control (7.1 Architecture). The custom logic is minimal, primarily consisting of role-based access for minting, pausing, and unpausing, which reduces the attack surface (7.2 Code Security). The _update function is correctly overridden to ensure proper behavior across multiple inherited ERC-20 extensions, demonstrating careful integration. The reliance on battle-tested libraries significantly enhances the technical security posture, minimizing common vulnerabilities like reentrancy or integer overflows.
The contract's governance and economic model are highly centralized, relying on the DEFAULT_ADMIN_ROLE for critical operations (7.5 Governance). This role, assigned to a single admin address in the constructor, has the power to pause/unpause the token and manage all other roles, including the MINTER_ROLE (7.3 Access Control). The MINTER_ROLE is responsible for issuing new tokens up to the defined cap of 210 million, posing a significant economic risk if compromised or misused (7.4 Economic). While the ERC20Capped mechanism limits total supply, the centralized control over minting and pausing functions introduces a single point of failure and potential for abuse if the DEFAULT_ADMIN_ROLE is compromised.
The B2Token contract is implemented as a standard, non-upgradeable contract (7.7 Upgrades). There is no proxy pattern or other mechanism built into the contract to facilitate future modifications or bug fixes without deploying an entirely new contract. Any necessary changes to the token's logic or parameters would require a complete redeployment and a migration strategy for existing token holders, which can be complex and disruptive. This design choice implies a high risk for future adaptability.
To mitigate the identified risks, it is strongly recommended to assign the DEFAULT_ADMIN_ROLE to a robust multi-signature wallet (e.g., Gnosis Safe) rather than a single EOA.
This will introduce a higher level of security and distributed control over critical functions like pausing and role management. Additionally, carefully consider the operational procedures for assigning and managing the MINTER_ROLE, ensuring it is also controlled by a multi-signature wallet or a trusted, audited smart contract with clear minting policies.
For future projects, evaluate the benefits of incorporating an upgradeability pattern (e.g., UUPS proxy) to allow for secure and controlled contract modifications. This would provide flexibility for bug fixes, feature enhancements, and adapting to evolving protocol needs without requiring a token migration.
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.
- Sep 4, 202648Medium
- Aug 12, 202643Medium
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Would You Like a More Detailed Audit of BSquared 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