On-chain security analysis — is it a scam or legit?
BNB ChainThe provided code implements a standard ERC20 token with burnable functionality, largely based on OpenZeppelin contracts.
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 $11.4K 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.
0xb5e8…d2810x58ad…2cf20x556b…d59e0xbe8e…70640xca72…65450x3389…b8300x5753…89cf0xc12d…aa330x3b0f…c9460x8060…8defNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
_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.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.
Implement 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.
Unresolved
approve Race Conditionapprove 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.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.
While 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.
Unresolved
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.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.
Consider 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.
Unresolved
_beforeTokenTransfer Hook_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.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.
If 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.
Unresolved
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.
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.
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.
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.
It is strongly recommended to address the critical functional flaw regarding token minting.
A public or owner-restricted minting function must be implemented in a derived contract to allow for token creation and distribution. Additionally, consider implementing a mechanism to mitigate the ERC20 approve race condition, such as the approve(0) pattern. Ensure that any future extensions or integrations are thoroughly reviewed for potential security implications.
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.
The Trust Wallet (TWT) contract on BNB Chain is 0x4b0f1812e5df2a09796481ff14017e6005508003. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Quantum Audit's risk score for Trust Wallet is 55/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $1.98M.
As of Sep 4, 2026, the 10 largest holders own 80.1% of the supply. The Holders section on this page shows who they are by holder type.
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
