Quantum Audit Logo

Is XRP (Universal) Safe?

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

XRP (Universal) UXRP
0x2615…93ae
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 7d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The audit of the WrappedAssetV2 contract, deployed as an upgradeable BeaconProxy, reveals a robust technical foundation built on OpenZeppelin standards. However, the contract design incorporates significant centralization risks, particularly concerning token supply management (mint/burn) and user blacklisting. The custom storage slot implementation, while a valid pattern, introduces a high technical risk for future upgrades if not meticulously managed. These factors contribute to an overall High risk level.

1 Critical2 High1 Informational
Volume 24h
$107.5K
Liquidity
$1.03M
Price
$1.3900
Token Age
1y
Top 10 Holders
62.1%

Security Findings

1 Crit2 High1 Info
Critical

Centralized Blacklisting Capability

C-01The `RESPONDER_ROLE` has the authority to blacklist any user via the `setUserBlacklist` function. Blacklisted users are prevented from sending or receiving tokens, as enforced by the `_update` override. This grants a single role the power to censor transactions and effectively freeze user funds, posing a critical risk to user autonomy and fund accessibility (7.3 Access Control, 7.4 Economic).
IssueThe `RESPONDER_ROLE` has the authority to blacklist any user via the `setUserBlacklist` function. Blacklisted users are prevented from sending or receiving tokens, as enforced by the `_update` override. This grants a single role the power to censor transactions and effectively freeze user funds, posing a critical risk to user autonomy and fund accessibility (7.3 Access Control, 7.4 Economic).
FixEvaluate the necessity and scope of the blacklisting feature. If essential, consider implementing a multi-signature approval process for blacklisting actions or a time-locked mechanism to allow users to react. Ensure clear policies and transparency around blacklisting criteria and procedures. Consider emitting an event when a user is blacklisted or unblacklisted.
StatusUnresolved
High

Centralized Control over Token Supply

H-01The `mint` and `burn` functions are restricted to the `MERCHANT_CONTROLLER` address. This grants the `MERCHANT_CONTROLLER` complete control over the token's total supply, allowing arbitrary inflation or deflation. While this may be an intended design, it introduces a significant centralization risk where the integrity of the token's value is entirely dependent on the security and trustworthiness of the `MERCHANT_CONTROLLER` (7.4 Economic, 7.3 Access Control).
IssueThe `mint` and `burn` functions are restricted to the `MERCHANT_CONTROLLER` address. This grants the `MERCHANT_CONTROLLER` complete control over the token's total supply, allowing arbitrary inflation or deflation. While this may be an intended design, it introduces a significant centralization risk where the integrity of the token's value is entirely dependent on the security and trustworthiness of the `MERCHANT_CONTROLLER` (7.4 Economic, 7.3 Access Control).
FixIf centralized supply control is intended, ensure the `MERCHANT_CONTROLLER` is secured by a robust multi-signature wallet with strict operational policies. Consider implementing rate limits or time locks on minting/burning operations, or requiring governance approval for large supply changes, to mitigate risks associated with a compromised key.
StatusUnresolved
High

Custom Storage Slot Management for Upgrades

H-02The contract uses a custom storage slot (`WrappedAssetV2StorageLocation`) for its `WrappedAssetV2Storage` struct, accessed via inline assembly in `_getWrappedAssetV2Storage()`. While this pattern can be used for 'eternal storage,' it introduces a high risk of storage collisions if not meticulously managed. Any future upgrade that introduces new state variables or changes the storage layout without accounting for this fixed slot could lead to data corruption or unexpected behavior (7.1 Architecture, 7.7 Upgrades).
IssueThe contract uses a custom storage slot (`WrappedAssetV2StorageLocation`) for its `WrappedAssetV2Storage` struct, accessed via inline assembly in `_getWrappedAssetV2Storage()`. While this pattern can be used for 'eternal storage,' it introduces a high risk of storage collisions if not meticulously managed. Any future upgrade that introduces new state variables or changes the storage layout without accounting for this fixed slot could lead to data corruption or unexpected behavior (7.1 Architecture, 7.7 Upgrades).
FixEnsure that all future upgrades are thoroughly audited for storage layout compatibility, specifically verifying that no new state variables are introduced that would occupy or overlap with the `WrappedAssetV2StorageLocation`. Maintain clear documentation of the custom storage slot and its purpose. Consider using a more standard upgradeable storage pattern (e.g., `_gap` for OpenZeppelin contracts) if the custom slot is not strictly necessary for a specific architectural pattern.
StatusUnresolved
Info

