On-chain security analysis — is it a scam or legit?
This audit was conducted without access to the contract's 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 6, 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.
0xd1c6…a0c0No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
The audit was conducted without access to the contract's Solidity source code. This severely limits the ability to perform a comprehensive security analysis, identify specific vulnerabilities (7.2 Code Security), or verify adherence to best practices. Users interacting with this contract cannot independently verify its logic or security properties.
It is strongly recommended to publish and verify the contract's source code on block explorers (e.g., Etherscan, Basescan). This enhances transparency, allows for community review, and enables thorough security audits.
Unresolved
Without source code, the access control mechanisms (7.3 Access Control) governing critical functions are unknown. Improper access control can lead to unauthorized state changes, fund manipulation, or denial-of-service attacks. It is unclear if roles are properly defined and enforced.
Implement robust access control using established patterns (e.g., OpenZeppelin's Ownable or AccessControl). Ensure that sensitive functions are restricted to authorized addresses and that ownership transfer processes are secure.
Unresolved
The presence and correctness of reentrancy protection mechanisms (7.2 Code Security) cannot be verified. Reentrancy vulnerabilities can allow an attacker to repeatedly call a function before the initial call has completed, leading to drained funds or unexpected state changes.
Always use the Checks-Effects-Interactions pattern and consider reentrancy guards (e.g., OpenZeppelin's ReentrancyGuard) for any function that performs external calls and modifies state.
Unresolved
The contract's handling of arithmetic operations (7.2 Code Security) is unknown. Without source code, it's impossible to confirm if integer overflow/underflow vulnerabilities are mitigated, which could lead to incorrect calculations, unexpected state, or fund loss.
Utilize Solidity versions 0.8.0 and above, which include default overflow/underflow checks. For older versions, use SafeMath libraries or similar constructs to prevent these issues in all arithmetic operations.
Unresolved
Any interactions with external contracts (7.6 External) or addresses are unknown. Improper handling of external calls can introduce various risks, including reentrancy, unexpected reverts, or gas limit issues. The contract's resilience to malicious external contracts cannot be assessed.
When making external calls, minimize trust in the callee. Isolate external calls to the end of functions, handle potential reverts gracefully, and implement reentrancy protection. Consider using call limits or whitelists for trusted external contracts.
Unresolved
The operational security practices (7.8 Operations) for managing the contract, such as multi-signature wallets for critical operations, emergency pause mechanisms, or upgrade procedures, are unknown. Lack of robust operational security can expose the protocol to single points of failure or slow response times during incidents.
Implement multi-signature wallets for critical administrative functions. Consider an emergency pause mechanism for rapid response to exploits. Establish clear operational procedures for upgrades, parameter changes, and incident response.
Unresolved
This audit was conducted without access to the contract's source code. Therefore, a comprehensive security analysis for vulnerabilities such as reentrancy, access control flaws, or integer issues could not be performed. The findings are informational and based on general best practices for EVM smart contracts.
Without access to the contract's source code (7.2 Code Security), a detailed technical analysis is not possible. Therefore, no specific architectural patterns (7.1 Architecture) or code-level vulnerabilities can be identified. General best practices for EVM contracts regarding reentrancy and integer safety are assumed to be critical for any deployed contract.
The economic model (7.4 Economic) and governance structure (7.5 Governance) cannot be assessed without contract source code or external documentation. Access control mechanisms (7.3 Access Control) are also unknown. Any contract handling significant value should implement robust economic incentives and decentralized governance where appropriate.
The upgradeability status (7.7 Upgrades) of the contract is unknown without source code. If the contract is upgradeable, proper proxy patterns (e.g., UUPS, Transparent) and safe upgrade procedures are crucial to prevent critical vulnerabilities. If not upgradeable, immutability provides security but lacks flexibility.
For any smart contract deployment, it is paramount to ensure that the source code is publicly verified and audited by reputable security firms.
Without source code, users interact with the contract at their own risk, as no security guarantees can be provided. Developers should prioritize transparency and thorough testing.
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 Plumbing contract on Base is 0xb200000000000000000000d3677a2bddb1184d01. 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 Plumbing is 46/100 (Medium risk) as of Sep 6, 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 6, 2026). Total DEX liquidity: $54.3K.
As of Sep 6, 2026, the 10 largest holders own 61.0% 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
