Quantum Audit Logo

Is Coinbase Wrapped BTC Safe?

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

Coinbase Wrapped BTC CBBTC
0xcbb7…33bf
Arbitrum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The audit of the FiatTokenV2_1 implementation contract identified a critical access control vulnerability in its initialization function, which could lead to unauthorized fund transfers and contract blacklisting. While the contract leverages well-audited OpenZeppelin libraries for core functionalities, the lack of proper protection for upgrade-specific logic poses a significant risk. Further, the absence of the base FiatTokenV2 contract code limits the scope of a comprehensive assessment.

1 Critical1 High1 Medium1 Low1 Informational
Volume 24h
$1.36M
Liquidity
$776.1K
Price
$80971.3800
Token Age
1y
Top 10 Holders
50.8%

Security Findings

1 Crit1 High1 Med1 Low1 Info
Critical

Lack of Access Control on `initializeV2_1` Function

C-01The `initializeV2_1` function, intended for upgrade-specific initialization, lacks proper access control. It only checks `_initializedVersion == 1` but does not restrict *who* can call it. If the `_initializedVersion` state variable is set to 1 (e.g., by a previous `initialize` call in `FiatTokenV2`), any external caller can execute this function. This allows unauthorized parties to trigger critical state changes.
IssueThe `initializeV2_1` function, intended for upgrade-specific initialization, lacks proper access control. It only checks `_initializedVersion == 1` but does not restrict *who* can call it. If the `_initializedVersion` state variable is set to 1 (e.g., by a previous `initialize` call in `FiatTokenV2`), any external caller can execute this function. This allows unauthorized parties to trigger critical state changes.
FixImplement a robust access control mechanism (e.g., `onlyOwner` or `onlyProxyAdmin`) for the `initializeV2_1` function. Ensure that the `_initializedVersion` state is managed carefully across upgrades and that initialization functions are called only by authorized entities, typically the proxy admin.
StatusUnresolved
High

Critical State Changes in Unprotected `initializeV2_1`

H-01The `initializeV2_1` function performs two critical and irreversible state changes: transferring all tokens held by the contract (`balances[address(this)]`) to a `lostAndFound` address and then blacklisting the contract itself. Due to the lack of access control (C-01), an unauthorized caller could trigger these actions. If the `lostAndFound` address is incorrect or compromised, funds could be permanently lost. Blacklisting the contract prevents it from holding or transferring tokens, which could disrupt operational flows if not fully anticipated.
IssueThe `initializeV2_1` function performs two critical and irreversible state changes: transferring all tokens held by the contract (`balances[address(this)]`) to a `lostAndFound` address and then blacklisting the contract itself. Due to the lack of access control (C-01), an unauthorized caller could trigger these actions. If the `lostAndFound` address is incorrect or compromised, funds could be permanently lost. Blacklisting the contract prevents it from holding or transferring tokens, which could disrupt operational flows if not fully anticipated.
FixThoroughly review the necessity and implications of these actions. Ensure the `lostAndFound` address is secure and correctly configured, ideally a multi-signature wallet. Document the operational impact of blacklisting the contract address. Consider adding a timelock or multi-party confirmation for such critical operations.
StatusUnresolved
Medium

Incomplete Audit Scope (Missing `FiatTokenV2` Source)

M-01The provided source code is for `FiatTokenV2_1`, which inherits from `FiatTokenV2`. The full source code for `FiatTokenV2` was not provided, limiting the ability to conduct a comprehensive audit of the entire token logic, including its initialization, access control, and core ERC-20 functionalities. Potential vulnerabilities in the base contract could affect the `FiatTokenV2_1` implementation.
IssueThe provided source code is for `FiatTokenV2_1`, which inherits from `FiatTokenV2`. The full source code for `FiatTokenV2` was not provided, limiting the ability to conduct a comprehensive audit of the entire token logic, including its initialization, access control, and core ERC-20 functionalities. Potential vulnerabilities in the base contract could affect the `FiatTokenV2_1` implementation.
FixProvide the complete source code for all inherited contracts (`FiatTokenV2` and any further dependencies) for a full security assessment of the entire system.
StatusUnresolved
Low

Use of Older Solidity Version and OpenZeppelin Libraries

L-01The contract uses Solidity `0.6.12` and corresponding OpenZeppelin libraries. While `0.6.x` is generally stable, newer Solidity versions (e.g., `0.8.x`) offer built-in overflow/underflow checks, reducing reliance on `SafeMath`, and other compiler optimizations. This can lead to minor gas inefficiencies and potential exposure to subtle compiler bugs present in older versions.
IssueThe contract uses Solidity `0.6.12` and corresponding OpenZeppelin libraries. While `0.6.x` is generally stable, newer Solidity versions (e.g., `0.8.x`) offer built-in overflow/underflow checks, reducing reliance on `SafeMath`, and other compiler optimizations. This can lead to minor gas inefficiencies and potential exposure to subtle compiler bugs present in older versions.
FixConsider upgrading to a more recent Solidity compiler version (e.g., `0.8.x`) and the latest compatible OpenZeppelin contracts to benefit from security enhancements, improved gas efficiency, and modern language features.
StatusUnresolved
Info

Deliberate Blacklisting of Contract Address

I-01The `initializeV2_1` function explicitly blacklists `address(this)`, meaning the proxy contract itself will be unable to send or receive tokens. This is a deliberate design choice often seen in stablecoins to prevent the token contract from being frozen or having its balance manipulated by external actors or its own functions.
IssueThe `initializeV2_1` function explicitly blacklists `address(this)`, meaning the proxy contract itself will be unable to send or receive tokens. This is a deliberate design choice often seen in stablecoins to prevent the token contract from being frozen or having its balance manipulated by external actors or its own functions.
FixEnsure this design choice is well-understood and documented within the project's specifications and operational procedures, as it has specific implications for how the token contract can interact with its own token supply.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract utilizes well-audited OpenZeppelin libraries like SafeMath and SafeERC20, enhancing code security against common integer and ERC-20 interaction vulnerabilities (7.2 Code Security). However, a critical architectural flaw exists in the `initializeV2_1` function, which lacks proper access control, allowing any caller to trigger significant state changes (7.3 Access Control, C-01). The reliance on `_initializedVersion == 1` as the sole protection is insufficient for a critical upgrade function.

GovernanceHigh1/10

The primary governance and economic risk stems from the unprotected `initializeV2_1` function, which can be called by anyone if `_initializedVersion` is 1, leading to unauthorized transfer of contract-held tokens and blacklisting of the contract itself (7.3 Access Control, 7.4 Economic, C-01, H-01). This poses a severe risk to asset security and operational control. The `lostAndFound` address becomes a single point of failure for transferred funds, requiring robust management (7.6 External, 7.8 Operations).

UpgradesHigh1/10

As an implementation contract for a proxy, upgrade safety is paramount (7.1 Architecture). The `initializeV2_1` function is designed for post-upgrade setup but critically lacks access control, making it callable by any address (7.7 Upgrades, C-01). This vulnerability allows unauthorized parties to execute critical initialization steps, including transferring funds and blacklisting the proxy contract (H-01), severely compromising the upgrade process and the integrity of the token.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeZeppelin Os Legacy
AdminEOA (single key controls upgrades)
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

50.8% in top 10
30.1% in wallets20.7% in contracts
Effective Concentration38.4%

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

$893.6K across 2 pairs
UniswapWBTCanalysed$776.1K86.8%PancakeswapWBTC$117.6K13.2%

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

2 addresses
Deployer
0xce97…4b05
Unlocked LP Held By
0xbe2f…1b54

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

What Raised This Score

12 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Admin is EOA (single key controls upgrades)
  • Top-10 concentration > 30% (50.8% total → 38.4% effective; 30.1% in EOAs, 20.7% in contracts — moderate)
  • 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 = 87% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 87% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 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

Related Audits

6 more on the record
ChipCritical RiskOrnn Exchange (ORNN)Critical RiskVision (VSN)Critical RiskDai Stablecoin (DAI)High RiskAethir Token (ATH)High RiskCatena Labs (CATE)Critical Risk

Would You Like a More Detailed Audit of Coinbase Wrapped BTC?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit