Quantum Audit Logo

Is Coinbase Wrapped XRP Safe?

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

Coinbase Wrapped XRP CBXRP
0xcb58…a4af
Base
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.
Last checked 18d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The FiatTokenV2_2 contract serves as the implementation logic for a fiat-backed ERC-20 token, deployed via a ZeppelinOS legacy proxy. The contract includes features such as blacklisting, pausing, and EIP-712 signed transactions (permit, transferWithAuthorization). While the core logic appears robust for its intended purpose, the audit identified significant centralization risks due to EOA control over critical administrative and upgrade functions. Additionally, a custom bit-packed storage solution for balances and blacklist states introduces complexity and potential upgrade risks.

2 High1 Medium1 Low1 Informational
Volume 24h
$2.82M
Liquidity
$880.0K
Price
$1.4400
Token Age
1y
Top 10 Holders
85.8%

Security Findings

2 High1 Med1 Low1 Info
High

Centralized Upgrade Control by EOA Admin

H-01The proxy contract's upgradeability is controlled by a single External Owned Account (EOA) at 0x7fec…c24e. If this EOA's private key is compromised, an attacker could unilaterally upgrade the contract to a malicious implementation, potentially leading to loss of funds or complete control over the token supply.
IssueThe proxy contract's upgradeability is controlled by a single External Owned Account (EOA) at . If this EOA's private key is compromised, an attacker could unilaterally upgrade the contract to a malicious implementation, potentially leading to loss of funds or complete control over the token supply.
FixMigrate the proxy admin role from a single EOA to a robust multi-signature wallet (e.g., Gnosis Safe) with a high threshold of signers, or a time-locked governance contract. This distributes control and adds a layer of security against a single point of failure.
StatusUnresolved
High

Centralized Administrative Control by EOA Owner

H-02Critical administrative functions such as minting, burning, pausing, and blacklisting are controlled by a single EOA owner at 0x9c49…9144. A compromise of this EOA would grant an attacker the ability to freeze user funds, manipulate token supply, or blacklist legitimate users, severely impacting the protocol's integrity and user trust.
IssueCritical administrative functions such as minting, burning, pausing, and blacklisting are controlled by a single EOA owner at . A compromise of this EOA would grant an attacker the ability to freeze user funds, manipulate token supply, or blacklist legitimate users, severely impacting the protocol's integrity and user trust.
FixTransfer ownership of critical administrative roles to a multi-signature wallet or a decentralized autonomous organization (DAO) governance system. Implement a timelock for sensitive operations to provide a delay for review and potential intervention.
StatusUnresolved
Medium

Complex Custom Bit-Packed Storage for Balances and Blacklisting

M-01The contract uses a custom storage pattern where `balanceAndBlacklistStates` stores both the account balance (lower 255 bits) and blacklist status (highest bit) in a single `uint256`. While this saves storage slots, it is a non-standard and complex design that increases the risk of subtle bugs, especially during future upgrades or if the bit manipulation logic is not perfectly maintained. Incorrect handling could lead to balance corruption or unintended blacklist states.
IssueThe contract uses a custom storage pattern where `balanceAndBlacklistStates` stores both the account balance (lower 255 bits) and blacklist status (highest bit) in a single `uint256`. While this saves storage slots, it is a non-standard and complex design that increases the risk of subtle bugs, especially during future upgrades or if the bit manipulation logic is not perfectly maintained. Incorrect handling could lead to balance corruption or unintended blacklist states.
FixEnsure rigorous testing and formal verification of any future contract upgrades that interact with `balanceAndBlacklistStates`. Document the storage layout meticulously. Consider refactoring to separate storage variables for balances and blacklist status in a future major upgrade, if gas costs allow, to improve clarity and reduce complexity.
StatusUnresolved
Low

Older Solidity Compiler Version

