Quantum Audit Logo
Launch App

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

Is BIO Safe?

Base
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
Technical8/10Governance3/10Upgrades4/10Checks passed2 of 5Findings2 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The Token contract implements an ERC-20 token with burnable functionality and role-based access control using OpenZeppelin's AccessControlDefaultAdminRules.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 50%
  • 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%
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — strong Multisig (5-of-8)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 50% (80.4% total → 52.9% effective; 34.7% in EOAs, 45.7% in contracts — heavy)
  • 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 = 46% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 46% of DEX liquidity)
  • 2 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
45.7%Contracts34.7%Wallets19.6%Everyone else
45.7%Contracts34.7%Wallets19.6%
ContractsWalletsEveryone elseBubble area = share of supply
80.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking45.7%
  • Walletsanonymous holders, free to sell34.7%
  • Everyone elsethe rest of the supply19.6%
Effective concentrationwhat the score reads52.9%
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$798.8K across 12 pairs
Show 1 more pair

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$365.3KShare of depth45.7%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x33ab…21fa0x69e5…109b0xcdeb…a3a0

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

Security Findings

2 Medium1 Low1 Info
Medium

Centralized Control over Token Transfers

The DEFAULT_ADMIN_ROLE has significant control over token transfers. It can call enableTransfers() to allow all users to transfer tokens, and it can also bypass the transfersEnabled restriction itself via the owner() check in _beforeTokenTransfer. This centralizes critical control over the token's liquidity and transferability, posing a risk if the DEFAULT_ADMIN_ROLE is compromised or mismanaged.M-01

Issue

The DEFAULT_ADMIN_ROLE has significant control over token transfers. It can call enableTransfers() to allow all users to transfer tokens, and it can also bypass the transfersEnabled restriction itself via the owner() check in _beforeTokenTransfer. This centralizes critical control over the token's liquidity and transferability, posing a risk if the DEFAULT_ADMIN_ROLE is compromised or mismanaged.

Fix

Ensure the DEFAULT_ADMIN_ROLE is secured by a robust multi-signature wallet with a high threshold. Clearly define and communicate the operational procedures and responsibilities associated with this role. Consider if the ability for the DEFAULT_ADMIN_ROLE to bypass transfer restrictions is strictly necessary, or if it could be limited to only enabling/disabling for all users.

Status

Unresolved

Medium

Unlimited Minting Capability

The MINTER_ROLE has the ability to mint an unlimited supply of tokens via the mint() function. There is no cap enforced on the total supply, which could lead to token inflation and devaluation if the MINTER_ROLE is compromised or misused. While ERC20Capped is imported, it is not utilized by the Token contract.M-02

Issue

The MINTER_ROLE has the ability to mint an unlimited supply of tokens via the mint() function. There is no cap enforced on the total supply, which could lead to token inflation and devaluation if the MINTER_ROLE is compromised or misused. While ERC20Capped is imported, it is not utilized by the Token contract.

Fix

If a maximum supply is intended, implement the ERC20Capped functionality or introduce a custom cap mechanism. If unlimited minting is by design, ensure strict off-chain governance and operational controls are in place for the MINTER_ROLE to prevent abuse. Consider implementing a time-locked or multi-signature controlled minting process for large amounts.

Status

Unresolved

Low

Unused ERC20Capped Import

The ERC20Capped contract is imported from OpenZeppelin but is not inherited or utilized by the Token contract. This suggests a potential design decision change or oversight, as the contract currently has no maximum supply cap despite importing the relevant functionality.L-01

Issue

The ERC20Capped contract is imported from OpenZeppelin but is not inherited or utilized by the Token contract. This suggests a potential design decision change or oversight, as the contract currently has no maximum supply cap despite importing the relevant functionality.

Fix

Remove the unused import if a supply cap is not intended, to improve code clarity and reduce potential confusion. If a supply cap was intended, integrate ERC20Capped into the Token contract's inheritance hierarchy and set an appropriate cap during deployment.

Status

Unresolved

Info

Initial Transfer Restriction Requires Manual Activation

