Is Bnb Tiger Inu (BNBTIGER) a Scam? Security Analysis

Security Findings

1 High1 Med1 Low

High

Denial of Service via Ownable.lock()

H-01The `lock()` function in the `Ownable` contract sets the `_owner` to `address(0)` for a specified duration. During this period, any function protected by the `onlyOwner` modifier will be inaccessible. If critical administrative functions (e.g., pausing transfers, adjusting fees, emergency withdrawals) rely on `onlyOwner` permissions, the protocol could experience a denial of service, preventing essential operations or responses to emergencies.

IssueThe `lock()` function in the `Ownable` contract sets the `_owner` to `address(0)` for a specified duration. During this period, any function protected by the `onlyOwner` modifier will be inaccessible. If critical administrative functions (e.g., pausing transfers, adjusting fees, emergency withdrawals) rely on `onlyOwner` permissions, the protocol could experience a denial of service, preventing essential operations or responses to emergencies.

FixAssess all owner-restricted functions in the main contract. If any are critical for ongoing operations or emergency responses, consider alternative access control mechanisms (e.g., time-locked multi-signature, governance vote) that remain functional during the lock period, or ensure the lock period is only applied when no critical owner actions are anticipated.

StatusUnresolved

Medium

Single Point of Failure for Ownership Recovery

M-01The `unlock()` function, which restores ownership after a `lock()` period, can only be called by the `_previousOwner` address. This creates a single point of failure. If the `_previousOwner` address is compromised, lost, or becomes inaccessible (e.g., if it's a contract that cannot initiate the call), the contract could remain permanently locked, or ownership could be transferred to an unauthorized entity after the lock period expires.

IssueThe `unlock()` function, which restores ownership after a `lock()` period, can only be called by the `_previousOwner` address. This creates a single point of failure. If the `_previousOwner` address is compromised, lost, or becomes inaccessible (e.g., if it's a contract that cannot initiate the call), the contract could remain permanently locked, or ownership could be transferred to an unauthorized entity after the lock period expires.

FixImplement a more robust ownership recovery mechanism. Consider using a multi-signature wallet for the `_previousOwner` or a time-locked recovery process that allows a community or a set of trusted parties to regain control, rather than relying on a single address.

StatusUnresolved

Low

Misleading Error Message in unlock()

L-01The `unlock()` function includes a revert message `"Contract is locked until 7 days"`. However, the actual lock duration (`_lockTime`) is dynamically set by the `time` parameter passed to the `lock()` function, not a fixed 7 days. This hardcoded message can be misleading to users regarding the actual remaining lock period.

IssueThe `unlock()` function includes a revert message `"Contract is locked until 7 days"`. However, the actual lock duration (`_lockTime`) is dynamically set by the `time` parameter passed to the `lock()` function, not a fixed 7 days. This hardcoded message can be misleading to users regarding the actual remaining lock period.

FixUpdate the error message to accurately reflect the dynamic nature of the lock time. For example, remove the specific '7 days' reference or dynamically include the actual unlock timestamp in the error message.

StatusUnresolved

Category Ratings

TechnicalLow9/10

The technical architecture leverages standard libraries like SafeMath and Address, which enhance code security by preventing common integer vulnerabilities. The `Ownable` contract implements a `lock` mechanism, which temporarily transfers ownership to the zero address, preventing any owner-only operations during the lock period. This design introduces a potential denial of service for critical administrative functions (7.3 Access Control, 7.8 Operations). Additionally, the `unlock` function relies on a single `_previousOwner` to regain control, creating a single point of failure (7.2 Code Security).

GovernanceHigh3/10

The governance model, as defined by the `Ownable` contract, is highly centralized, with a single owner controlling all administrative functions. The `lock` mechanism, while intended to temporarily decentralize control, effectively halts all owner-dependent operations, potentially impacting the protocol's economic stability if critical parameters need adjustment during the lock period (7.4 Economic, 7.5 Governance). The reliance on a single `_previousOwner` for unlocking also presents a significant governance risk if that address is compromised or becomes inaccessible.

UpgradesLow7/10

The provided contract is not designed with an upgrade mechanism (7.7 Upgrades), meaning its logic cannot be modified after deployment. This eliminates upgrade-related risks such as proxy implementation mismatches or insecure upgrade paths. However, it also means any discovered vulnerabilities or desired feature enhancements would require a complete redeployment.

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

HoneypotNoneBuy Tax0.1%Sell Tax0.1%

Holder Composition

69.3% in top 10

63.1% in wallets6.2% in contracts

Effective Concentration65.6%

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

$1.16M across 30 pairs

Pancakeswap v2WBNBanalysed$1.16M Pancakeswap v2USDT$306 Pancakeswap v3USDT$281 UniswapUSDC$221 UniswapUSDT$153 UniswapUSDC$139

Show 4 more pairsShow less

UniswapWBNB$136 Pancakeswap v3WBNB$127 Uniswap v2WBNB$91 Uniswap v2USDC$72

The 20 remaining pairs hold $122 between them and are not listed.

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

LP Burned99.9% · ≈ permanent lock

LP Locked99.9%

Key Addresses

10 addresses

Deployer

0x7444…513f

Unlocked LP Held By

0x0fc5…fe6b0xf864…bb410x00f2…3b7b0x4875…8bfa0x0ed9…97060xef05…bf610xf0ab…79970xda1b…24670xfed1…4d87

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

What Raised This Score

5 factors

Ownership NOT renounced — owner is an EOA (single private key)
Top-10 concentration > 50% (69.3% total → 65.6% effective; 63.1% in EOAs, 6.2% in contracts — heavy)
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 Bnb Tiger Inu a Scam?

Security Findings

Denial of Service via Ownable.lock()

Single Point of Failure for Ownership Recovery

Misleading Error Message in unlock()

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Bnb Tiger Inu?