Quantum Audit Logo
Launch App

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

Is ETHGas Safe?

GWEIBNB 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
Critical RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades1/10Checks passed1 of 5Findings1 Critical · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The audit of the BridgeToken implementation contract identified a critical access control vulnerability: the contract owner, who controls minting, burning, and metadata updates, cannot be changed after initialization.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a contract
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Complex proxy pattern
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 Critical finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Complex proxy pattern (BEACON)
  • Top-10 concentration > 70% (96.7% total → 82.4% effective; 72.9% in EOAs, 23.8% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($21,598 across 1 pairs — thin market)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 1 Critical finding(s) from audit
  • 1 Medium 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

Security Checklist

as of audit · Sep 41 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
23.8%Contracts72.9%Wallets3.3%
23.8%Contracts72.9%Wallets
ContractsWalletsEveryone elseBubble area = share of supply
96.7%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking23.8%
  • Walletsanonymous holders, free to sell72.9%
  • Everyone elsethe rest of the supply3.3%
Effective concentrationwhat the score reads82.4%
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$21.6K

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$21.6KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x3b28…6f570x6458…2df50xa5b8…f6780xfacd…2a140x66a9…44fb

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

Security Findings

1 Critical1 Medium1 Low1 Info
Critical

Irreversible Owner Assignment

The _state.owner variable, which controls critical functions like mint, burn, and updateDetails, is set only during the initialize function and lacks any mechanism (e.g., transferOwnership) to change it. This means the initial owner address is permanently fixed.C-01

Issue

The _state.owner variable, which controls critical functions like mint, burn, and updateDetails, is set only during the initialize function and lacks any mechanism (e.g., transferOwnership) to change it. This means the initial owner address is permanently fixed.

Fix

Implement a robust ownership management mechanism, such as inheriting from OpenZeppelin's Ownable and including transferOwnership and renounceOwnership functions. For critical roles, consider using a multi-signature wallet or a well-tested governance contract to manage ownership.

Status

Unresolved

Medium

Centralized Control over Token Metadata

The updateDetails function allows the owner to change the token's name and symbol at any time. While this might be intended for a bridge token to reflect changes on the native chain, it introduces a centralization risk where the owner can arbitrarily change the token's identity, potentially misleading users or exchanges.M-01

Issue

The updateDetails function allows the owner to change the token's name and symbol at any time. While this might be intended for a bridge token to reflect changes on the native chain, it introduces a centralization risk where the owner can arbitrarily change the token's identity, potentially misleading users or exchanges.

Fix

Consider if this functionality is strictly necessary. If so, ensure robust governance or multi-sig control over the owner address. Document this capability clearly for users and integrate it into the protocol's risk disclosure.

Status

Unresolved

Low

ERC-20 approve Race Condition

The approve function, like all standard ERC-20 approve implementations, is susceptible to a known front-running attack where a user's allowance can be manipulated if they approve a new amount before the spender spends the old amount. This can lead to the spender having access to an unintended amount.L-01

Issue

The approve function, like all standard ERC-20 approve implementations, is susceptible to a known front-running attack where a user's allowance can be manipulated if they approve a new amount before the spender spends the old amount. This can lead to the spender having access to an unintended amount.

Fix

While not a critical vulnerability, users should be aware of this ERC-20 standard limitation. Encourage the use of increaseAllowance and decreaseAllowance functions, which mitigate this risk, instead of direct approve calls when adjusting allowances.

Status

Unresolved

Info

Missing _beforeTokenTransfer Hook

The contract implements core ERC-20 logic directly without inheriting from OpenZeppelin's ERC20 contract. This means it lacks the _beforeTokenTransfer and _afterTokenTransfer hooks, which are useful for adding custom logic (e.g., blacklisting, fee mechanisms, snapshotting) in future upgrades without modifying core transfer logic.I-01

Issue

The contract implements core ERC-20 logic directly without inheriting from OpenZeppelin's ERC20 contract. This means it lacks the _beforeTokenTransfer and _afterTokenTransfer hooks, which are useful for adding custom logic (e.g., blacklisting, fee mechanisms, snapshotting) in future upgrades without modifying core transfer logic.

Fix

Consider inheriting from OpenZeppelin's ERC20 contract or implementing similar internal hooks if future extensibility for custom transfer logic is desired. This can improve modularity and upgradeability.

Status

Unresolved

Analysis

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

The audit of the BridgeToken implementation contract identified a critical access control vulnerability: the contract owner, who controls minting, burning, and metadata updates, cannot be changed after initialization. This poses a severe operational and security risk. Other findings include centralized control over metadata, standard ERC-20 approve race condition, and missing transfer hooks. The contract generally exhibits good code quality and utilizes state separation for upgradeability.

Technical4/10Medium risk

The contract demonstrates good architectural practices by separating state into TokenState and utilizing OpenZeppelin libraries for secure primitives (7.1 Architecture, 7.2 Code Security). However, a critical flaw exists in access control (7.3 Access Control) where the owner, responsible for minting and burning, is permanently fixed after initialization, lacking any transfer mechanism. Additionally, the contract implements ERC-20 logic directly, missing potential extensibility hooks (7.2 Code Security).

Governance1/10High risk

The economic model centers on an owner-controlled mint/burn mechanism, which is typical for a bridge token (7.4 Economic). However, the inability to transfer ownership (7.5 Governance) creates a single point of failure; compromise or loss of the owner's key would permanently disable critical token functions. The owner also has the ability to update token metadata (name, symbol), introducing a centralization risk (7.4 Economic).

Upgrades1/10High risk

The contract is designed as an upgradeable implementation for a Beacon Proxy, correctly using an initializer modifier and separating state into TokenState, which are strong practices for upgrade safety (7.7 Upgrades). However, the critical issue of an irreversible owner directly impacts future upgrade paths and operational continuity (7.8 Operations), as any change to ownership would necessitate a full contract upgrade rather than a simple ownership transfer.

Final RecommendationWhat to do about this score

It is imperative to address the critical issue of irreversible ownership.

Implement a robust ownership management system, preferably using a multi-signature wallet or a well-audited governance contract for the owner role, to ensure operational continuity and security. Review the necessity of the updateDetails function and consider if its control should also be subject to multi-sig or governance. Adopting OpenZeppelin's ERC20 base contract could provide additional security features and extensibility.

Contract & Record

1 audit on record
TypeBridgeToken
NetworkBNB Chain
Token age6mo
Contract0x3011…7d49
Deployer0xf135…fe2e
Proxy Upgrade Controls
Proxy TypeBeacon
ImplementationVerified source
Badge for your website
ETHGas 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 11, 202694Critical

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

Related Audits

6 more on the recordAll audits
Tesla, Inc. TSLAB · BNB Chain96CriticalBless TokenBLESS · BNB Chain97CriticalCircle Internet Group Inc.CRCLB · BNB Chain91CriticalMonkeyBNB Chain90CriticalMonkeyBNB Chain90CriticalACETokenACE · BNB Chain98Critical

Would You Like a More Detailed Audit of ETHGas?

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