The transfersEnabled flag is initialized to false, meaning general token transfers are restricted immediately after deployment. Transfers can only be performed by address(0) (minting), the owner() (DEFAULT_ADMIN_ROLE), or accounts with the TRANSFER_ROLE until the enableTransfers() function is explicitly called by the DEFAULT_ADMIN_ROLE.I-01

Issue

The transfersEnabled flag is initialized to false, meaning general token transfers are restricted immediately after deployment. Transfers can only be performed by address(0) (minting), the owner() (DEFAULT_ADMIN_ROLE), or accounts with the TRANSFER_ROLE until the enableTransfers() function is explicitly called by the DEFAULT_ADMIN_ROLE.

Fix

This is an intended feature for controlled token launch. Ensure that the operational team is aware of this initial state and has a clear plan for when and how enableTransfers() will be called. Communicate this behavior to users to manage expectations.

Status

Unresolved

Analysis

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

The Token contract implements an ERC-20 token with burnable functionality and role-based access control using OpenZeppelin's AccessControlDefaultAdminRules. The contract exhibits good code quality and leverages audited libraries. Key functionalities include minting by a MINTER_ROLE and controlled transfer enablement by a DEFAULT_ADMIN_ROLE. While robust access control is in place, the centralized power of these roles introduces significant governance and economic risks, particularly regarding token supply and transfer restrictions.

Technical8/10Low risk

The contract (7.1 Architecture, 7.2 Code Security) is well-structured, inheriting from battle-tested OpenZeppelin ERC20 and AccessControlDefaultAdminRules contracts, ensuring a solid foundation and adherence to standards. Solidity version 0.8.23 mitigates common integer overflow/underflow issues. Access control (7.3 Access Control) is implemented using roles (DEFAULT_ADMIN_ROLE, MINTER_ROLE, TRANSFER_ROLE), providing granular permissions. However, the centralized power of the DEFAULT_ADMIN_ROLE and MINTER_ROLE introduces a technical risk if these roles are compromised, as they can unilaterally control token supply and transferability.

Governance3/10High risk

The contract (7.4 Economic, 7.5 Governance) utilizes OpenZeppelin's AccessControlDefaultAdminRules, which provides a robust, delayed mechanism for transferring the DEFAULT_ADMIN_ROLE, enhancing security for critical governance functions. The initial DEFAULT_ADMIN_ROLE is held by a multisig, which is a strong security practice. However, the MINTER_ROLE has the ability to mint an unlimited supply of tokens, posing a significant economic risk of inflation. Additionally, the DEFAULT_ADMIN_ROLE retains unilateral control over enabling/disabling transfers and bypassing transfer restrictions, centralizing substantial power over the token's economic flow.

Upgrades4/10Medium risk

The contract (7.7 Upgrades) is not designed to be upgradeable, eliminating any risks associated with upgrade mechanisms, proxy patterns, or potential upgradeability bugs. This design choice simplifies the contract's lifecycle and reduces the attack surface related to future modifications.

Final RecommendationWhat to do about this score

It is recommended to carefully manage the keys and operational procedures for the DEFAULT_ADMIN_ROLE and MINTER_ROLE, especially given their centralized power over token supply and transferability.

Consider implementing a maximum supply cap if not already intended, or establish clear off-chain governance policies for minting. Ensure the multisig holding the DEFAULT_ADMIN_ROLE is robustly secured and its members are trustworthy.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age1y
Contract0x226a…7dd2
Deployer0x9ec0…99b5
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. Sep 4, 202660Medium
  2. Aug 14, 202661Medium

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

Frequently Asked Questions

What is the BIO contract address?

The BIO contract on Base is 0x226a2fa2556c48245e57cd1cba4c6c9e67077dd2. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is BIO a scam?

Quantum Audit's risk score for BIO is 60/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is BIO liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $798.8K.

Who holds BIO?

As of Sep 4, 2026, the 10 largest holders own 80.4% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
Morpho TokenMORPHO · Base60MediumTether USDUSDT · Base60MediumevoBase60MediumHydrexHYDX · Base60MediumAavegotchi GHST TokenGHST · Base60MediumFree BotsBOTS · Base60Medium

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