Quantum Audit Logo

Is Litecoin Token Safe?

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

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

Litecoin Token LTC
0x4338…db94
BNB Chain
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.Own this token? Put it under verification →
Last checked today 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The BEP20BitcoinCash contract implements a standard BEP-20 token with owner-controlled minting and user-controlled burning. The contract utilizes SafeMath to prevent integer overflows/underflows and follows a basic Ownable access control pattern. Key findings include the use of an outdated Solidity compiler version, a significant naming inconsistency between the contract and token details, and some minor code redundancies. The owner's ability to mint new tokens introduces a centralized economic risk.

2 Medium2 Low2 Informational
Volume 24h
$312.5K
Liquidity
$216.8K
Price
$71.0330
Token Age
3y
Top 10 Holders
67.3%

Security Findings

2 Med2 Low2 Info
Medium

Outdated Solidity Compiler Version

M-01The contract is compiled with Solidity version `0.5.16`. While `SafeMath` is used to mitigate integer overflows/underflows, newer compiler versions (e.g., 0.8.x) include built-in overflow checks, improved security features, and various bug fixes and optimizations not present in older versions. Using an outdated compiler can expose the contract to potential, albeit unknown, vulnerabilities or inefficiencies.
IssueThe contract is compiled with Solidity version `0.5.16`. While `SafeMath` is used to mitigate integer overflows/underflows, newer compiler versions (e.g., 0.8.x) include built-in overflow checks, improved security features, and various bug fixes and optimizations not present in older versions. Using an outdated compiler can expose the contract to potential, albeit unknown, vulnerabilities or inefficiencies.
FixUpgrade the Solidity compiler version to a more recent and actively maintained release (e.g., `^0.8.0`). This will leverage modern security features, better gas optimizations, and address known compiler-specific issues.
StatusUnresolved
Medium

Naming Inconsistency Between Contract and Token Details

M-02The contract is named `BEP20BitcoinCash`, but its internal `_name` is initialized as 'Litecoin Token' and `_symbol` as 'LTC'. This discrepancy can lead to significant confusion for users, exchanges, and integration partners, potentially causing misidentification of the token or trust issues.
IssueThe contract is named `BEP20BitcoinCash`, but its internal `_name` is initialized as 'Litecoin Token' and `_symbol` as 'LTC'. This discrepancy can lead to significant confusion for users, exchanges, and integration partners, potentially causing misidentification of the token or trust issues.
FixEnsure consistency between the contract's name, its file name, and the token's `name()` and `symbol()` values. For example, if the intention is a Bitcoin Cash token, the `_name` should be 'Bitcoin Cash Token' and `_symbol` 'BCH'. If it's a Litecoin token, the contract name should reflect that.
StatusUnresolved
Low

Redundant Public Getters for State Variables

L-01The contract includes external functions `getOwner()` and `decimals()` which simply return the value of the public `owner()` function and the public state variable `_decimals` respectively. Since `owner()` is already public and `_decimals` is a public state variable, these explicit getter functions are redundant and add unnecessary bytecode and gas cost without providing additional functionality.
IssueThe contract includes external functions `getOwner()` and `decimals()` which simply return the value of the public `owner()` function and the public state variable `_decimals` respectively. Since `owner()` is already public and `_decimals` is a public state variable, these explicit getter functions are redundant and add unnecessary bytecode and gas cost without providing additional functionality.
FixRemove the redundant `getOwner()` and `decimals()` functions. Users can directly access the `owner()` function or the `_decimals` public state variable.
StatusUnresolved
Low

Unused Internal `_burnFrom` Functionality

L-02The contract defines an internal function `_burnFrom(address account, uint256 amount)` which allows burning tokens from an account with an allowance. However, this internal function is not called by any public or external function, meaning the `burnFrom` functionality (burning tokens on behalf of another user with their approval) is effectively unavailable to users. This represents a missing feature rather than a direct vulnerability.
IssueThe contract defines an internal function `_burnFrom(address account, uint256 amount)` which allows burning tokens from an account with an allowance. However, this internal function is not called by any public or external function, meaning the `burnFrom` functionality (burning tokens on behalf of another user with their approval) is effectively unavailable to users. This represents a missing feature rather than a direct vulnerability.
FixIf `burnFrom` functionality is intended, create a public or external function that calls `_burnFrom`. Otherwise, consider removing the unused internal function to reduce bytecode size and improve clarity.
StatusUnresolved
Info

Centralized Control via Owner Minting

I-01The `mint` function is restricted to the contract owner via the `onlyOwner` modifier. This allows the owner to increase the total supply of tokens at any time, potentially diluting the value for existing token holders. While this is a common design choice for certain token models, it introduces a centralized point of control and an economic risk.
IssueThe `mint` function is restricted to the contract owner via the `onlyOwner` modifier. This allows the owner to increase the total supply of tokens at any time, potentially diluting the value for existing token holders. While this is a common design choice for certain token models, it introduces a centralized point of control and an economic risk.
FixClearly communicate the owner's ability to mint new tokens to all prospective token holders. If a more decentralized approach is desired, consider implementing a timelock for minting operations, multi-signature control, or removing the minting capability entirely after an initial supply distribution.
StatusUnresolved
Info

`_msgData()` from `Context` is Unused

I-02The `Context` contract is inherited by `BEP20BitcoinCash`, which includes the internal function `_msgData()`. However, `_msgData()` is never called within the `BEP20BitcoinCash` contract. While this is a minor issue, it adds a small amount of unnecessary bytecode to the deployed contract.
IssueThe `Context` contract is inherited by `BEP20BitcoinCash`, which includes the internal function `_msgData()`. However, `_msgData()` is never called within the `BEP20BitcoinCash` contract. While this is a minor issue, it adds a small amount of unnecessary bytecode to the deployed contract.
FixIf `_msgData()` is not required for any functionality, consider removing the `Context` inheritance or ensuring that only necessary components are included to optimize bytecode size.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract demonstrates good security practices by utilizing SafeMath for all arithmetic operations, effectively preventing integer overflow/underflow vulnerabilities (7.2 Code Security). Standard BEP-20 functions are implemented correctly, and access control for sensitive operations like `mint` is properly enforced via the `onlyOwner` modifier (7.3 Access Control). However, the use of Solidity compiler version 0.5.16 is outdated, which may lack modern security features and optimizations (7.2 Code Security). Additionally, some functions like `getOwner()` and `decimals()` are redundant as their underlying state variables are already public (7.1 Architecture).

GovernanceHigh3/10

The contract implements an `Ownable` pattern, granting the deployer significant control over the token (7.5 Governance). Specifically, the owner has the exclusive ability to `mint` new tokens, which allows for flexible supply management but also introduces a centralized point of control and potential for token dilution (7.4 Economic). This design choice means token holders rely on the owner's integrity regarding supply increases. Renouncing ownership is possible, which could decentralize control if desired.

UpgradesHigh3/10

The contract is not designed with an upgradeability pattern (e.g., proxy contracts), meaning its logic cannot be modified after deployment (7.7 Upgrades). This provides immutability and predictability for users, as the contract's behavior is fixed. Consequently, there are no upgrade-related risks such as proxy misconfigurations or insecure upgrade paths. Any future changes would require deploying an entirely new contract.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

67.3% in top 10
61.5% in wallets5.8% in contracts
Effective Concentration63.8%

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.23M across 30 pairs
Pancakeswap v3WBNBanalysed$216.8K17.7%Pancakeswap v2VIN$167.8K13.7%Pancakeswap v2YFSX$133.6K10.9%Uniswap v2YFSX$123.5K10.1%Uniswap比特币$111.6K9.1%Pancakeswap v3USDT$88.2K7.2%
Show 4 more pairsShow less
UniswapUSDT$79.6K6.5%Squadswap v3WBNB$72.9K5.9%Pancakeswap v3USDT$55.2K4.5%UniswapXVS$34.7K2.8%

The 20 remaining pairs hold $142.8K 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 Holder48.3%
Top-3 Unlocked78.0%

Key Addresses

11 addresses
Deployer
0x88ef…0566
Unlocked LP Held By
0xeee1…284e0x556b…d59e0x1a2b…fec30xdc77…4eda0x65e9…16400xcdcf…e0340x4057…b53a0x76cf…e16d0xf3b8…5e060x21eb…9a5d

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

What Raised This Score

6 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 50% (67.3% total → 63.8% effective; 61.5% in EOAs, 5.8% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 2 Medium finding(s) from audit
  • 2 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
Infinity Ground AI (AIN)High RiskFinTech AI (FNA)High RiskSOCKHigh RiskTopazHigh RiskAnoma (XAN)Critical RiskPlasma (XPL)Critical Risk

Would You Like a More Detailed Audit of Litecoin Token?

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

Get Detailed Audit