Honeypot, rug-pull and ownership checks
BNB ChainThis audit covers the provided Solidity code snippets, primarily focusing on the Ownable contract and common libraries.
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
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
The 20 remaining pairs hold $122 between them and are not listed. The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
0x0fc5…fe6b0xf864…bb410x00f2…3b7b0x4875…8bfa0x0ed9…97060xef05…bf610xf0ab…79970xda1b…24670xfed1…4d87No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
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.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.
Assess 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.
Unresolved
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.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.
Implement 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.
Unresolved
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.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.
Update 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.
Unresolved
This audit covers the provided Solidity code snippets, primarily focusing on the Ownable contract and common libraries. The core token contract implementation (BNBTiger) was not provided, limiting the scope of the analysis to general patterns and the Ownable logic. Key findings include potential denial of service due to the lock mechanism in Ownable and a single point of failure for regaining ownership.
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).
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.
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.
It is recommended to carefully review the Ownable contract's lock and unlock mechanisms.
Consider implementing a multi-signature wallet for ownership to mitigate the single point of failure risk. Ensure that all critical administrative functions are designed to either operate autonomously during a lock period or have a robust, multi-party recovery mechanism. Additionally, clarify or remove the misleading error message in the unlock function.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
The Bnb Tiger Inu (BNBTIGER) contract on BNB Chain is 0xac68931b666e086e9de380cfdb0fb5704a35dc2d. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Quantum Audit's risk score for Bnb Tiger Inu is 32/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 9% / 9%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $1.16M.
As of Sep 4, 2026, the 10 largest holders own 69.3% of the supply. The Holders section on this page shows who they are by holder type.
Paste the contract address into our AI-powered scanner for a deeper real-time report — free, with every scoring factor shown.
Get Detailed Audit Is this your token? Publish your own audit on this page
