Quantum Audit Logo

Is BIO Safe?

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

BIO BIO
0x226a…7dd2
Base Not verifiedLast checked 2d ago 1 audit on record
Executive SummaryAI Copilot

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.

2 Medium1 Low1 Informational
Volume 24h
$375.1K
Liquidity
$365.3K
Price
$0.02687
Token Age
1y
Top 10 Holders
80.4%

Security Findings

Medium

Centralized Control over Token Transfers

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

Unlimited Minting Capability

M-02The `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.
IssueThe `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.
FixIf 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.
StatusUnresolved
Low

Unused ERC20Capped Import

L-01The `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.
IssueThe `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.
FixRemove 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.
StatusUnresolved
Info

Initial Transfer Restriction Requires Manual Activation

I-01The `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`.
IssueThe `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`.
FixThis 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.
StatusUnresolved

Category Ratings

TechnicalLow8/10

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.

GovernanceHigh3/10

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.

UpgradesMedium4/10

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.

Security Checklist

Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

34.7% in wallets45.7% in contracts
Effective Concentration52.9%

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 1 more pairShow 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
0x9ec0…99b5
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.

What Raised This Score

  • 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

Related Audits

Morpho Token (MORPHO)High RiskTether USD (USDT)High RiskevoHigh RiskHydrex (HYDX)High RiskAavegotchi GHST Token (GHST)High RiskFree Bots (BOTS)High Risk

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