Quantum Audit Logo

Is Trust Wallet Safe?

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

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

Trust Wallet TWT
0x4b0f…8003
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The provided code implements a standard ERC20 token with burnable functionality, largely based on OpenZeppelin contracts. While it correctly uses `SafeMath` to prevent integer overflows/underflows, a critical functional flaw exists: there is no mechanism to mint new tokens, rendering the `_totalSupply` permanently zero and making the token unusable. This fundamental issue prevents the token from serving its intended purpose.

1 Critical1 Low2 Informational
Volume 24h
$302.0K
Liquidity
$616.7K
Price
$0.5938
Token Age
3y
Top 10 Holders
80.1%

Security Findings

1 Crit1 Low2 Info
Critical

No Minting Mechanism

C-01The `_mint` function is declared as `internal virtual` but is not called by any public or external function within the provided `ERC20` or `ERC20Burnable` contracts. This means that no tokens can ever be created, and the `_totalSupply` will perpetually remain zero. Consequently, the token cannot be distributed or used for any intended purpose, rendering the contract non-functional.
IssueThe `_mint` function is declared as `internal virtual` but is not called by any public or external function within the provided `ERC20` or `ERC20Burnable` contracts. This means that no tokens can ever be created, and the `_totalSupply` will perpetually remain zero. Consequently, the token cannot be distributed or used for any intended purpose, rendering the contract non-functional.
FixImplement a public or owner-restricted minting function in a derived contract that calls `_mint(address account, uint256 amount)` to allow for the creation and initial distribution of tokens. Ensure appropriate access control (e.g., `onlyOwner`) is applied to prevent unauthorized token inflation.
StatusUnresolved
Low

ERC20 `approve` Race Condition

L-01The standard ERC20 `approve` function is susceptible to a known front-running vulnerability. If a user attempts to change an allowance from a non-zero value to another non-zero value, a malicious actor could front-run the transaction, spend the original allowance, and then spend the newly approved allowance, effectively spending more than the user intended.
IssueThe standard ERC20 `approve` function is susceptible to a known front-running vulnerability. If a user attempts to change an allowance from a non-zero value to another non-zero value, a malicious actor could front-run the transaction, spend the original allowance, and then spend the newly approved allowance, effectively spending more than the user intended.
FixWhile this is a known ERC20 standard limitation, consider implementing a two-step approval process (e.g., setting allowance to zero before setting a new value) or using `increaseAllowance`/`decreaseAllowance` functions where possible, which are less susceptible to this specific race condition.
StatusUnresolved
Info

Older Solidity Compiler Version

I-01The contract is compiled with Solidity version 0.6.12. While `SafeMath` is used to mitigate integer overflow/underflow issues, newer compiler versions (e.g., 0.8.x and above) include built-in overflow and underflow checks by default, reducing reliance on external libraries for this specific security concern. Newer versions also offer other optimizations and security improvements.
IssueThe contract is compiled with Solidity version 0.6.12. While `SafeMath` is used to mitigate integer overflow/underflow issues, newer compiler versions (e.g., 0.8.x and above) include built-in overflow and underflow checks by default, reducing reliance on external libraries for this specific security concern. Newer versions also offer other optimizations and security improvements.
FixConsider upgrading to a more recent Solidity compiler version (e.g., 0.8.x) to benefit from built-in safety checks and other language improvements. If upgrading, ensure all arithmetic operations are reviewed as `SafeMath` would no longer be strictly necessary for overflow/underflow prevention.
StatusUnresolved
Info

Empty `_beforeTokenTransfer` Hook

I-02The `_beforeTokenTransfer` hook is an empty virtual function. While this is a common pattern for extensibility, it currently serves no functional purpose within the provided contracts. If custom logic (e.g., blacklisting, fees, snapshotting) is intended to be executed before or after token transfers, it would need to be implemented in a derived contract.
IssueThe `_beforeTokenTransfer` hook is an empty virtual function. While this is a common pattern for extensibility, it currently serves no functional purpose within the provided contracts. If custom logic (e.g., blacklisting, fees, snapshotting) is intended to be executed before or after token transfers, it would need to be implemented in a derived contract.
FixIf no custom logic is required for token transfers, this is acceptable. If future functionality is planned, ensure that any overrides of this hook in derived contracts are thoroughly tested and do not introduce new vulnerabilities or unexpected behavior.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical architecture (7.1) is a standard ERC20 implementation, leveraging battle-tested OpenZeppelin patterns and `SafeMath` for robust arithmetic operations (7.2 Code Security). However, a critical functional flaw exists where no public or internal function is provided to mint tokens, making the `_totalSupply` perpetually zero and rendering the token non-functional. Access control (7.3) for standard ERC20 functions is correctly implemented, but the absence of a minting mechanism is a significant oversight.

GovernanceHigh1/10

The contract, as a standalone ERC20 token, lacks explicit governance mechanisms (7.5). Economically (7.4), the token's design is fundamentally flawed as no tokens can ever be minted, meaning the `_totalSupply` will always be zero. This prevents any economic activity or utility for the token. There are no external dependencies (7.6) that introduce economic risk.

UpgradesMedium5/10

The contract is not designed to be upgradeable (7.7), which eliminates upgrade-specific risks such as proxy storage collisions or logic errors during upgrades. However, this also means that any identified vulnerabilities or functional flaws, such as the inability to mint tokens, are permanent and cannot be patched post-deployment. Operations (7.8) are limited to standard ERC20 functions.

Security Checklist

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

Holder Composition

80.1% in top 10
73.2% in wallets6.9% in contracts
Effective Concentration75.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

$1.98M across 30 pairs
Pancakeswap v3WBNBanalysed$616.7K31.1%Pancakeswap v2WBNB$370.3K18.7%Pancakeswap v1WBNB$369.1K18.6%Pancakeswap v3USDT$356.3K18.0%ApeswapWBNB$155.4K7.8%BiswapWBNB$63.2K3.2%
Show 4 more pairsShow less
UniswapUSDT$24.4K1.2%0x5539…9675WBNB$11.5K0.6%0x7810…197dWBNB$2.8K0.1%0x670f…FC31WBNB$2.3K0.1%

The 20 remaining pairs hold $11.4K 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 Holder98.3%
Top-3 Unlocked99.8%

Key Addresses

11 addresses
Deployer
0xb2df…d1cd
Unlocked LP Held By
0xb5e8…d2810x58ad…2cf20x556b…d59e0xbe8e…70640xca72…65450x3389…b8300x5753…89cf0xc12d…aa330x3b0f…c9460x8060…8def

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

What Raised This Score

7 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Top-10 concentration > 70% (80.1% total → 75.9% effective; 73.2% in EOAs, 6.9% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 98.3% (independent LP — depth risk, pool = 31% of DEX liquidity)
  • LP top3 unlocked holders = 99.8% (independent LP — depth risk, pool = 31% of DEX liquidity)
  • 1 Critical 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
BicatHigh Riskb-moneyHigh RiskSTABLEHigh RiskOLYHigh RiskVelvetHigh RiskUnibase (UB)High Risk

Would You Like a More Detailed Audit of Trust Wallet?

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

Get Detailed Audit