Quantum Audit Logo
Launch App

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

Is Coinbase Wrapped BTC Safe?

CBBTCArbitrum
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
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades1/10Checks passed1 of 5Findings1 Critical · 1 High · 1 Medium · 1 Low · 1 Info5
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.

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
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 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% (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

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
20.7%Contracts30.1%Wallets49.2%Everyone else
20.7%Contracts30.1%Wallets49.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
50.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking20.7%
  • Walletsanonymous holders, free to sell30.1%
  • Everyone elsethe rest of the supply49.2%
Effective concentrationwhat the score reads38.4%
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$893.6K 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$776.1KShare of depth86.8%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0xbe2f…1b54

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

Security Findings

1 Critical1 High1 Medium1 Low1 Info
Critical

Lack of Access Control on initializeV2_1 Function

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

Issue

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

Fix

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

Status

Unresolved

High

Critical State Changes in Unprotected initializeV2_1

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

Issue

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

Fix

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

Status

Unresolved

Medium

Incomplete Audit Scope (Missing FiatTokenV2 Source)

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

Issue

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

Fix

Provide the complete source code for all inherited contracts (FiatTokenV2 and any further dependencies) for a full security assessment of the entire system.

Status

Unresolved

Low

Use of Older Solidity Version and OpenZeppelin Libraries

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

Issue

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

Fix

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

Status

Unresolved

Info

Deliberate Blacklisting of Contract Address

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical4/10Medium risk

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.

Governance1/10High risk

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

Upgrades1/10High risk

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.

Final RecommendationWhat to do about this score

Immediately implement robust access control (e.g., onlyOwner or onlyProxyAdmin) for the initializeV2_1 function to prevent unauthorized execution of critical state changes.

Ensure that the lostAndFound address is a secure, multi-signature controlled wallet. Conduct a full audit of the FiatTokenV2 base contract to identify any underlying vulnerabilities that could impact the overall system.

Contract & Record

1 audit on record
TypeFiatTokenProxy
NetworkArbitrum
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, 202674High

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

Related Audits

6 more on the recordAll audits
InfiniIFN · Arbitrum74HighEuniceEUIAI · Arbitrum74HighChipArbitrum73HighTHEA FinanceTHEA · Arbitrum73HighNeoSoulNEOS · Arbitrum73HighAgentumAGT · Arbitrum76High

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