L-01The contract is compiled with Solidity version 0.6.12. While this version is stable, it predates several security enhancements and optimizations introduced in newer versions, particularly Solidity 0.8.0+, which includes built-in overflow/underflow checks for arithmetic operations by default.
IssueThe contract is compiled with Solidity version 0.6.12. While this version is stable, it predates several security enhancements and optimizations introduced in newer versions, particularly Solidity 0.8.0+, which includes built-in overflow/underflow checks for arithmetic operations by default.
FixConsider upgrading to a more recent and actively maintained Solidity compiler version (e.g., 0.8.x) in future contract iterations. This would leverage the latest compiler features, bug fixes, and built-in safety mechanisms, potentially reducing the attack surface.
StatusUnresolved
Info

Self-Blacklisting of Contract Address During Initialization

I-01The `initializeV2_2` function explicitly blacklists `address(this)` (the contract itself) after migrating deprecated blacklist accounts. This means the token contract address cannot hold or transfer tokens, as it will always be considered blacklisted.
IssueThe `initializeV2_2` function explicitly blacklists `address(this)` (the contract itself) after migrating deprecated blacklist accounts. This means the token contract address cannot hold or transfer tokens, as it will always be considered blacklisted.
FixWhile this might be an intentional design choice to prevent tokens from being locked in the contract, it's an unusual pattern. Ensure this behavior is clearly documented and understood by all stakeholders to avoid confusion or unexpected issues if tokens are accidentally sent to the contract address.
StatusUnresolved

Category Ratings

TechnicalMedium5/10

The contract demonstrates a robust implementation of EIP-712 signed transactions, including an anti-front-running check for `receiveWithAuthorization`. The `_chainId()` function correctly uses the `chainid()` opcode for domain separation (7.2 Code Security). However, the custom bit-packed storage for `balanceAndBlacklistStates` is a complex design choice that increases the risk of errors and makes future storage layout changes more challenging (7.1 Architecture).

GovernanceHigh1/10

The token design is highly centralized, with critical administrative functions such as minting, burning, pausing, and blacklisting controlled by a single EOA owner (7.3 Access Control, 7.5 Governance). This centralization is typical for fiat-backed stablecoins but represents a significant single point of failure. The blacklisting mechanism, while functional, grants substantial power to the owner (7.4 Economic).

UpgradesHigh1/10

The contract utilizes a ZeppelinOS legacy proxy pattern, which is a known and understood upgrade mechanism. The `initializeV2_2` function correctly prevents re-initialization (7.7 Upgrades). However, the upgrade process is entirely controlled by a single EOA proxy admin, posing a critical single point of failure. The custom bit-packed storage layout for balances and blacklist status introduces a high risk for storage collisions or corruption during future upgrades if not meticulously managed (7.7 Upgrades).

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

85.8% in top 10
1.7% in wallets84.1% in contracts
Effective Concentration35.3%

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

$1.49M across 22 pairs
AerodromeWETHanalysed$880.0K59.0%AerodromeWETH$148.6K10.0%AerodromecbBTC$123.7K8.3%PancakeswapWETH$102.2K6.8%Hydrex CLAMMWETH$94.2K6.3%Uniswap v3USDC$33.7K2.3%
Show 4 more pairsShow less
Uniswap v4USDC$19.2K1.3%PancakeswapcbBTC$18.6K1.2%Uniswap v4ETH$13.7K0.9%Uniswap v3cbBTC$12.8K0.9%

The 12 remaining pairs hold $45.3K 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 Holder99.9%
Top-3 Unlocked100.0%

Key Addresses

4 addresses
Deployer
0xc813…cdb1
Unlocked LP Held By
0x03e1…dab10x6932…1f9f0x6313…1a60

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

What Raised This Score

11 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% (85.8% total → 35.3% effective; 1.7% in EOAs, 84.1% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.9% (independent LP — depth risk, pool = 59% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 59% of DEX liquidity)
  • 2 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
ZestHigh RiskOMI Token (OMI)High RiskSilencio (SLC)High RiskRibbita by Virtuals (TIBBIR)High RiskPromptHigh RiskEURCHigh Risk

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

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

Get Detailed Audit