Quantum Audit Logo

Is SPIKE Safe?

On-chain security analysis — is it a scam or legit?

SPIKE SPIKE
0xb200…4d01
Base
Not verifiedThis record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.
Last checked today 1 audit on record
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

This audit report is based on the provided contract address 0xb20000000000000000000070f6c1a66d7c1e4d01 on the Base network. No Solidity source code was provided for analysis, and the contract is not verified on-chain. Therefore, a comprehensive security assessment of the contract's logic, architecture, and potential vulnerabilities could not be performed. The findings below represent general security considerations and best practices applicable to EVM smart contracts.

5 Informational
Volume 24h
$321.2K
Liquidity
$117.9K
Price
$0.0006396
Token Age
1mo
Top 10 Holders
0.0%

Security Findings

Info

Lack of Verified Source Code

I-01The contract at 0xb200…4d01 does not have its Solidity source code verified on the Base blockchain explorer, nor was it provided for this audit. This prevents any form of code-level security analysis (7.1 Architecture, 7.2 Code Security).
IssueThe contract at does not have its Solidity source code verified on the Base blockchain explorer, nor was it provided for this audit. This prevents any form of code-level security analysis (7.1 Architecture, 7.2 Code Security).
FixIt is critical for all production smart contracts to have their source code publicly verified on the blockchain explorer. This enables transparency, allows for independent security reviews, and builds trust with users.
StatusUnresolved
Info

Unknown Access Control Mechanisms

I-02Without source code (7.3 Access Control), the contract's access control mechanisms are unknown. It is impossible to determine if privileged functions are adequately protected, if a multi-signature wallet is used for critical operations, or if there are single points of failure.
IssueWithout source code (7.3 Access Control), the contract's access control mechanisms are unknown. It is impossible to determine if privileged functions are adequately protected, if a multi-signature wallet is used for critical operations, or if there are single points of failure.
FixImplement robust access control using roles (e.g., OpenZeppelin's Ownable or AccessControl) and consider multi-signature wallets for critical administrative functions to prevent single points of compromise.
StatusUnresolved
Info

Unverified Upgradeability Status

I-03The contract's upgradeability (7.7 Upgrades) cannot be determined without source code. If the contract is intended to be upgradeable, the specific proxy pattern and its implementation are unknown, posing potential risks if not correctly designed and secured.
IssueThe contract's upgradeability (7.7 Upgrades) cannot be determined without source code. If the contract is intended to be upgradeable, the specific proxy pattern and its implementation are unknown, posing potential risks if not correctly designed and secured.
FixIf upgradeability is desired, use well-established and audited proxy patterns (e.g., UUPS, Transparent) and ensure that upgrade permissions are secured, ideally via a multi-signature wallet or a robust governance process.
StatusUnresolved
Info

Potential for Undetected Economic Vulnerabilities

I-04The economic model and potential for manipulation (7.4 Economic) cannot be assessed without source code. This includes risks related to tokenomics, fee structures, flash loan attacks, or oracle manipulation if external price feeds are used.
IssueThe economic model and potential for manipulation (7.4 Economic) cannot be assessed without source code. This includes risks related to tokenomics, fee structures, flash loan attacks, or oracle manipulation if external price feeds are used.
FixDesign economic models carefully, considering edge cases and potential attack vectors. Implement safeguards against flash loan attacks (e.g., time-weighted averages, commit-reveal schemes) and use robust, decentralized oracle solutions if external data is required.
StatusUnresolved
Info

Unconfirmed Reentrancy Protection

I-05Without source code (7.2 Code Security), it is impossible to confirm if the contract implements proper reentrancy protection for functions that send Ether or interact with external contracts.
IssueWithout source code (7.2 Code Security), it is impossible to confirm if the contract implements proper reentrancy protection for functions that send Ether or interact with external contracts.
FixAlways use the `nonReentrant` modifier from OpenZeppelin's `ReentrancyGuard` or follow the Checks-Effects-Interactions pattern for any function that performs external calls, especially those involving value transfers.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

Due to the absence of source code (7.1 Architecture, 7.2 Code Security), a detailed technical analysis of the contract's implementation, design patterns, and potential code-level vulnerabilities could not be conducted. Key areas such as reentrancy protection, integer overflow/underflow safeguards, and secure handling of external calls (7.6 External) are critical for contract security. Without code, it is impossible to confirm the presence of these protections or identify specific flaws.

GovernanceHigh3/10

Without source code, the economic model (7.4 Economic) and governance mechanisms (7.5 Governance) of the contract cannot be assessed. Important considerations include tokenomics, fee structures, potential for economic manipulation, and the decentralization or centralization of control. Access control mechanisms (7.3 Access Control) are also unknown, making it impossible to determine if privileged roles are appropriately managed or if single points of failure exist. Operational aspects (7.8 Operations) like pause mechanisms or emergency shutdowns are also unverified.

UpgradesMedium5/10

The contract's upgradeability status (7.7 Upgrades) is unknown due to the lack of source code. If the contract is intended to be upgradeable, it is crucial to ensure that a secure proxy pattern (e.g., UUPS, Transparent) is correctly implemented and that upgrade paths are robust and well-governed. Improper upgrade mechanisms can introduce significant security risks, including logic errors or the potential for malicious code injection during an upgrade. Without code, no assessment of upgrade safety can be made.

Security Checklist

Contract VerifiedFail
Ownership Renounced?
No Mint Function?
Liquidity LockedFail
Not a ProxyPass

Liquidity Depth

Show 4 more pairsShow less

The 5 remaining pairs hold $10 between them and are not listed.

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

What Raised This Score

  • Ownership status UNKNOWN (owner could not be resolved)
  • Mint capability UNKNOWN (implementation ABI unreadable)
  • Contract source NOT verified
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)

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

Related Audits

Derive (DRV)Medium RiskVenice Deity (VVVEITY)Medium Risktokenbot (CLANKER)Medium RiskKairence (KAI)Medium RiskB3Medium RiskHandlPay (HANDL)Medium Risk

Would You Like a More Detailed Audit of SPIKE?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit