Quantum Audit Logo

Is Coinbase Wrapped BTC Safe?

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

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

This audit covers the FiatTokenV2_1 contract, which serves as an implementation for an upgradeable proxy. The analysis focuses on the `initializeV2_1` function and general security practices. While the contract utilizes well-vetted libraries like OpenZeppelin's SafeMath and SafeERC20, specific logic within the upgrade initialization introduces medium-level risks related to critical state changes and potential misconfiguration. The provided source code for inherited contracts and libraries was truncated, limiting a full comprehensive analysis of all dependencies.

1 Medium2 Low1 Informational
Volume 24h
$2.43M
Liquidity
$18.10M
Price
$80993.3600
Token Age
1y
Top 10 Holders
91.5%

Security Findings

1 Med2 Low1 Info
Medium

Critical State Changes in `initializeV2_1`

M-01The `initializeV2_1` function performs two highly impactful operations: it transfers the entire balance of the token contract (`balances[address(this)]`) to a `lostAndFound` address, and then blacklists the token contract itself (`blacklisted[address(this)] = true`). If the `lostAndFound` address is incorrect, or if blacklisting the contract prevents it from performing necessary future operations (e.g., receiving tokens, interacting with other protocols), it could lead to a denial of service or loss of funds. The rationale and implications of blacklisting the contract address should be thoroughly documented and verified.
IssueThe `initializeV2_1` function performs two highly impactful operations: it transfers the entire balance of the token contract (`balances[address(this)]`) to a `lostAndFound` address, and then blacklists the token contract itself (`blacklisted[address(this)] = true`). If the `lostAndFound` address is incorrect, or if blacklisting the contract prevents it from performing necessary future operations (e.g., receiving tokens, interacting with other protocols), it could lead to a denial of service or loss of funds. The rationale and implications of blacklisting the contract address should be thoroughly documented and verified.
FixEnsure the `lostAndFound` address is correctly configured and immutable after initialization. Clearly document the intended purpose and long-term implications of blacklisting the token contract address. Verify that this action does not inadvertently break any existing or future integrations or functionalities of the token.
StatusUnresolved
Low

Checks-Effects-Interactions Pattern Violation in `initializeV2_1`

L-01The `initializeV2_1` function performs an internal `_transfer` to an external `lostAndFound` address before updating critical state variables (`blacklisted[address(this)]` and `_initializedVersion`). While `_transfer` is internal and less prone to reentrancy than direct external calls, the general security best practice (Checks-Effects-Interactions pattern) dictates that all state changes should occur before any external interactions. This minimizes the window for reentrancy or unexpected behavior if the external call were to trigger unforeseen side effects.
IssueThe `initializeV2_1` function performs an internal `_transfer` to an external `lostAndFound` address before updating critical state variables (`blacklisted[address(this)]` and `_initializedVersion`). While `_transfer` is internal and less prone to reentrancy than direct external calls, the general security best practice (Checks-Effects-Interactions pattern) dictates that all state changes should occur before any external interactions. This minimizes the window for reentrancy or unexpected behavior if the external call were to trigger unforeseen side effects.
FixReorder the operations within `initializeV2_1` to update `blacklisted[address(this)] = true` and `_initializedVersion = 2` *before* calling `_transfer(address(this), lostAndFound, lockedAmount)`. This adheres to the Checks-Effects-Interactions pattern, enhancing robustness.
StatusUnresolved
Low

Use of Older Solidity Compiler Version

L-02The contract is compiled with `pragma solidity 0.6.12`. While functional, this version is older. Newer Solidity versions (e.g., 0.8.x) introduce several security enhancements, such as default checked arithmetic for `uint256` operations (preventing overflow/underflow without explicit SafeMath calls), more explicit error handling, and improved gas optimizations. Sticking to older versions might miss out on these built-in security features and potential future compiler bug fixes.
IssueThe contract is compiled with `pragma solidity 0.6.12`. While functional, this version is older. Newer Solidity versions (e.g., 0.8.x) introduce several security enhancements, such as default checked arithmetic for `uint256` operations (preventing overflow/underflow without explicit SafeMath calls), more explicit error handling, and improved gas optimizations. Sticking to older versions might miss out on these built-in security features and potential future compiler bug fixes.
FixConsider upgrading the Solidity compiler version to a more recent stable release (e.g., 0.8.x). This would allow for the removal of explicit SafeMath library usage, simplifying the code and leveraging native compiler checks for arithmetic safety. Thorough testing would be required after such an upgrade.
StatusUnresolved
Info

