Quantum Audit Logo
Launch App

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

Is BSquared Token Safe?

B2BNB 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
SummaryAI Copilot

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
What raised the score
  • 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 42 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
64.6%Contracts9.9%Wallets25.4%Everyone else
64.6%Contracts9.9%25.4%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
74.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking64.6%
  • Walletsanonymous holders, free to sell9.9%
  • Everyone elsethe rest of the supply25.4%
Effective concentrationwhat the score reads35.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$729.4K across 10 pairs
LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$728.2KShare of depth99.8%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x1730…27f60xa54b…5a000x6642…1a33

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

Security Findings

1 High1 Medium1 Low2 Info
High

Centralized 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

Medium

Unassigned 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

Low

No 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

Info

Immutability / 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

Info

Reliance 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 4
Executive SummaryWhat the contract is and what the review found

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.

Technical7/10Low risk

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

Governance1/10High risk

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.

Upgrades5/10Medium risk

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.

Final RecommendationWhat to do about this score

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

1 audit on record
TypeB2Token
NetworkBNB Chain
Token age1y
Contract0x783c…e2a2
Deployer0x61bb…5946
Badge for your website
BSquared Token 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, 202648Medium
  2. 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