Quantum Audit Logo

Is Circle Wrapped Bitcoin a Scam?

Early-stage security check — honeypot & rug-pull analysis

Is this your token? Publish your own audit on this page →

Circle Wrapped Bitcoin CIRBTC
0x72df…075e
Ethereum
Not verifiedThis 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 2d ago 1 audit on record New Launch · 4d old
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

This audit covers the FiatTokenV2_2 contract, which serves as the implementation logic for a proxy-based ERC-20 stablecoin. The contract introduces EIP-712 permit and authorization features, and a refined blacklisting mechanism that packs balance and blacklist status into a single storage slot. While the EIP-712 implementation appears robust and the bitwise operations for state packing are carefully handled, a significant risk lies in potential storage collisions during upgrades due to the altered storage layout. Centralized control is inherent to the stablecoin's design, and the contract's self-blacklisting behavior, while potentially intentional, warrants careful consideration.

1 High1 Medium1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (4d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$4.52M
Liquidity
$21.90M
Price
$80300.3200
Token Age
4d
Top 10 Holders
100.1%

Security Findings

1 High1 Med1 Low1 Info
High

Storage Collision Risk in Upgrade

H-01The `FiatTokenV2_2` contract introduces a new storage pattern where `balanceAndBlacklistStates` combines both the token balance and the blacklisted status into a single `uint256` using bitwise operations. If prior versions of the contract (e.g., `FiatTokenV2_1`, `FiatTokenV2`, `FiatTokenV1`) stored these two pieces of information in separate storage slots (e.g., `balances` mapping and `blacklisted` mapping), this change in storage layout could lead to a storage collision during an upgrade. A collision would result in data corruption, where existing balances or blacklist statuses are overwritten or misinterpreted, potentially leading to loss of funds or incorrect blacklisting.
IssueThe `FiatTokenV2_2` contract introduces a new storage pattern where `balanceAndBlacklistStates` combines both the token balance and the blacklisted status into a single `uint256` using bitwise operations. If prior versions of the contract (e.g., `FiatTokenV2_1`, `FiatTokenV2`, `FiatTokenV1`) stored these two pieces of information in separate storage slots (e.g., `balances` mapping and `blacklisted` mapping), this change in storage layout could lead to a storage collision during an upgrade. A collision would result in data corruption, where existing balances or blacklist statuses are overwritten or misinterpreted, potentially leading to loss of funds or incorrect blacklisting.
FixConduct a comprehensive storage layout analysis across all contract versions in the upgrade path to ensure that the introduction of `balanceAndBlacklistStates` does not conflict with previously used storage slots. If a conflict is identified, a migration strategy or a different storage layout for the new version must be implemented to preserve existing data integrity. This is critical for upgrade safety (7.7 Upgrades).
StatusUnresolved
Medium

Self-Blacklisting of Contract Address

M-01The `initializeV2_2` function explicitly blacklists the contract's own address (`_blacklist(address(this))`). While this might be an intentional design choice to prevent the token contract itself from holding tokens, it is an unusual pattern for an ERC-20 token. This could lead to unexpected behavior or operational limitations if future functionalities or integrations require the contract to temporarily hold or receive its own tokens. It also means the contract cannot be a recipient in any transfer, which might not be immediately obvious to external systems (7.8 Operations).
IssueThe `initializeV2_2` function explicitly blacklists the contract's own address (`_blacklist(address(this))`). While this might be an intentional design choice to prevent the token contract itself from holding tokens, it is an unusual pattern for an ERC-20 token. This could lead to unexpected behavior or operational limitations if future functionalities or integrations require the contract to temporarily hold or receive its own tokens. It also means the contract cannot be a recipient in any transfer, which might not be immediately obvious to external systems (7.8 Operations).
FixClearly document the rationale and implications of blacklisting the contract's own address. Ensure that all current and future operational requirements and integrations are compatible with this restriction. If the intent is solely to prevent the contract from holding tokens, consider alternative mechanisms that are less restrictive or more explicit in their purpose.
StatusUnresolved
Low

Centralized Control Over Critical Functions

L-01The contract, as part of a stablecoin system, relies on centralized control for critical functions such as pausing transfers, blacklisting accounts, and managing upgrades. Roles like `owner`, `pauser`, and `blacklister` (inherited from base contracts) possess significant power, including the ability to freeze user funds or prevent all token operations (7.3 Access Control, 7.5 Governance). While this is a common and often necessary design for stablecoins to ensure stability and compliance, it introduces a single point of failure and a high degree of trust in the controlling entities.
IssueThe contract, as part of a stablecoin system, relies on centralized control for critical functions such as pausing transfers, blacklisting accounts, and managing upgrades. Roles like `owner`, `pauser`, and `blacklister` (inherited from base contracts) possess significant power, including the ability to freeze user funds or prevent all token operations (7.3 Access Control, 7.5 Governance). While this is a common and often necessary design for stablecoins to ensure stability and compliance, it introduces a single point of failure and a high degree of trust in the controlling entities.
FixWhile centralization is inherent to this type of asset, consider implementing additional security measures for critical administrative roles, such as multi-signature wallets for ownership and key operational roles, and potentially time-locks for sensitive parameter changes or upgrade approvals. This enhances security by distributing control and providing a delay for review (7.5 Governance).
StatusUnresolved
Info

Complex Bitwise Operations for State Packing

I-01The contract utilizes bitwise operations to pack two distinct pieces of state (token balance and blacklisted status) into a single `uint256` variable (`balanceAndBlacklistStates`). Specifically, the highest bit (2^255) is used to indicate blacklisting, while the lower 255 bits store the balance. While this is an efficient storage optimization, it significantly increases the complexity of the code and the potential for subtle errors if not handled with extreme care (7.2 Code Security).
IssueThe contract utilizes bitwise operations to pack two distinct pieces of state (token balance and blacklisted status) into a single `uint256` variable (`balanceAndBlacklistStates`). Specifically, the highest bit (2^255) is used to indicate blacklisting, while the lower 255 bits store the balance. While this is an efficient storage optimization, it significantly increases the complexity of the code and the potential for subtle errors if not handled with extreme care (7.2 Code Security).
FixEnsure comprehensive unit and integration tests specifically cover all edge cases related to the bitwise operations, including maximum balance values, blacklisting/unblacklisting transitions, and concurrent operations. Maintain clear and detailed documentation explaining this storage mechanism to reduce the risk of future misinterpretations or errors during maintenance or upgrades.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract demonstrates robust implementation of EIP-712 permit and authorization functions, leveraging secure libraries like ECRecover and SignatureChecker (7.2 Code Security). The bitwise packing of balance and blacklist state is an efficient, albeit complex, design choice, with appropriate checks to prevent overflow (7.2 Code Security). However, the `initializeV2_2` function includes an unusual self-blacklisting mechanism for the contract address itself, which could lead to unexpected operational constraints (7.8 Operations).

GovernanceHigh1/10

As a stablecoin, the protocol exhibits a high degree of centralized control, with roles such as owner, pauser, and blacklister possessing significant authority over token operations, including freezing funds and managing upgrades (7.3 Access Control, 7.5 Governance). This centralization is typical for fiat-backed stablecoins, enabling rapid response to security incidents or regulatory requirements (7.4 Economic). However, it also introduces a single point of failure and a high degree of trust in the controlling entities (7.5 Governance).

UpgradesHigh1/10

The contract is designed as an upgradeable implementation for a proxy (7.1 Architecture). The `initializeV2_2` function includes a version check (`_initializedVersion == 2`) to prevent re-initialization, which is a good practice for upgrade safety (7.7 Upgrades). However, the introduction of the `balanceAndBlacklistStates` mapping, which combines two pieces of state using bitwise operations, poses a significant risk of storage collision if previous contract versions used separate storage slots for balances and blacklist status (7.7 Upgrades). Such a collision could lead to data corruption or loss during the upgrade process.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

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

Holder Composition

100.1% in top 10
52.3% in wallets47.8% in contracts
Effective Concentration71.5%

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

$33.45M across 7 pairs
Uniswap v3WBTCanalysed$21.90M65.5%Uniswap v3WETH$5.89M17.6%Uniswap v3USDC$5.66M16.9%

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
0xadb3…a9d1
Unlocked LP Held By
0xbea2…6c3c

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 > 70% (100.1% total → 71.5% effective; 52.3% in EOAs, 47.8% in contracts — extreme)
  • 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 = 65% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 65% of DEX liquidity)
  • Token age < 7 days (early, volatile)
  • 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
Gensyn (AI)Critical RiskSpark (SPK)Critical RiskEden Token (EDEN)Critical RiskZK Coin (ZKC)Critical RiskCOTICritical Riskdmt-natCritical Risk

Would You Like a More Detailed Audit of Circle Wrapped Bitcoin?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit