Quantum Audit Logo
Launch App

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

Is Ethereum Token Safe?

ETHBNB Chain
Not verified This 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 Sep 4, 2026 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance2/10Upgrades3/10Checks passed4 of 7Findings1 Low · 4 Info5
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.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is an EOA
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 96.9%
  • LP top3 unlocked holders = 98.6%
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 44 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
12.2%Contracts43.2%Wallets44.6%Everyone else
12.2%43.2%Wallets44.6%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
55.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking12.2%
  • Walletsanonymous holders, free to sell43.2%
  • Everyone elsethe rest of the supply44.6%
Effective concentrationwhat the score reads48.1%
How holder types affect the score

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

Liquidity

as of audit · Sep 4$68.77M across 30 pairs
Show 4 more pairs

The 20 remaining pairs hold $8.56M between them and are not listed. The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$15.84MShare of depth23.0%
Top-1 Unlocked Holder96.9%
Top-3 Unlocked98.6%
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.

Security Findings

1 Low4 Info
Low

Centralized Control over Token Minting

The 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).L-01

Issue

The 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).

Fix

Clearly 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.

Status

Unresolved

Info

Outdated Solidity Compiler Version

The 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).I-01

Issue

The 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).

Fix

Consider 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.

Status

Unresolved

Info

Redundant External Functions

The 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).I-02

Issue

The 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).

Fix

Remove redundant external functions like getOwner() and decimals(). Users can directly query the owner() function or the public _decimals state variable.

Status

Unresolved

Info

Potential approve Race Condition (Mitigated)

The 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).I-03

Issue

The 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).

Fix

Educate 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.

Status

Unresolved

Info

Confusing Token Name and Symbol

The 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).I-04

Issue

The 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).

Fix

Consider 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.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical8/10Low risk

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.

Governance2/10High risk

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).

Upgrades3/10High risk

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.

Final RecommendationWhat to do about this score

It is recommended to carefully consider the implications of centralized minting power and establish clear operational guidelines for the owner's role.

For future deployments, consider migrating to a newer Solidity compiler version (e.g., 0.8.x) to leverage built-in safety features and gas optimizations. Review and remove any redundant external functions to optimize contract size and clarity.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age3y
Contract0x2170…33f8
Deployer0x88ef…0566
Badge for your website
Ethereum Token security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Aug 30, 202649Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Related Audits

6 more on the recordAll audits
CRYSTAL STONESBNB Chain49MediumUSELESS COINUSELESS · BNB Chain49MediumPepeBNB Chain49MediumBSquared TokenB2 · BNB Chain48MediumBrokBNB Chain48Mediumo1.exchangeO · BNB Chain50Medium

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 Is this your token? Publish your own audit on this page