Early-stage security check — honeypot & rug-pull analysis
BNB ChainThis report is generated without access to the smart contract source code.
Read the full analysisEach 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 5, 2026
The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
The audit was requested for a contract address () on the BSC network, but no corresponding Solidity source code was provided for analysis. This prevents any meaningful security assessment of the contract's implementation.
Always provide the full and verified source code for all contracts intended for audit. This includes all dependent libraries and imported contracts. Ensure the provided source code matches the deployed bytecode on the blockchain.
Unresolved
Without the source code, it is impossible to evaluate critical technical security aspects such as reentrancy vulnerabilities, integer overflows/underflows, access control flaws (7.3 Access Control), potential denial-of-service vectors, or adherence to secure coding best practices (7.2 Code Security). The contract's architecture (7.1 Architecture) also remains unverified.
Ensure that all smart contracts are developed following established security patterns and best practices. Conduct thorough internal code reviews and static analysis before submitting for external audit. Focus on robust input validation, secure state transitions, and proper error handling.
Unresolved
The absence of source code precludes any analysis of the contract's economic model (7.4 Economic), including tokenomics, fee structures, and incentive mechanisms. Similarly, the governance framework (7.5 Governance) and its associated risks, such as centralized control or upgrade path vulnerabilities (7.7 Upgrades), cannot be assessed.
Design economic models with careful consideration of potential attack vectors and long-term sustainability. Implement transparent and decentralized governance mechanisms where appropriate. For upgradeable contracts, ensure the upgrade process is secure, well-documented, and communicated to users.
Unresolved
This report is generated without access to the smart contract source code. Therefore, a comprehensive security audit could not be performed. The findings below reflect the inability to conduct a proper analysis rather than specific vulnerabilities within the contract. All risk levels are set to 'Low' by default due to the absence of code for evaluation.
Without the contract's source code, a detailed technical assessment of 7.1 Architecture, 7.2 Code Security, and 7.3 Access Control cannot be performed. Key areas like reentrancy protection, integer overflow/underflow, and proper access control mechanisms could not be verified. Adherence to secure coding practices is paramount for smart contract integrity.
The economic model (7.4 Economic) and governance structure (7.5 Governance) of the protocol could not be evaluated due to the absence of source code. This prevents analysis of tokenomics, fee structures, incentive mechanisms, and decision-making processes. Robust economic design and transparent governance are crucial for long-term protocol stability and user trust.
An assessment of the upgradeability mechanism (7.7 Upgrades) was not possible without the contract's source code. This includes verifying the use of secure proxy patterns (e.g., UUPS, Transparent) and ensuring proper initialization and storage slot management. Secure upgrade paths are vital for future protocol evolution and bug fixes.
For any smart contract deployment, it is critical to undergo a thorough security audit by independent experts.
Ensure all source code is publicly available and verified against deployed bytecode. Implement robust testing, including unit, integration, and fuzz testing, to cover all possible execution paths. Establish a clear incident response plan and consider bug bounty programs to incentivize community-driven security research.
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 TrustCat contract on BNB Chain is 0x75b364916b65f1e8959fa0210a6922c2ee237777. 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 TrustCat is 0/100 (Low risk) as of Sep 5, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 3% / 3%. 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 5, 2026). Total DEX liquidity: $67.8K.
As of Sep 5, 2026, the 10 largest holders own 28.4% of the supply. The Holders section on this page shows who they are by holder type.
This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.
Get Detailed Audit Is this your token? Publish your own audit on this page
