Quantum Audit Logo

Is ETHGas Safe?

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

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

ETHGas GWEI
0x3011…7d49
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive 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. 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.

1 Critical1 Medium1 Low1 Informational
Volume 24h
$10.8K
Liquidity
$21.6K
Price
$0.02472
Token Age
6mo
Top 10 Holders
96.7%

Security Findings

1 Crit1 Med1 Low1 Info
Critical

Irreversible Owner Assignment

C-01The `_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.
IssueThe `_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.
FixImplement 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.
StatusUnresolved
Medium

Centralized Control over Token Metadata

M-01The `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.
IssueThe `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.
FixConsider 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.
StatusUnresolved
Low

ERC-20 `approve` Race Condition

L-01The `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.
IssueThe `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.
FixWhile 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.
StatusUnresolved
Info

Missing `_beforeTokenTransfer` Hook

I-01The 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.
IssueThe 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.
FixConsider 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.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

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

GovernanceHigh1/10

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

UpgradesHigh1/10

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.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeBeacon
ImplementationVerified source

Holder Composition

96.7% in top 10
72.9% in wallets23.8% in contracts
Effective Concentration82.4%

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

$21.6K

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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

6 addresses
Deployer
0xf135…fe2e
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.

What Raised This Score

12 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

Related Audits

6 more on the record
Tesla, Inc. (TSLAB)Critical RiskBless Token (BLESS)Critical RiskMonkeyCritical RiskMonkeyCritical RiskACEToken (ACE)Critical RiskInvesqo QQQ (QQQB)Critical Risk

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