Quantum Audit Logo
Launch App

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

Is Bitway Token Safe?

BTWBNB 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 · 2 audits on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance5/10Upgrades7/10Checks passed3 of 5Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The BitwayToken contract implements an ERC20 token with custom transfer restrictions based on a timestamp and a whitelist.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — strong Multisig (4-of-6)
  • Top-10 concentration > 30% (96.1% total → 44.9% effective; 10.7% in EOAs, 85.5% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 1 High 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 43 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
85.5%Contracts10.7%Wallets3.9%
85.5%Contracts10.7%3.9%
ContractsWalletsEveryone elseBubble area = share of supply
96.1%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking85.5%
  • Walletsanonymous holders, free to sell10.7%
  • Everyone elsethe rest of the supply3.9%
Effective concentrationwhat the score reads44.9%
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.6K across 5 pairs

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$39.3KShare of depth57.4%
Top-1 Unlocked Holder21.5%
Top-3 Unlocked38.2%
Unlocked LP held by
0x1fb6…8fc00x2b87…1f400x3fe9…f2fe0xac30…0ae10xa5f3…4cf20xe81e…53040x9489…57370x611c…fba10x2adc…50480xddec…cb52

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

Security Findings

1 High1 Medium1 Low1 Info
High

Owner Can Indefinitely Extend Transfer Lockup Period

The setTransferAllowedTimestamp function's logic for ETA (Estimated Time of Arrival) does not consistently restrict the owner's ability to extend the transferAllowedTimestamp. If the current transferAllowedTimestamp is still in the future (transferAllowedTimestamp > block.timestamp), the owner can set a newTimestamp arbitrarily far into the future without any ETA constraint. This allows the owner to indefinitely postpone the lifting of transfer restrictions for non-whitelisted users, effectively freezing token liquidity at will.H-01

Issue

The setTransferAllowedTimestamp function's logic for ETA (Estimated Time of Arrival) does not consistently restrict the owner's ability to extend the transferAllowedTimestamp. If the current transferAllowedTimestamp is still in the future (transferAllowedTimestamp > block.timestamp), the owner can set a newTimestamp arbitrarily far into the future without any ETA constraint. This allows the owner to indefinitely postpone the lifting of transfer restrictions for non-whitelisted users, effectively freezing token liquidity at will.

Fix

Modify the setTransferAllowedTimestamp function to ensure that the ETA mechanism or a similar constraint applies consistently, regardless of whether the current transferAllowedTimestamp is in the past or future. For example, always enforce a maximum extension period or introduce a timelock for changes that extend the lockup. Consider a governance mechanism or a fixed, non-extendable lockup period if decentralization is a goal.

Status

Unresolved

Medium

Inconsistent Whitelist Application for Minting and Burning

The _update function, which enforces the transfer lockup and whitelist, contains a conditional check: if (from != address(0)) { require(whitelist[from], "Not allowed"); }. This means that when from is address(0) (as in _mint operations), the whitelist check is bypassed. However, for burn operations, where from is _msgSender(), the whitelist check *is* applied. This design choice means that during the restricted period, tokens can be minted to any address, but burning tokens requires the burner to be whitelisted. While potentially intentional, this inconsistency could lead to user confusion or unexpected behavior if not clearly documented.M-01

Issue

The _update function, which enforces the transfer lockup and whitelist, contains a conditional check: if (from != address(0)) { require(whitelist[from], "Not allowed"); }. This means that when from is address(0) (as in _mint operations), the whitelist check is bypassed. However, for burn operations, where from is _msgSender(), the whitelist check *is* applied. This design choice means that during the restricted period, tokens can be minted to any address, but burning tokens requires the burner to be whitelisted. While potentially intentional, this inconsistency could lead to user confusion or unexpected behavior if not clearly documented.

Fix

Clearly document the specific behavior of the whitelist for both minting and burning operations in the contract's NatSpec and external documentation. If this behavior is not intentional, adjust the _update logic to apply the whitelist consistently or as desired for all from addresses, or consider if burn should also bypass the whitelist if _mint does.

Status

Unresolved

Low

Unused OpenZeppelin Pausable Import

The Pausable contract from OpenZeppelin is imported in BitwayToken.sol but is not inherited or used anywhere within the contract. This results in unnecessary code being included in the contract's dependencies.L-01

Issue

The Pausable contract from OpenZeppelin is imported in BitwayToken.sol but is not inherited or used anywhere within the contract. This results in unnecessary code being included in the contract's dependencies.

Fix

Remove the unused import {Pausable} from "@openzeppelin/contracts/utils/Pausable.sol"; statement to reduce contract size and improve code clarity.

Status

Unresolved

Info

Complex and Potentially Misleading ETA Logic

The ETA (Estimated Time of Arrival) logic within the setTransferAllowedTimestamp function is somewhat complex, involving conditional checks based on transferAllowedTimestamp > block.timestamp and ETA == 0. This complexity, combined with the high-severity issue of potential bypass, makes the function harder to reason about and increases the risk of misinterpretation or future vulnerabilities.I-01

Issue

The ETA (Estimated Time of Arrival) logic within the setTransferAllowedTimestamp function is somewhat complex, involving conditional checks based on transferAllowedTimestamp > block.timestamp and ETA == 0. This complexity, combined with the high-severity issue of potential bypass, makes the function harder to reason about and increases the risk of misinterpretation or future vulnerabilities.

Fix

Refactor the setTransferAllowedTimestamp function to simplify the ETA logic. Consider using clearer variable names, adding comments to explain complex conditions, or breaking down the logic into smaller, more manageable parts. Ensure the intended behavior of ETA is explicitly and unambiguously enforced.

Status

Unresolved

Analysis

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

The BitwayToken contract implements an ERC20 token with custom transfer restrictions based on a timestamp and a whitelist. The contract utilizes OpenZeppelin's Ownable and ERC20Permit. A significant finding is the owner's ability to indefinitely extend the transfer lockup period, posing a high centralization risk. Other findings include a nuanced whitelist application for minting vs. burning, and minor code quality issues. The owner is a multisig, which is a positive security practice for critical operations.

Technical8/10Low risk

The BitwayToken contract is built upon well-audited OpenZeppelin libraries (ERC20, Ownable, ERC20Permit), which contributes to a solid foundation (7.2 Code Security). The custom _update logic correctly enforces the transfer lockup and whitelist conditions. However, the setTransferAllowedTimestamp function's ETA mechanism is complex and contains a logic flaw that allows the owner to bypass its intended restriction (7.2 Code Security). Additionally, the Pausable contract is imported but not utilized, adding unnecessary complexity (7.1 Architecture).

Governance5/10Medium risk

The contract exhibits a high degree of centralization, with the owner having significant control over token transferability (7.3 Access Control). Specifically, the owner can indefinitely extend the transferAllowedTimestamp as long as the current timestamp is in the future, effectively controlling when non-whitelisted users can transfer tokens (7.4 Economic). While the owner is a multisig, which mitigates single-point-of-failure risk (7.5 Governance), the extensive power over token liquidity remains a concern. The whitelist mechanism also grants the owner full control over who can bypass transfer restrictions (7.3 Access Control).

Upgrades7/10Low risk

The BitwayToken contract is not designed with an upgrade mechanism (7.7 Upgrades). This means its logic is immutable once deployed, eliminating risks associated with proxy patterns or upgradeability flaws. Any future changes would require a new contract deployment and migration of assets, which should be considered in long-term planning.

Final RecommendationWhat to do about this score

It is strongly recommended to address the high-severity issue regarding the owner's ability to indefinitely extend the transfer lockup period.

This could involve redesigning the setTransferAllowedTimestamp function to ensure the ETA mechanism consistently limits the owner's power, or by implementing a timelock for such critical changes. Additionally, clearly document the whitelist behavior for minting and burning to manage user expectations. Consider removing unused imports to streamline the codebase.

Contract & Record

2 audits on record
TypeBitwayToken
NetworkBNB Chain
Token age4mo
Contract0x4440…acaa
Deployer0x1942…8419
Badge for your website
Bitway 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. Sep 4, 202639Medium
  2. Jul 27, 202654Medium
  3. Jul 27, 202661Medium

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

Frequently Asked Questions

Is Bitway Token a scam?

Based on automated analysis, Bitway Token scores 61/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is Bitway Token safe to buy?

Our scanner flagged a risk score of 61/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has Bitway Token been audited?

The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

6 more on the recordAll audits
MarsCoinBNB Chain39MediumCZ'S DOGBROCCOLI · BNB Chain39MediumCharacterXCAI · BNB Chain39Medium永生果蝇果蝇 · BNB Chain39MediumFetchFET · BNB Chain39MediumR2BNB Chain39Medium

Would You Like a More Detailed Audit of Bitway 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