Is Coinbase Wrapped XRP (CBXRP) Safe? Smart Contract Security Analysis

Security Checklist

1/5 checks passed

Contract VerifiedFail

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Audit History

1 audit on record

Jul 2486

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

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.

Final Recommendation: It is strongly recommended to transition critical administrative roles (owner, pauser, blacklister) and the proxy admin role from single EOAs to a robust multi-signature wallet or a well-tested DAO governance system. This would significantly reduce the risk of a single point of failure and enhance the overall security posture of the protocol. Additionally, for future upgrades, extreme caution must be exercised with the custom bit-packed storage layout to prevent data corruption.

Category Ratings

TechnicalHigh

2/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 fo

GovernanceHigh

1/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 poi

UpgradesHigh

2/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 poi

What Raised This Score

7 factors

Ownership NOT renounced — owner is an EOA (single private key)
Mintable supply — no cap found, dilution unbounded
Contract source NOT verified
Liquidity NOT locked (owner can withdraw — rug-pull risk)
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

Security Findings

5 total

2 High 1 Medium 1 Low 1 Info

H-01HighUnresolved

Centralized Upgrade Control by EOA Admin

The proxy contract's upgradeability is controlled by a single External Owned Account (EOA) at `0x7fec9bc54c94d4ed5d98bcfadaebcbc55aa0c24e`. 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.

Recommendation: Migrate 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.

H-02HighUnresolved

Centralized Administrative Control by EOA Owner

Critical administrative functions such as minting, burning, pausing, and blacklisting are controlled by a single EOA owner at `0x9c4955ad8b8ec15aea30fa7d751a59699c179144`. 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.

Recommendation: Transfer 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.

M-01MediumUnresolved

Complex Custom Bit-Packed Storage for Balances and Blacklisting

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

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

L-01LowUnresolved

Older Solidity Compiler Version

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

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

I-01InformationalUnresolved

Self-Blacklisting of Contract Address During Initialization

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

Recommendation: While 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.

Is Coinbase Wrapped XRP Safe? CBXRP