Quantum Audit Logo

Is Spice Safe?

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

Is this your token? Publish your own audit on this page →

Spice SFI
0xb753…902c
Ethereum Not verifiedLast checked 1d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The audit of the SFI Token (ERC20) contract identified a critical flaw where the token's total supply is not initialized, rendering the token unusable. The contract otherwise uses standard OpenZeppelin patterns, including SafeMath for arithmetic operations, which mitigates common integer vulnerabilities. Informational findings include the use of an older Solidity compiler version and the inherent ERC20 `approve` race condition.

1 Critical2 Informational
Volume 24h
$62.4K
Liquidity
$368.5K
Price
$126.7200
Token Age
6mo
Top 10 Holders
41.7%

Security Findings

1 Crit2 Info
Critical

Missing Initial Token Supply

C-01The `ERC20` contract's constructor initializes token metadata (`name`, `symbol`, `decimals`) but does not mint any initial supply to an owner or deployer address. The `_mint` function is `internal virtual` and is not called within the provided `ERC20` constructor. Consequently, `_totalSupply` remains 0, and no tokens can ever be created or transferred, rendering the token completely unusable upon deployment.
IssueThe `ERC20` contract's constructor initializes token metadata (`name`, `symbol`, `decimals`) but does not mint any initial supply to an owner or deployer address. The `_mint` function is `internal virtual` and is not called within the provided `ERC20` constructor. Consequently, `_totalSupply` remains 0, and no tokens can ever be created or transferred, rendering the token completely unusable upon deployment.
FixA derived contract must implement a constructor that calls `_mint(deployerAddress, initialSupply)` to create the initial token supply upon deployment. For example: `constructor(string memory name_, string memory symbol_, uint256 initialSupply_) ERC20(name_, symbol_) { _mint(msg.sender, initialSupply_); }`.
StatusUnresolved
Info

Older Solidity Compiler Version

I-01The contract uses Solidity version `^0.7.1`. Newer versions (e.g., `^0.8.0` and above) include additional safety checks (like default overflow/underflow protection, removing the need for SafeMath in many cases) and compiler optimizations. While SafeMath is used, leveraging newer compiler features can further enhance security and efficiency.
IssueThe contract uses Solidity version `^0.7.1`. Newer versions (e.g., `^0.8.0` and above) include additional safety checks (like default overflow/underflow protection, removing the need for SafeMath in many cases) and compiler optimizations. While SafeMath is used, leveraging newer compiler features can further enhance security and efficiency.
FixConsider upgrading to a more recent stable Solidity compiler version (e.g., `^0.8.x`) to benefit from improved security features, gas efficiencies, and a more modern development environment.
StatusUnresolved
Info

ERC20 `approve` Race Condition

I-02The standard `approve` function is susceptible to a known front-running vulnerability. If a user approves an amount `X` for a spender, and then attempts to approve a new amount `Y`, a malicious actor could front-run the second transaction, spending the original `X` amount. The `Y` approval would then still be valid, potentially allowing the spender to spend `X + Y` in total. While `increaseAllowance` and `decreaseAllowance` functions are provided to mitigate this, the base `approve` function remains.
IssueThe standard `approve` function is susceptible to a known front-running vulnerability. If a user approves an amount `X` for a spender, and then attempts to approve a new amount `Y`, a malicious actor could front-run the second transaction, spending the original `X` amount. The `Y` approval would then still be valid, potentially allowing the spender to spend `X + Y` in total. While `increaseAllowance` and `decreaseAllowance` functions are provided to mitigate this, the base `approve` function remains.
FixUsers should be advised to use `increaseAllowance` and `decreaseAllowance` functions instead of directly calling `approve` when modifying existing allowances, as these functions are designed to prevent this specific front-running vector.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract implements a standard ERC20 token using well-vetted OpenZeppelin libraries like SafeMath and Address, ensuring robust arithmetic operations (7.2 Code Security). However, a critical architectural flaw exists where the `_totalSupply` is never initialized, making the token non-functional (7.1 Architecture). The `_mint` and `_burn` functions are internal, preventing external supply manipulation, but also preventing initial supply creation.

GovernanceHigh2/10

The economic model is severely impacted by the critical issue of an uninitialized token supply, meaning no tokens can be created or distributed (7.4 Economic). There are no explicit governance mechanisms or owner roles defined within this base ERC20 contract for supply management, which would typically be handled by a derived contract or an external governance module (7.5 Governance). This lack of initial supply makes the token economically non-viable.

UpgradesHigh2/10

The contract is a standard, non-upgradeable ERC20 implementation. There are no proxy patterns or upgrade mechanisms present, which eliminates upgrade-related risks (7.7 Upgrades). This means the contract's logic is immutable once deployed, ensuring predictable behavior without future modification capabilities.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

41.7% in top 10
21.6% in wallets20.0% in contracts
Effective Concentration29.7%

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

$537.5K across 4 pairs
Uniswap v3USDCanalysed$368.5K68.6%Uniswap v2WETH$130.0K24.2%SushiswapWETH$33.5K6.2%Uniswap v3WETH$5.5K1.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

Top-1 Unlocked Holder66.7%
Top-3 Unlocked98.1%

Key Addresses

7 addresses
Deployer
0x09e9…f8cb
Unlocked LP Held By
0xa38d…78270x45bf…32290x9b61…28080xf211…24760xc134…b9390x5a66…90ea

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

7 factors
  • Ownership NOT renounced (admin/mint authority retained)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 20% (41.7% total → 29.7% effective; 21.6% in EOAs, 20.0% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 66.7% (independent LP — depth risk, pool = 69% of DEX liquidity)
  • LP top3 unlocked holders = 98.1% (independent LP — depth risk, pool = 69% of DEX liquidity)
  • 1 Critical 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
MorphoHigh RiskBeamHigh RiskSuperVerse (SUPER)High Risk00 Token (00)High RiskIxs Token (IXS)High RiskAlberich Token (ALBRH)High Risk

Would You Like a More Detailed Audit of Spice?

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

Get Detailed Audit