Quantum Audit Logo

Is BSquared Token Safe?

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

Is this your token? Publish your own audit on this page →

BSquared Token B2
0x783c…e2a2
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
Executive 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. 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.

1 High1 Medium1 Low2 Informational
Volume 24h
$385.1K
Liquidity
$728.2K
Price
$0.4134
Token Age
1y
Top 10 Holders
74.6%

Security Findings

High

Centralized Control of Critical Functions

H-01The `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).
IssueThe `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).
FixAssign 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.
StatusUnresolved
Medium

Unassigned MINTER_ROLE Post-Deployment

M-01The `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).
IssueThe `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).
FixEnsure 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.
StatusUnresolved
Low

No Emergency Renouncement for MINTER_ROLE

L-01While 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).
IssueWhile 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).
FixWhile `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.
StatusUnresolved
Info

Immutability / No Upgradeability

I-01The `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).
IssueThe `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).
FixFor 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.
StatusUnresolved
Info

Reliance on OpenZeppelin Libraries

I-02The 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).
IssueThe 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).
FixContinue 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.
StatusUnresolved

Category Ratings

TechnicalLow7/10

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.

GovernanceHigh1/10

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.

UpgradesMedium5/10

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.

Security Checklist

Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

9.9% in wallets64.6% in contracts
Effective Concentration35.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

Show 3 more pairsShow less

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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

Deployer
0x61bb…5946
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.

What Raised This Score

  • 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

Related Audits

BrokHigh RiskCRYSTAL STONESHigh RiskIce Open Network (ION)High RiskEthereum Token (ETH)High RiskUSELESS COIN (USELESS)High RiskCSI888 (CSI)High Risk

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