Quantum Audit Logo

Is XRP Token Safe?

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

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

XRP Token XRP
0x1d2f…0dbe
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The BEP20XRP token contract implements a standard BEP20 token with minting and burning capabilities. It utilizes SafeMath for arithmetic safety and the Ownable pattern for access control. A significant economic risk is identified due to the owner's ability to mint an unlimited supply of tokens, which could lead to inflation or value dilution.

1 High1 Low2 Informational
Volume 24h
$450.7K
Liquidity
$1.31M
Price
$1.4500
Token Age
3y
Top 10 Holders
65.6%

Security Findings

1 High1 Low2 Info
High

Centralized Minting Authority

H-01The `mint` function is restricted to the contract owner via the `onlyOwner` modifier. This allows the owner to mint an arbitrary amount of new tokens at any time, increasing the total supply without limit. This centralized control over token supply introduces a significant economic risk, as it can lead to inflation, dilution of existing token holders' value, and potential for abuse if the owner's key is compromised or misused (7.4 Economic, 7.5 Governance).
IssueThe `mint` function is restricted to the contract owner via the `onlyOwner` modifier. This allows the owner to mint an arbitrary amount of new tokens at any time, increasing the total supply without limit. This centralized control over token supply introduces a significant economic risk, as it can lead to inflation, dilution of existing token holders' value, and potential for abuse if the owner's key is compromised or misused (7.4 Economic, 7.5 Governance).
FixIf the token is intended to have a fixed or capped supply, the `mint` function should be removed entirely or modified to enforce a maximum total supply. If minting is a necessary feature, consider implementing a multi-signature wallet for the owner address or integrating a decentralized governance mechanism to approve minting operations.
StatusUnresolved
Low

Outdated Solidity Compiler Version

L-01The contract is compiled with Solidity version 0.5.16. While `SafeMath` is used to prevent integer overflows/underflows, newer Solidity versions (e.g., 0.8.x and above) include built-in overflow and underflow checks by default, making `SafeMath` largely redundant and potentially saving gas. Using an older compiler version may also miss out on recent compiler optimizations, bug fixes, and security enhancements (7.2 Code Security).
IssueThe contract is compiled with Solidity version 0.5.16. While `SafeMath` is used to prevent integer overflows/underflows, newer Solidity versions (e.g., 0.8.x and above) include built-in overflow and underflow checks by default, making `SafeMath` largely redundant and potentially saving gas. Using an older compiler version may also miss out on recent compiler optimizations, bug fixes, and security enhancements (7.2 Code Security).
FixConsider upgrading the contract to a more recent Solidity compiler version (e.g., 0.8.x). This would allow for the removal of the `SafeMath` library, simplifying the code and potentially reducing gas costs, while benefiting from the latest language features and security improvements.
StatusUnresolved
Info

Unused Internal Function `_burnFrom`

I-01The contract defines an internal function `_burnFrom(address account, uint256 amount)` which allows burning tokens from an account's balance and simultaneously reducing the allowance. However, this function is never called anywhere within the `BEP20XRP` contract. This means the functionality to burn tokens on behalf of another address (similar to `transferFrom`) is implemented but not exposed (7.2 Code Security).
IssueThe contract defines an internal function `_burnFrom(address account, uint256 amount)` which allows burning tokens from an account's balance and simultaneously reducing the allowance. However, this function is never called anywhere within the `BEP20XRP` contract. This means the functionality to burn tokens on behalf of another address (similar to `transferFrom`) is implemented but not exposed (7.2 Code Security).
FixEither remove the `_burnFrom` function if its functionality is not intended to be used, or expose it via a public function (e.g., `burnFrom(address account, uint256 amount)`) if it is a desired feature. Removing unused code can slightly reduce contract size and improve clarity.
StatusUnresolved
Info

Redundant `getOwner()` Function

I-02The `BEP20XRP` contract implements an external view function `getOwner()` which simply returns the result of the inherited `owner()` function from the `Ownable` contract. This `getOwner()` function is redundant as the `owner()` function already provides the same functionality and is publicly accessible (7.2 Code Security).
IssueThe `BEP20XRP` contract implements an external view function `getOwner()` which simply returns the result of the inherited `owner()` function from the `Ownable` contract. This `getOwner()` function is redundant as the `owner()` function already provides the same functionality and is publicly accessible (7.2 Code Security).
FixThe `getOwner()` function can be safely removed without affecting contract functionality, as `owner()` already serves its purpose. This would slightly reduce contract size and improve code clarity.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract exhibits good technical security practices, including the consistent use of SafeMath to prevent integer overflows/underflows (7.2 Code Security). The implementation of BEP20 standards is correct, and there are no apparent reentrancy vulnerabilities (7.2 Code Security). However, the use of an older Solidity compiler version (0.5.16) means it does not benefit from modern compiler optimizations and built-in safety features (7.2 Code Security).

GovernanceHigh1/10

The contract's economic model presents a high risk due to the owner's unrestricted ability to mint new tokens (7.4 Economic). The `mint` function, protected by `onlyOwner`, allows the total supply to be increased arbitrarily, which could lead to significant inflation and dilution of existing token holders' value (7.5 Governance). While the `Ownable` pattern provides clear access control, this centralized power over supply is a critical economic consideration.

UpgradesHigh3/10

This contract is not designed to be upgradeable, as it does not implement any proxy pattern (7.7 Upgrades). Therefore, there are no upgrade-specific risks associated with its deployment. Any changes to the contract's logic would require a new deployment and migration of assets, if applicable.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

65.6% in top 10
62.7% in wallets2.9% in contracts
Effective Concentration63.9%

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

$4.77M across 30 pairs
Pancakeswap v3WBNBanalysed$1.31M27.6%Pancakeswap v3USDT$1.25M26.3%UniswapUSDT$501.9K10.5%Pancakeswap v3ETH$442.9K9.3%Pancakeswap v3BTCB$288.3K6.0%Unchain-xWBNB$243.5K5.1%
Show 4 more pairsShow less
UniswapWBNB$143.2K3.0%UniswapETH$110.3K2.3%Uniswap比特币$94.3K2.0%BiswapWBNB$67.0K1.4%

The 20 remaining pairs hold $311.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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

11 addresses
Deployer
0x88ef…0566
Unlocked LP Held By
0x3cdf…fcc50xa5f8…76520x73fe…e24e0x07b8…707a0xe76d…7d510xe5cf…d7bc0x7793…d63b0xb8e0…42900xcf06…dba10xaac5…c39b

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

What Raised This Score

8 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 50% (65.6% total → 63.9% effective; 62.7% in EOAs, 2.9% in contracts — heavy)
  • 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 = 28% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 28% of DEX liquidity)
  • 1 High 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
Starpower Network (STAR)High RiskBTR token (BTR)High RiskBNB Attestation (BAS)High RiskCaldera (ERA)High Risk0GHigh RiskFilecoin (FIL)High Risk

Would You Like a More Detailed Audit of XRP Token?

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

Get Detailed Audit