Quantum Audit Logo

Is Ethereum Token Safe?

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

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

Ethereum Token ETH
0x2170…33f8
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The BEP20Ethereum contract implements a standard BEP-20 token with minting and burning capabilities, utilizing the Ownable pattern for administrative control and SafeMath for arithmetic safety. The contract demonstrates good practices in preventing common integer overflow/underflow issues and includes functions to mitigate the approve race condition. However, the centralized control over token minting by the owner introduces a significant economic risk, as the total supply can be arbitrarily increased. Additionally, the use of an older Solidity compiler version and some redundant functions are noted as informational findings.

1 Low4 Informational
Volume 24h
$17.87M
Liquidity
$15.84M
Price
$2507.6500
Token Age
3y
Top 10 Holders
55.4%

Security Findings

1 Low4 Info
Low

Centralized Control over Token Minting

L-01The `mint` function is restricted to the contract owner via the `onlyOwner` modifier. This grants the owner the ability to arbitrarily increase the total supply of tokens. While a common design pattern for some tokens, this centralized control over supply can lead to token dilution, impact token economics, and represents a significant centralization risk (7.4 Economic, 7.5 Governance).
IssueThe `mint` function is restricted to the contract owner via the `onlyOwner` modifier. This grants the owner the ability to arbitrarily increase the total supply of tokens. While a common design pattern for some tokens, this centralized control over supply can lead to token dilution, impact token economics, and represents a significant centralization risk (7.4 Economic, 7.5 Governance).
FixClearly communicate the implications of centralized minting to token holders. If decentralization is a goal, consider implementing a timelock for minting operations, a multi-signature wallet for ownership, or a community-governed mechanism for supply adjustments. Alternatively, remove minting functionality if a fixed supply is desired.
StatusUnresolved
Info

Outdated Solidity Compiler Version

I-01The contract is compiled with Solidity version 0.5.16. While `SafeMath` is used to mitigate integer overflow/underflow, newer Solidity versions (e.g., 0.8.x and above) include built-in overflow/underflow checks by default, making `SafeMath` largely redundant and potentially reducing gas costs. Newer versions also offer various language improvements and optimizations (7.2 Code Security).
IssueThe contract is compiled with Solidity version 0.5.16. While `SafeMath` is used to mitigate integer overflow/underflow, newer Solidity versions (e.g., 0.8.x and above) include built-in overflow/underflow checks by default, making `SafeMath` largely redundant and potentially reducing gas costs. Newer versions also offer various language improvements and optimizations (7.2 Code Security).
FixConsider upgrading the Solidity compiler version to 0.8.x or higher for future deployments. This would allow for the removal of the `SafeMath` library, potentially reducing bytecode size and gas costs, and leveraging the latest compiler features and security enhancements.
StatusUnresolved
Info

Redundant External Functions

I-02The contract includes `getOwner()` and `decimals()` external view functions that simply return the values of `owner()` and `_decimals` respectively. These functions are redundant as the underlying state variables or `owner()` function are already publicly accessible. While not a security vulnerability, they add unnecessary bytecode and slightly increase deployment costs (7.2 Code Security).
IssueThe contract includes `getOwner()` and `decimals()` external view functions that simply return the values of `owner()` and `_decimals` respectively. These functions are redundant as the underlying state variables or `owner()` function are already publicly accessible. While not a security vulnerability, they add unnecessary bytecode and slightly increase deployment costs (7.2 Code Security).
FixRemove redundant external functions like `getOwner()` and `decimals()`. Users can directly query the `owner()` function or the public `_decimals` state variable.
StatusUnresolved
Info

Potential `approve` Race Condition (Mitigated)

I-03The standard `approve` function is susceptible to a front-running attack where a malicious spender could exploit a pending `approve` transaction to drain funds if the owner first approves X, then approves Y (where Y < X). However, the contract also provides `increaseAllowance` and `decreaseAllowance` functions. These functions are the recommended way to modify allowances safely by adding or subtracting from the current allowance, thereby mitigating the race condition (7.2 Code Security).
IssueThe standard `approve` function is susceptible to a front-running attack where a malicious spender could exploit a pending `approve` transaction to drain funds if the owner first approves X, then approves Y (where Y < X). However, the contract also provides `increaseAllowance` and `decreaseAllowance` functions. These functions are the recommended way to modify allowances safely by adding or subtracting from the current allowance, thereby mitigating the race condition (7.2 Code Security).
FixEducate users to primarily use `increaseAllowance` and `decreaseAllowance` instead of directly calling `approve` when modifying existing allowances. This best practice helps prevent potential front-running scenarios.
StatusUnresolved
Info