Incomplete Source Code for Dependencies

I-01The provided source code for `FiatTokenV2` (the base contract) and parts of the `EIP712` library were truncated. This limits the ability to perform a complete and comprehensive security analysis, particularly regarding potential storage collisions in the upgradeable proxy context, or specific logic within the inherited token functionality (e.g., the exact implementation of `_transfer` or other critical functions).
IssueThe provided source code for `FiatTokenV2` (the base contract) and parts of the `EIP712` library were truncated. This limits the ability to perform a complete and comprehensive security analysis, particularly regarding potential storage collisions in the upgradeable proxy context, or specific logic within the inherited token functionality (e.g., the exact implementation of `_transfer` or other critical functions).
FixFor a full audit, ensure all dependent contract source codes are provided in their entirety. This allows for a complete analysis of inheritance, storage layout, and inter-contract interactions.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract demonstrates good architectural practices (7.1 Architecture) by inheriting from a base token contract and utilizing well-audited OpenZeppelin libraries for SafeMath and SafeERC20, mitigating common integer overflow/underflow and ERC-20 interaction issues (7.2 Code Security). However, the `initializeV2_1` function performs critical state changes, including transferring the contract's entire token balance and blacklisting the contract address itself. This logic, while potentially intentional for migration, introduces a medium technical risk if not perfectly executed or if its implications are misunderstood.

GovernanceMedium4/10

The contract relies on a centralized administrative model for upgrades and critical state changes, such as the `initializeV2_1` function which transfers contract-held tokens and blacklists the contract itself (7.5 Governance). This centralized control is typical for stablecoins but introduces a single point of failure. The economic implications (7.4 Economic) of blacklisting the contract itself require careful consideration to avoid unintended operational disruptions or interactions with external protocols (7.6 External).

UpgradesHigh1/10

The system employs a proxy pattern, allowing for future upgrades. The `FiatTokenV2_1` contract represents an upgrade, introducing the `initializeV2_1` function. This function is critical for the upgrade process (7.7 Upgrades) as it performs one-time setup, including transferring tokens and blacklisting the contract address. Proper execution and access control for this initialization are paramount to ensure upgrade safety and prevent misconfiguration, as a failure could lead to a bricked contract or loss of funds.

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

91.5% in top 10
1.0% in wallets90.5% in contracts
Effective Concentration37.2%

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

$99.04M across 28 pairs
AerodromeWETHanalysed$18.10M18.3%Uniswap v3WETH$12.15M12.3%AerodromeWETH$9.82M9.9%Uniswap v3WETH$8.85M8.9%Uniswap v3USDC$7.93M8.0%AerodromeUSDC$6.97M7.0%
Show 4 more pairsShow less
AerodromeUSDC$5.79M5.8%PancakeswapWETH$5.78M5.8%AerodromeUSDC$4.32M4.4%Uniswap v4USDC$3.89M3.9%

The 18 remaining pairs hold $15.44M between them and are not listed.

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 Holder4.1%

Key Addresses

11 addresses
Deployer
0xce97…4b05
Unlocked LP Held By
0x2cc5…121b0xd774…f6bc0x1c3b…bc2e0x1d8d…beb80xe73b…05ab0x67f5…30dc0x9ad5…f7d40x2ddd…30fc0xcb8f…879a0x4f9b…7941

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 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% (91.5% total → 37.2% effective; 1.0% in EOAs, 90.5% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 1 Medium finding(s) from audit
  • 2 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
EURCHigh RiskDotHigh RiskSekuya (SKYA)High RiskRibbita by Virtuals (TIBBIR)High RiskPromptHigh RiskCoinbase Wrapped XRP (CBXRP)High 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