Early-stage security check — honeypot & rug-pull analysis
This report is based on an audit request for a contract on the Base network.
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 2 remaining pairs hold $9 between them and are not listed. 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.
0x575e…fe98No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
The Solidity source code for the contract at was not provided for this audit. This prevents any form of static analysis, manual review, or dynamic testing of the contract's logic and security posture. Without source code, it is impossible to identify vulnerabilities such as reentrancy, integer overflows, access control flaws, or other critical issues.
Always provide the full Solidity source code for all contracts intended for audit. For deployed contracts, ensure the source code is publicly verified on the blockchain explorer (e.g., Etherscan, Basescan) to allow for community review and transparency.
Unresolved
The contract at is not verified on the Base blockchain explorer. This means that the deployed bytecode cannot be easily matched against human-readable Solidity code by the public or by security tools. Lack of verification significantly hinders transparency and trust.
It is strongly recommended to verify the contract's source code on the respective blockchain explorer. This allows users and auditors to confirm that the deployed bytecode matches the intended Solidity logic, enhancing transparency and trust in the contract's operations.
Unresolved
Due to the absence of source code, a comprehensive assessment for specific vulnerability patterns (e.g., reentrancy, front-running, flash loan attacks, oracle manipulation, access control bypasses, denial-of-service vectors) could not be conducted. The contract's security against these common attack vectors remains unknown.
A full security audit requires access to the complete source code. If the contract is critical, a post-deployment audit with source code verification is essential to ensure its resilience against known attack patterns.
Unresolved
Without the Solidity source code, the exact functionality, purpose, and intended interactions of the contract are entirely unknown. It is impossible to determine if it's a token, a vault, a lending pool, a governance contract, or any other DeFi primitive, which makes risk assessment impossible.
For any contract, clear documentation and publicly available source code are vital to communicate its intended functionality and allow users to understand its role within an ecosystem. This transparency builds user confidence and facilitates security reviews.
Unresolved
When source code is not provided or verified, there is a significant risk that the deployed bytecode could contain malicious or unintended logic. This could include backdoors, unauthorized fund transfers, or other harmful functionalities that are not apparent from external interactions alone.
Users should exercise extreme caution and avoid interacting with contracts that do not have publicly verified source code. Always assume the worst-case scenario when transparency is lacking, as malicious actors often hide their intentions in unverified code.
Unresolved
It is impossible to determine if the contract implements an upgradeable proxy pattern (e.g., UUPS, Transparent, Beacon) without its source code. This means the potential for future logic changes, and the associated risks (e.g., upgradeability governance, proxy admin control), cannot be assessed.
If the contract is intended to be upgradeable, its proxy pattern and upgrade mechanisms should be clearly documented and verifiable through source code. This includes the roles and procedures for initiating and executing upgrades, which should ideally involve robust governance or multi-signature controls.
Unresolved
This report is based on an audit request for a contract on the Base network. No Solidity source code was provided for analysis, preventing a comprehensive security assessment. The contract at 0xb20000000000000000000000c6f9024862c6fb01 is unverified on-chain. Therefore, this report cannot identify specific vulnerabilities or provide detailed technical insights into its functionality or security posture.
Due to the absence of Solidity source code, a technical analysis of the contract's architecture (7.1), code security (7.2), and access control mechanisms (7.3) could not be performed. Without the source, it is impossible to assess common vulnerabilities like reentrancy, integer overflows, or logic flaws. The contract's bytecode is deployed, but its functionality remains opaque.
Without access to the contract's source code, an evaluation of its economic model (7.4) and governance structure (7.5) is not possible. It is unknown if the contract interacts with external protocols (7.6), has any tokenomics, or is controlled by a multi-sig or DAO. The potential for oracle manipulation or flash loan attacks cannot be assessed.
The upgradeability status (7.7) of the contract cannot be determined without its source code. It is unknown if the contract implements a proxy pattern (e.g., UUPS, Transparent) or if its logic can be modified post-deployment. This also prevents an assessment of operational risks (7.8) related to upgrade paths or administrative controls.
For any smart contract interaction, it is crucial to ensure that the contract's source code is publicly verified on the blockchain explorer.
Users should exercise extreme caution when interacting with unverified contracts, as their functionality and security cannot be independently audited. Always prioritize transparency and review comprehensive audit reports from reputable firms before engaging with decentralized applications.
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 Baseline contract on Base is 0xb20000000000000000000000c6f9024862c6fb01. 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 Baseline is 29/100 (Low 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: $62.2K.
As of Sep 4, 2026, the 10 largest holders own 22.8% 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