Lack of Event Emission for Critical Actions

I-01The `setUserBlacklist` function, which performs a critical access control action by blacklisting or unblacklisting a user, does not emit an event. This makes it difficult for off-chain systems, such as block explorers, monitoring tools, or user interfaces, to track changes to the blacklist status of addresses (7.8 Operations).
IssueThe `setUserBlacklist` function, which performs a critical access control action by blacklisting or unblacklisting a user, does not emit an event. This makes it difficult for off-chain systems, such as block explorers, monitoring tools, or user interfaces, to track changes to the blacklist status of addresses (7.8 Operations).
FixEmit an event (e.g., `BlacklistStatusChanged(address indexed user, bool blacklisted, address indexed by)`) whenever `setUserBlacklist` is called. This improves transparency, auditability, and allows for easier off-chain monitoring and integration.
StatusUnresolved

Category Ratings

TechnicalHigh3/10

The contract leverages OpenZeppelin's upgradeable ERC20, ERC20Permit, and AccessControlDefaultAdminRules, ensuring a strong foundation for code security (7.2). The `MERCHANT_CONTROLLER` is correctly set as `immutable` in the constructor, and `_disableInitializers` is properly called. However, the use of a custom storage slot (`WrappedAssetV2StorageLocation`) for the `userBlacklist` via assembly introduces significant complexity and a high risk of storage collisions if not meticulously managed during future upgrades (7.1, 7.7).

GovernanceHigh1/10

The contract implements `AccessControlDefaultAdminRules` with an `ADMIN_TRANSFER_DELAY`, enhancing the security of role management, and the initial admin is a multisig (7.3, 7.5). However, the `RESPONDER_ROLE` possesses the power to blacklist any user, which prevents them from transferring or receiving tokens, posing a critical censorship and fund access risk (7.3, 7.4). Additionally, the `MERCHANT_CONTROLLER` has unrestricted ability to mint and burn tokens, granting centralized control over the token's total supply (7.4).

UpgradesHigh1/10

The contract is designed for upgradeability using the BeaconProxy pattern and OpenZeppelin's `Initializable` module, with proper initializer calls for inherited contracts (7.7). The `_disableInitializers()` call in the constructor correctly prevents re-initialization. A key concern is the custom storage slot (`WrappedAssetV2StorageLocation`) used for `WrappedAssetV2Storage`, which requires extremely careful management in all future upgrades to prevent storage collisions and state corruption (7.7).

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 TypeBeacon
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

62.1% in top 10
9.0% in wallets53.2% in contracts
Effective Concentration30.2%

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.07M across 12 pairs
Uniswap v3WETHanalysed$1.03M96.0%AerodromeWETH$41.5K3.9%Uniswap v3WETH$1.4K0.1%PancakeswapWETH$1620.0%Uniswap v4ETH$1050.0%Uniswap v4USDC$260.0%
Show 4 more pairsShow less
Aerodromedoginme$100.0%Uniswap v4USDC$50.0%Uniswap v4ETH$10.0%AerodromeVIRTUAL$00.0%

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

3 addresses
Deployer
0x693c…47a2
Unlocked LP Held By
0x2434…56f50x6313…1a60

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

What Raised This Score

10 factors
  • Ownership NOT renounced — Multisig (2-of-4)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Complex proxy pattern (BEACON)
  • Top-10 concentration > 30% (62.1% total → 30.2% effective; 9.0% in EOAs, 53.2% 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 = 96% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 96% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 2 High 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
ChipCritical Riskdefi-nativeCritical RiskVCATCritical RiskWrapped PROS (PROS)Critical RiskCortex (CX)Critical RiskThe White Wolf (WOLF)Critical Risk

Would You Like a More Detailed Audit of XRP (Universal)?

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

Get Detailed Audit