On-chain security analysis — is it a scam or legit?
BNB ChainThe BEP20XRP token contract implements a standard BEP20 token with minting and burning capabilities.
Read the full analysisEach 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
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.
Holder balances as recorded by the audit of Sep 4, 2026
The 20 remaining pairs hold $311.3K between them and are not listed. The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0x3cdf…fcc50xa5f8…76520x73fe…e24e0x07b8…707a0xe76d…7d510xe5cf…d7bc0x7793…d63b0xb8e0…42900xcf06…dba10xaac5…c39bNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
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).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).
If 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.
Unresolved
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).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).
Consider 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.
Unresolved
_burnFrom_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).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).
Either 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.
Unresolved
getOwner() FunctionBEP20XRP 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).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).
The 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.
Unresolved
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.
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).
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.
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.
It is strongly recommended to carefully consider the implications of the centralized minting authority.
If the intention is for a fixed or capped supply, the mint function should be removed or its functionality restricted. For long-term projects, consider migrating to a newer Solidity version (0.8.x+) to leverage built-in safety features and gas optimizations. Ensure the owner's private key is secured with multi-signature wallets or robust operational procedures.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.
Get Detailed Audit Is this your token? Publish your own audit on this page
