Quantum Audit Logo
Launch App

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

Is Coinbase Wrapped BTC Safe?

CBBTCBase
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
Technical7/10Governance4/10Upgrades1/10Checks passed1 of 5Findings1 Medium · 2 Low · 1 Info4
SummaryAI Copilot

This audit covers the FiatTokenV2_1 contract, which serves as an implementation for an upgradeable proxy.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is an EOA
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Admin is EOA
  • Top-10 concentration > 30%
  • 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
Exact 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

Security Checklist

as of audit · Sep 41 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
90.5%Contracts8.5%Everyone else
90.5%Contracts8.5%
ContractsWalletsEveryone elseBubble area = share of supply
91.5%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking90.5%
  • Walletsanonymous holders, free to sell1.0%
  • Everyone elsethe rest of the supply8.5%
Effective concentrationwhat the score reads37.2%
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$99.04M across 28 pairs
Show 4 more pairs

The 18 remaining pairs hold $15.44M between them and are not listed. 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$18.10MShare of depth18.3%
Top-1 Unlocked Holder4.1%
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.

Security Findings

1 Medium2 Low1 Info
Medium

Critical State Changes in initializeV2_1

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

Issue

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

Fix

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

Status

Unresolved

Low

Checks-Effects-Interactions Pattern Violation in initializeV2_1

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

Issue

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

Fix

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

Status

Unresolved

Low

Use of Older Solidity Compiler Version

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

Issue

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

Fix

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

Status

Unresolved

Info

Incomplete Source Code for Dependencies

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical7/10Low risk

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.

Governance4/10Medium risk

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

Upgrades1/10High risk

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.

Final RecommendationWhat to do about this score

Thoroughly review the design implications of blacklisting the token contract itself and ensure this aligns with all intended operational scenarios and external integrations.

Implement robust access control and multi-signature protection for the initializeV2_1 function to prevent unauthorized or erroneous execution. Consider upgrading to a more recent Solidity compiler version to benefit from enhanced security features and optimizations.

Contract & Record

1 audit on record
TypeFiatTokenProxy
NetworkBase
Token age1y
Contract0xcbb7…33bf
Deployer0xce97…4b05
Proxy Upgrade Controls
Proxy TypeZeppelin Os Legacy
AdminEOA (single key controls upgrades)
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Coinbase Wrapped BTC 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. Aug 11, 202655Medium

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

Related Audits

6 more on the recordAll audits
EURCBase55MediumDotBase55MediumSekuyaSKYA · Base55Medium717ai by VirtualsWIRE · Base55MediumMementoDEXTF · Base55MediumRibbita by VirtualsTIBBIR · Base56Medium

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 Is this your token? Publish your own audit on this page