Is Bitway Token (BTW) Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med1 Low1 Info

High

Owner Can Indefinitely Extend Transfer Lockup Period

H-01The `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.

IssueThe `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.

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

StatusUnresolved

Medium

Inconsistent Whitelist Application for Minting and Burning

M-01The `_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.

IssueThe `_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.

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

StatusUnresolved

Low

Unused OpenZeppelin Pausable Import

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

IssueThe `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.

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

StatusUnresolved

Info

Complex and Potentially Misleading ETA Logic

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

IssueThe `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.

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

StatusUnresolved

Category Ratings

TechnicalLow8/10

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

GovernanceMedium5/10

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

UpgradesLow7/10

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.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

96.1% in top 10

10.7% in wallets85.5% in contracts

Effective Concentration44.9%

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.6K across 5 pairs

UniswapUSDTanalysed$39.3K UniswapUSDT$28.8K Pancakeswap v3WBNB$303 Pancakeswap v3USDT$99 Pancakeswap v3USDT$33

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 Holder21.5%

Top-3 Unlocked38.2%

Key Addresses

11 addresses

Deployer

0x1942…8419

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.

What Raised This Score

6 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

Is Bitway Token Safe?

Security Findings

Owner Can Indefinitely Extend Transfer Lockup Period

Inconsistent Whitelist Application for Minting and Burning

Unused OpenZeppelin Pausable Import

Complex and Potentially Misleading ETA Logic

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Frequently Asked Questions

Related Audits

Would You Like a More Detailed Audit of Bitway Token?