Confusing Token Name and Symbol

I-04The contract is named `BEP20Ethereum` and implements a BEP-20 token, but its internal `_name` is set to 'Ethereum Token' and `_symbol` to 'ETH'. This naming can be confusing, especially on a network like BSC, as it might be mistaken for the native Ethereum token or an official wrapped version, potentially leading to user errors or misinterpretations (7.6 External, 7.4 Economic).
IssueThe contract is named `BEP20Ethereum` and implements a BEP-20 token, but its internal `_name` is set to 'Ethereum Token' and `_symbol` to 'ETH'. This naming can be confusing, especially on a network like BSC, as it might be mistaken for the native Ethereum token or an official wrapped version, potentially leading to user errors or misinterpretations (7.6 External, 7.4 Economic).
FixConsider renaming the token's `_name` and `_symbol` to clearly distinguish it from the native Ethereum token or other established assets, especially given its deployment on the BSC network. This enhances clarity and reduces potential user confusion.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract exhibits strong technical security foundations (7.2 Code Security). It correctly implements the BEP-20 standard and uses the SafeMath library to prevent integer overflow/underflow vulnerabilities. The inclusion of `increaseAllowance` and `decreaseAllowance` functions helps mitigate the common `approve` race condition. However, the contract is compiled with an older Solidity version (0.5.16), which, while not inherently insecure due to SafeMath, could benefit from features and optimizations in newer versions.

GovernanceHigh2/10

The contract employs the Ownable pattern (7.3 Access Control), granting the deployer significant administrative control, including the ability to transfer or renounce ownership. A key economic risk (7.4 Economic) is the owner's exclusive power to mint new tokens via the `mint` function. This centralized control over supply can lead to token dilution and impact the token's value if misused. While common for some token designs, it represents a single point of failure and a potential governance concern (7.5 Governance).

UpgradesHigh3/10

The contract is not designed to be upgradeable (7.7 Upgrades), meaning its logic cannot be modified after deployment. This eliminates risks associated with upgrade mechanisms, such as proxy implementation vulnerabilities or improper upgrade paths. Any changes would require deploying a new contract and migrating assets, which is a standard approach for non-upgradeable tokens.

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

55.4% in top 10
43.2% in wallets12.2% in contracts
Effective Concentration48.1%

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

$68.77M across 30 pairs
Pancakeswap v3WBNBanalysed$15.84M23.0%Pancakeswap v3COSA$11.94M17.4%Uniswap比特币$9.07M13.2%UniswapWBNB$5.98M8.7%Pancakeswap v3USDT$5.23M7.6%Pancakeswap v3BTCB$4.01M5.8%
Show 4 more pairsShow less
Pancakeswap v2WBNB$3.13M4.6%Pancakeswap v2MGC$2.06M3.0%Pancakeswap v3USDT$1.53M2.2%Pancakeswap v2VIN$1.41M2.1%

The 20 remaining pairs hold $8.56M 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 Holder96.9%
Top-3 Unlocked98.6%

Key Addresses

11 addresses
Deployer
0x88ef…0566
Unlocked LP Held By
0x556b…d59e0x421a…99220xcde6…90d70xa986…62580xf04f…1eb20x19a7…b7190xcddb…e7600x801e…8aac0x6d59…f7ec0x184a…0656

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)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (55.4% total → 48.1% effective; 43.2% in EOAs, 12.2% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 96.9% (independent LP — depth risk, pool = 23% of DEX liquidity)
  • LP top3 unlocked holders = 98.6% (independent LP — depth risk, pool = 23% of DEX liquidity)
  • 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
CRYSTAL STONESHigh RiskUSELESS COIN (USELESS)High RiskBSquared Token (B2)High RiskBrokHigh Risko1.exchange (O)High RiskBaby Ansem (BABYANSEM)High Risk

Would You Like a More Detailed Audit of Ethereum Token?

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

Get Detailed Audit