Is Biconomy (BICO) Safe? Smart Contract Security Analysis

Security Findings

1 Med2 Info

Medium

Transparent Proxy Admin Function Clash

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

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

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

StatusUnresolved

Info

Centralized Control of Upgradeability

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

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

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

StatusUnresolved

Info

Incomplete Source Code Provided

I-02The 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).

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

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

StatusUnresolved

Category Ratings

TechnicalLow8/10

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

GovernanceHigh1/10

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.

UpgradesHigh2/10

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

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent

AdminMultisig · 3-of-3

ImplementationVerified source

Upgrades (30d)0 · stable

Holder Composition

62.9% in top 10

57.9% in wallets5.0% in contracts

Effective Concentration59.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

$41.1K across 2 pairs

SushiswapWETHanalysed$35.6K BalancerWETH$5.5K

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.9%

Top-3 Unlocked100.0%

Key Addresses

11 addresses

Deployer

0x7f3b…4138

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.

What Raised This Score

8 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

Is Biconomy Safe?

Security Findings

Transparent Proxy Admin Function Clash

Centralized Control of Upgradeability

Incomplete Source Code Provided

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Biconomy?