Quantum Audit Logo

Is SPARK Safe?

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

SPARK SPARK
0x0fb0…8248
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The SPARK token contract is a straightforward ERC20 implementation, leveraging battle-tested OpenZeppelin libraries for its core functionality and ERC20Permit extension. The contract is simple, with a fixed supply minted at deployment and no additional administrative roles or complex logic. The primary risks identified are informational regarding its design choices and a low-severity user-side risk associated with the `permit` function's susceptibility to front-running.

1 Low3 Informational
Volume 24h
$32.6K
Liquidity
$104.8K
Price
$0.002349
Token Age
3mo
Top 10 Holders
44.1%

Security Findings

1 Low3 Info
Low

`permit` Function Transaction Front-Running

L-01The `permit` function, while enabling gasless approvals, is susceptible to front-running (7.2 Code Security). A malicious actor monitoring the mempool could observe a signed `permit` message, and if the `deadline` allows, submit their own transaction with a higher gas price to approve and then spend the tokens before the legitimate transaction confirms. This is a known characteristic of the ERC20Permit standard and not a bug in the implementation itself, but a risk for users.
IssueThe `permit` function, while enabling gasless approvals, is susceptible to front-running (7.2 Code Security). A malicious actor monitoring the mempool could observe a signed `permit` message, and if the `deadline` allows, submit their own transaction with a higher gas price to approve and then spend the tokens before the legitimate transaction confirms. This is a known characteristic of the ERC20Permit standard and not a bug in the implementation itself, but a risk for users.
FixUsers should be advised to set a sufficiently short `deadline` for `permit` signatures to minimize the window for front-running. Additionally, users should be cautious when broadcasting `permit` signatures and consider using services that protect against front-running where available.
StatusUnresolved
Info

Reliance on Battle-Tested OpenZeppelin Libraries

I-01The SPARK token contract leverages standard and widely-audited OpenZeppelin contracts for its ERC20 and ERC20Permit implementations. This significantly reduces the likelihood of common vulnerabilities (7.2 Code Security) such as reentrancy, integer overflows/underflows, and standard ERC20 compliance issues, as these base contracts have undergone extensive scrutiny and are considered industry best practice.
IssueThe SPARK token contract leverages standard and widely-audited OpenZeppelin contracts for its ERC20 and ERC20Permit implementations. This significantly reduces the likelihood of common vulnerabilities (7.2 Code Security) such as reentrancy, integer overflows/underflows, and standard ERC20 compliance issues, as these base contracts have undergone extensive scrutiny and are considered industry best practice.
FixNo action required. This is a strength of the contract's design.
StatusResolved
Info

Immutability of Token Supply and Parameters

I-02The `SPARK` token has a fixed total supply that is minted entirely during the constructor call (7.4 Economic). There are no functions for further minting or burning (beyond standard transfers to/from address(0) which adjust total supply). Similarly, the token's name, symbol, and decimals are set in the constructor and cannot be changed. This design provides predictability and transparency regarding the token's supply and characteristics but limits any future flexibility or adjustments.
IssueThe `SPARK` token has a fixed total supply that is minted entirely during the constructor call (7.4 Economic). There are no functions for further minting or burning (beyond standard transfers to/from address(0) which adjust total supply). Similarly, the token's name, symbol, and decimals are set in the constructor and cannot be changed. This design provides predictability and transparency regarding the token's supply and characteristics but limits any future flexibility or adjustments.
FixNo action required. This is a design choice. Ensure that the initial deployment parameters (recipient and total supply) are correct, as they cannot be altered.
StatusResolved
Info

Absence of Administrative Roles

I-03The `SPARK` token contract does not implement any administrative roles (e.g., `owner`, `pauser`, `minter`) or access control mechanisms (7.3 Access Control) beyond the standard ERC20 functions. This design choice minimizes the attack surface associated with centralized control and single points of failure, as no single entity can unilaterally alter the contract's behavior or freeze funds. However, it also means there are no emergency mechanisms (e.g., pausing transfers in case of a critical vulnerability in an integrated system) or upgrade capabilities (7.8 Operations).
IssueThe `SPARK` token contract does not implement any administrative roles (e.g., `owner`, `pauser`, `minter`) or access control mechanisms (7.3 Access Control) beyond the standard ERC20 functions. This design choice minimizes the attack surface associated with centralized control and single points of failure, as no single entity can unilaterally alter the contract's behavior or freeze funds. However, it also means there are no emergency mechanisms (e.g., pausing transfers in case of a critical vulnerability in an integrated system) or upgrade capabilities (7.8 Operations).
FixNo action required. This is a design choice. Stakeholders should be aware of the implications of a fully decentralized and immutable token without administrative intervention capabilities.
StatusResolved

Category Ratings

TechnicalLow10/10

The technical architecture (7.1 Architecture) of the SPARK token is robust, relying entirely on well-audited OpenZeppelin ERC20 and ERC20Permit contracts. This significantly mitigates common code security (7.2 Code Security) vulnerabilities like reentrancy and integer overflows. The contract's simplicity, with no complex custom logic, further enhances its security posture. No significant technical vulnerabilities were found, demonstrating a high level of code quality.

GovernanceMedium6/10

The economic model (7.4 Economic) of the SPARK token is very simple: a fixed total supply is minted once during deployment to a specified recipient. There are no further minting or burning capabilities exposed, ensuring a predictable supply. The contract lacks any governance mechanisms (7.5 Governance) or administrative roles, which eliminates risks associated with centralized control but also removes options for emergency intervention or future parameter adjustments.

UpgradesLow7/10

The SPARK contract is not designed to be upgradeable (7.7 Upgrades). It is deployed as a standard, immutable contract. This eliminates the complexities and potential risks associated with proxy patterns and upgrade mechanisms, providing certainty regarding its code and behavior post-deployment.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

44.1% in top 10
12.4% in wallets31.7% in contracts
Effective Concentration25.1%

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.

Liquidity Depth

$141.6K across 6 pairs
Uniswap v4ETHanalysed$104.8K74.0%Uniswap v4ETH$36.3K25.6%Uniswap v4ETH$2610.2%Uniswap v4ETH$2590.2%Uniswap v4USDC$20.0%Uniswap v4USDC$10.0%

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.

LP Distribution

LP Locked100.0% · UNCX V4 Lock

Key Addresses

1 addresses
Deployer
0xb1da…1cbc

What Raised This Score

3 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 20% (44.1% total → 25.1% effective; 12.4% in EOAs, 31.7% in contracts — mild)
  • 1 Low finding(s) from audit

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

6 more on the record
OpenVPP (OVPP)Low RiskBasecatLow RiskBase Juice (BASEJUICE)Low RiskSKI MASK DOG (SKI)Low RiskClawBankLow RiskEdelLow Risk

Would You Like a More Detailed Audit of SPARK?

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

Get Detailed Audit