Quantum Audit Logo
Launch App

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

Is Biconomy Safe?

BICOEthereum
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/10Governance1/10Upgrades2/10Checks passed2 of 5Findings1 Medium · 2 Info3
SummaryAI Copilot

The BicoToken contract, implemented as an upgradeable ERC-20 token behind a Transparent Proxy, leverages well-audited OpenZeppelin libraries for upgradeability, access control, and reentrancy protection.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Proxy contract
  • Top-10 concentration > 50%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k
  • LP top1 unlocked holder = 99.9%
  • LP top3 unlocked holders = 100.0%
  • 1 Medium finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 50% (62.9% total → 59.9% effective; 57.9% in EOAs, 5.0% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($41,072 across 2 pairs — thin market)
  • LP top1 unlocked holder = 99.9% (independent LP — depth risk, pool = 87% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 87% of DEX liquidity)
  • 1 Medium 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
OwnershipUnknown
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
5.0%Contracts57.9%Wallets37.1%Everyone else
5.0%57.9%Wallets37.1%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
62.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking5.0%
  • Walletsanonymous holders, free to sell57.9%
  • Everyone elsethe rest of the supply37.1%
Effective concentrationwhat the score reads59.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$41.1K across 2 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$35.6KShare of depth86.7%
Top-1 Unlocked Holder99.9%
Top-3 Unlocked100.0%
Unlocked LP held by
0x3887…7f1c0x74cd…4e8d0xb70f…19dc0x13e9…37030xd5a1…6c700x1d2a…158c0x0fb2…e6a80xd6f0…eebd0xb9ab…45680x5ad6…e277

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

Security Findings

1 Medium2 Info
Medium

Transparent Proxy Admin Function Clash

The contract uses the Transparent Proxy pattern. A known characteristic of this pattern is that if the proxy admin (0x2a2d…bce3) calls a function that exists in both the proxy contract and the implementation contract, the call will be routed to the proxy's function, not the implementation's. This can lead to unexpected behavior, failed transactions, or operational errors if the admin intends to interact with the implementation's logic (7.1 Architecture, 7.7 Upgrades).M-01

Issue

The contract uses the Transparent Proxy pattern. A known characteristic of this pattern is that if the proxy admin () calls a function that exists in both the proxy contract and the implementation contract, the call will be routed to the proxy's function, not the implementation's. This can lead to unexpected behavior, failed transactions, or operational errors if the admin intends to interact with the implementation's logic (7.1 Architecture, 7.7 Upgrades).

Fix

The proxy admin should only call functions that are unique to the proxy (e.g., upgradeTo, changeAdmin). All other interactions with the contract's logic should be performed by non-admin accounts. Implement thorough testing and clear operational guidelines for the multisig signers to prevent accidental function clashes.

Status

Unresolved

Info

Centralized Control of Upgradeability

The upgradeability of the BicoToken is controlled by a 2-of-3 multisig (0x2a2d…bce3). While a multisig enhances security over a single External Owned Account (EOA), it still represents a centralized point of control for future contract logic changes. This implies that a majority of the multisig signers can unilaterally decide on and execute upgrades, which could introduce new vulnerabilities or alter tokenomics (7.5 Governance, 7.3 Access Control).I-01

Issue

The upgradeability of the BicoToken is controlled by a 2-of-3 multisig (). While a multisig enhances security over a single External Owned Account (EOA), it still represents a centralized point of control for future contract logic changes. This implies that a majority of the multisig signers can unilaterally decide on and execute upgrades, which could introduce new vulnerabilities or alter tokenomics (7.5 Governance, 7.3 Access Control).

Fix

This is a common and often necessary design choice for upgradeable contracts. For transparency, clearly communicate the role and responsibilities of the multisig signers to the community. Consider exploring more decentralized governance mechanisms for upgrades in the long term, if aligned with the project's vision.

Status

Unresolved

Info

Incomplete Source Code Provided

The provided source code snippet for the BicoTokenImplementation contract is truncated, specifically for the StringsUpgradeable library and potentially the main token logic. A full security audit requires access to the complete, verifiable source code of all deployed contracts and their dependencies to ensure no hidden logic or vulnerabilities exist beyond the scope of the provided snippet (7.2 Code Security).I-02

Issue

The provided source code snippet for the BicoTokenImplementation contract is truncated, specifically for the StringsUpgradeable library and potentially the main token logic. A full security audit requires access to the complete, verifiable source code of all deployed contracts and their dependencies to ensure no hidden logic or vulnerabilities exist beyond the scope of the provided snippet (7.2 Code Security).

Fix

For future audits, always provide the complete and verified source code for all contracts, including any imported libraries or inherited contracts, to enable a comprehensive security analysis.

Status

Unresolved

Analysis

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

The BicoToken contract, implemented as an upgradeable ERC-20 token behind a Transparent Proxy, leverages well-audited OpenZeppelin libraries for upgradeability, access control, and reentrancy protection. The proxy's administrative control is secured by a 2-of-3 multisig, enhancing operational security. While the architecture is robust, a known risk with Transparent Proxies regarding admin function clashes is present. The provided source code was truncated, limiting a full review of the entire implementation.

Technical8/10Low risk

The contract leverages battle-tested OpenZeppelin upgradeable libraries, including Initializable and ReentrancyGuardUpgradeable, which significantly enhances code security (7.2 Code Security). The use of Solidity 0.8.4 provides default checked arithmetic, mitigating integer overflow/underflow risks. A potential technical risk lies in the Transparent Proxy pattern, where the proxy admin could inadvertently call a function on the proxy itself if a function selector clashes with the implementation (7.1 Architecture).

Governance1/10High risk

The contract's upgradeability and administrative functions are secured by a 2-of-3 multisig (7.5 Governance), providing a robust access control mechanism against single points of failure (7.3 Access Control). The prefill indicates no minting functionality (has_mint: false), suggesting a fixed supply token, which reduces certain economic risks (7.4 Economic). However, the multisig represents a centralized control point for critical operations.

Upgrades2/10High risk

The contract utilizes the Transparent Proxy pattern with OpenZeppelin's upgradeable contracts, including Initializable and __gap storage variables, ensuring proper storage layout for future upgrades (7.7 Upgrades). The proxy's admin is a 2-of-3 multisig, enhancing the security of upgrade decisions. A known risk with Transparent Proxies is the potential for function selector clashes between the proxy and implementation, which could lead to operational issues if the admin calls a clashing function (7.7 Upgrades).

Final RecommendationWhat to do about this score

It is recommended to ensure that the multisig administrators are fully aware of the Transparent Proxy pattern's specific operational considerations, particularly regarding potential function selector clashes.

Implement robust internal procedures and testing for all upgrade proposals to mitigate this risk. Additionally, for future audits, provide the complete and verifiable source code for all contracts and their dependencies to allow for a comprehensive security review.

Contract & Record

1 audit on record
TypeBicoTokenProxy
NetworkEthereum
Token age4y
Contract0xf17e…c6c2
Deployer0x7f3b…4138
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminMultisig · 3-of-3
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Biconomy 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, 202645Medium
  2. Aug 7, 202639Medium

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

Related Audits

6 more on the recordAll audits
LiskLSK · Ethereum45MediumSatellite Doge-1DOGE-1 · Ethereum44MediumEuro CoinEURC · Ethereum44MediumWorld Liberty FinancialWLFI · Ethereum44MediumAsentumASE · Ethereum46MediumTornadoCashTORN · Ethereum46Medium

Would You Like a More Detailed Audit of Biconomy?

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