Is BIO Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med1 Low1 Info

High

Centralized Control over Token Supply and Transfers

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

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

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

StatusUnresolved

Medium

Dual Access Control Mechanisms

M-01The `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.

IssueThe `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.

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

StatusUnresolved

Low

Unused Import

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

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

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

StatusUnresolved

Info

Initial Transfer Restrictions

I-01The `_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.

IssueThe `_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.

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

StatusUnresolved

Category Ratings

TechnicalLow7/10

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.

GovernanceHigh3/10

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.

UpgradesMedium4/10

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.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Holder Composition

59.6% in top 10

27.5% in wallets32.1% in contracts

Effective Concentration40.3%

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

$533.8K across 8 pairs

Uniswap v4ETHanalysed$336.4K Uniswap v4USDC$64.4K Uniswap v3NEURON$61.9K Uniswap v3VITA$54.5K Uniswap v2QBIO$12.1K Uniswap v3WETH$3.8K

Show 2 more pairsShow less

SupernovaWETH$526 Uniswap v3USDT$139

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 Holder99.3%

Top-3 Unlocked100.0%

Key Addresses

6 addresses

Deployer

0x0536…c932

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.

What Raised This Score

9 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

Is BIO Safe?

Security Findings

Centralized Control over Token Supply and Transfers

Dual Access Control Mechanisms

Unused Import

Initial Transfer Restrictions

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of BIO?