On-chain security analysis — is it a scam or legit?
This audit report is based on the provided contract address without access to its 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 4, 2026
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0x1623…ab5b0x1983…a2580x3dd5…599d0x72b5…5a230x170f…7cecNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
The contract source code for address was not provided. This prevents a detailed technical security assessment, including checks for common vulnerabilities like reentrancy, integer overflows/underflows, denial-of-service, and logic errors (7.2 Code Security).
Always provide verified source code for any smart contract intended for public deployment or audit. This enables a comprehensive review of the contract's logic and security posture.
Unresolved
Without the contract's source code, it is impossible to verify the implementation of access control mechanisms (7.3 Access Control) and identify any privileged functions. This includes assessing whether critical operations are adequately protected, if ownership is properly managed, or if there are potential single points of failure.
Implement robust access control using established patterns (e.g., OpenZeppelin's Ownable or AccessControl). Clearly define and document all privileged roles and their associated permissions. Ensure multi-signature wallets are used for critical administrative actions.
Unresolved
The absence of source code and project context prevents any assessment of economic (7.4), governance (7.5), external (7.6), and upgradeability (7.7) risks. This includes potential for oracle manipulation, flash loan attacks, governance centralization, or unsafe upgrade paths. Operational aspects (7.8) also remain unverified.
Provide comprehensive documentation detailing the protocol's economic model, governance structure, external dependencies, and upgrade strategy. For upgradeable contracts, ensure a secure proxy pattern is used and thoroughly tested.
Unresolved
This audit report is based on the provided contract address without access to its source code. Therefore, a comprehensive security analysis could not be performed. The findings below highlight general security considerations that would typically be assessed, but their applicability and resolution status remain unverified.
Due to the absence of contract source code, a comprehensive technical security analysis (7.1 Architecture, 7.2 Code Security, 7.3 Access Control) could not be performed. Therefore, specific vulnerabilities such as reentrancy, integer overflows, or improper access control mechanisms cannot be identified or confirmed. General best practices for secure smart contract development are assumed but unverified.
Without access to the contract's source code and broader protocol documentation, an assessment of economic (7.4) and governance (7.5) risks is not possible. This includes analysis of tokenomics, incentive mechanisms, potential for oracle manipulation, or governance attack vectors. External dependencies (7.6) and their associated risks also remain unexamined.
The upgradeability architecture (7.7) of the contract could not be determined without source code. This prevents an analysis of potential upgrade safety issues, such as storage collisions in proxy patterns or improper initialization logic. Operational aspects (7.8) related to contract administration and emergency procedures also remain unverified.
For any smart contract deployment, it is paramount to conduct a thorough security audit with full access to the source code.
This includes reviewing for common vulnerabilities, adherence to best practices, and a comprehensive understanding of the contract's intended functionality and interactions. Ensure robust testing, formal verification, and continuous monitoring are part of the development and deployment lifecycle.
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 Basehat contract on Base is 0xb2000000000000000000008c60669cc2bd524a01. 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 Basehat is 36/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Liquidity lock: Not locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $42.6K.
As of Sep 4, 2026, the 10 largest holders own 29.8% of the supply. The Holders section on this page shows who they are by holder type.
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
