Quantum Audit Logo
Launch App

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

Is BIO Safe?

Ethereum
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
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance3/10Upgrades4/10Checks passed2 of 5Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The BioToken contract implements an ERC20 token with burnable functionality, utilizing OpenZeppelin's Ownable and AccessControlEnumerable for permission management.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.3%
  • 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 NOT renounced — strong Multisig (3-of-6)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (59.6% total → 40.3% effective; 27.5% in EOAs, 32.1% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.3% (independent LP — depth risk, pool = 63% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 63% 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
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
32.1%Contracts27.5%Wallets40.4%Everyone else
32.1%Contracts27.5%Wallets40.4%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
59.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking32.1%
  • Walletsanonymous holders, free to sell27.5%
  • Everyone elsethe rest of the supply40.4%
Effective concentrationwhat the score reads40.3%
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$533.8K across 8 pairs
Show 2 more pairs

The risk score reads depth across every pair.

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$336.4KShare of depth63.0%
Top-1 Unlocked Holder99.3%
Top-3 Unlocked100.0%
Unlocked LP held by
0x0049…56280xdcd1…a5060x5fa9…2d720x4f0c…53c40x7c4d…8f2c

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

Security Findings

1 High1 Medium1 Low1 Info
High

Centralized Control over Token Supply and Transfers

The contract grants significant power to the owner() and accounts with MINTER_ROLE. The mint function, callable by MINTER_ROLE holders, allows for an arbitrary amount of new tokens to be created, potentially leading to unlimited inflation. Furthermore, the enableTransfers function, callable only by the owner(), dictates when general token transfers are allowed, effectively enabling the owner to freeze or unfreeze transfers for all users. This high degree of centralization (7.4 Economic, 7.5 Governance, 7.8 Operations) poses a substantial risk if the controlling keys are compromised or misused, potentially leading to economic instability or censorship.H-01

Issue

The contract grants significant power to the owner() and accounts with MINTER_ROLE. The mint function, callable by MINTER_ROLE holders, allows for an arbitrary amount of new tokens to be created, potentially leading to unlimited inflation. Furthermore, the enableTransfers function, callable only by the owner(), dictates when general token transfers are allowed, effectively enabling the owner to freeze or unfreeze transfers for all users. This high degree of centralization (7.4 Economic, 7.5 Governance, 7.8 Operations) poses a substantial risk if the controlling keys are compromised or misused, potentially leading to economic instability or censorship.

Fix

Implement a multi-signature wallet for the owner() address and for managing the MINTER_ROLE and TRANSFER_ROLE. Consider adding a time-lock mechanism for critical operations like enabling transfers or changing minters to provide a window for community review or emergency intervention. Explore options for progressive decentralization of these powers, potentially through a governance module.

Status

Unresolved

Medium

Dual Access Control Mechanisms

The BioToken contract inherits from both Ownable and AccessControlEnumerable (7.3 Access Control). While both are robust OpenZeppelin libraries, their combined use for different privileged functions (onlyOwner for enableTransfers and onlyRole for mint) creates two distinct access control systems. This can lead to increased complexity in role management, potential confusion for administrators, and a higher chance of misconfiguration compared to using a single, unified access control system.M-01

Issue

The BioToken contract inherits from both Ownable and AccessControlEnumerable (7.3 Access Control). While both are robust OpenZeppelin libraries, their combined use for different privileged functions (onlyOwner for enableTransfers and onlyRole for mint) creates two distinct access control systems. This can lead to increased complexity in role management, potential confusion for administrators, and a higher chance of misconfiguration compared to using a single, unified access control system.

Fix

Consolidate access control under a single mechanism, preferably AccessControlEnumerable due to its flexibility. For instance, enableTransfers could be protected by a specific role (e.g., PAUSER_ROLE) instead of onlyOwner. This would streamline permission management and reduce potential operational errors.

Status

Unresolved

Low

Unused Import

The contract imports ERC20Capped from @openzeppelin/contracts/token/ERC20/extensions/ERC20Capped.sol but does not utilize its functionality (7.2 Code Security). The BioToken contract does not inherit from ERC20Capped nor does it implement any capping logic.L-01

Issue

The contract imports ERC20Capped from @openzeppelin/contracts/token/ERC20/extensions/ERC20Capped.sol but does not utilize its functionality (7.2 Code Security). The BioToken contract does not inherit from ERC20Capped nor does it implement any capping logic.

Fix

Remove the unused import statement for ERC20Capped to improve code clarity and reduce unnecessary dependencies. If capping functionality is intended for the future, ensure it is properly integrated into the contract's inheritance and logic.

Status

Unresolved

Info

Initial Transfer Restrictions

The _beforeTokenTransfer hook implements a mechanism where general token transfers are restricted until the transfersEnabled flag is set to true by the owner (7.1 Architecture, 7.8 Operations). During this restricted phase, only minting, transfers by the owner, or transfers by accounts holding the TRANSFER_ROLE are permitted. This is a common pattern for controlled token launches or initial distribution phases.I-01

Issue

The _beforeTokenTransfer hook implements a mechanism where general token transfers are restricted until the transfersEnabled flag is set to true by the owner (7.1 Architecture, 7.8 Operations). During this restricted phase, only minting, transfers by the owner, or transfers by accounts holding the TRANSFER_ROLE are permitted. This is a common pattern for controlled token launches or initial distribution phases.

Fix

Ensure that the project's documentation clearly communicates this initial transfer restriction and the conditions under which general transfers will be enabled. This transparency helps manage user expectations and prevents confusion regarding token liquidity.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The BioToken contract implements an ERC20 token with burnable functionality, utilizing OpenZeppelin's Ownable and AccessControlEnumerable for permission management. Key features include a minting function restricted by a MINTER_ROLE and a transfer mechanism that can be enabled/disabled by the owner. While the code is generally well-structured and relies on audited libraries, significant centralization risks exist due to the owner's control over token supply and transfer restrictions. The contract does not include upgradeability features.

Technical7/10Low risk

The BioToken contract (7.1 Architecture, 7.2 Code Security) is built upon battle-tested OpenZeppelin ERC20, ERC20Burnable, Ownable, and AccessControlEnumerable libraries, which significantly reduces the risk of common vulnerabilities. The custom logic for transfer restrictions in _beforeTokenTransfer is clearly defined and appears to function as intended for a controlled launch. However, the use of both Ownable and AccessControlEnumerable (7.3 Access Control) for different privileged functions introduces two distinct access control systems, which could lead to management complexity or potential misconfigurations if not carefully handled. An unused import for ERC20Capped also indicates minor code hygiene issues.

Governance3/10High risk

The contract exhibits a high degree of centralization (7.4 Economic, 7.5 Governance, 7.8 Operations). The MINTER_ROLE allows for unlimited token minting, which, if compromised or misused, could lead to severe inflation and devaluation of the token. Furthermore, the contract owner has the sole authority to enableTransfers, effectively controlling when general token transfers are permitted. This centralized control over critical economic parameters and operational functions by a single entity or a small group of role holders presents a significant risk to the protocol's economic stability and governance model.

Upgrades4/10Medium risk

The BioToken contract (7.7 Upgrades) is not designed with any upgradeability mechanism, such as a proxy pattern. This means that once deployed, the contract's logic cannot be modified or updated. While this eliminates risks associated with upgradeability itself (e.g., proxy implementation bugs, upgrade path vulnerabilities), it also means that any discovered critical bugs or desired feature enhancements would necessitate a new contract deployment and token migration.

Final RecommendationWhat to do about this score

To mitigate the identified risks, consider implementing a multi-signature wallet for the owner() address and for managing critical roles like MINTER_ROLE and TRANSFER_ROLE.

This would distribute control and reduce the single point of failure risk. Additionally, evaluate the necessity of the dual access control mechanisms and consider consolidating permissions under AccessControlEnumerable for improved clarity and management. For future iterations, explore community governance mechanisms to decentralize control over key token parameters.

Contract & Record

1 audit on record
TypeBioToken
NetworkEthereum
Token age1y
Contract0xcb15…5ffa
Deployer0x0536…c932
Badge for your website
BIO 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. Aug 20, 202652Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Related Audits

6 more on the recordAll audits
UniswapUNI · Ethereum52MediumRelicsEthereum52MediumVirtuals ProtocolVIRTUAL · Ethereum51MediumDeriveDRV · Ethereum51MediumLido DAOLDO · Ethereum51MediumFOXEthereum53Medium

Would You Like a More Detailed Audit of BIO?

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