On-chain security analysis — is it a scam or legit?
EthereumThe audit of the SFI Token (ERC20) contract identified a critical flaw where the token's total supply is not initialized, rendering the token unusable.
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 5, 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.
0xa38d…78270x45bf…32290x9b61…28080xf211…24760xc134…b9390x5a66…90eaNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
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.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.
A 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_); }`.
Unresolved
^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.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.
Consider 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.
Unresolved
approve Race Conditionapprove 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.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.
Users 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.
Unresolved
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.
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.
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.
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.
The most critical issue is the lack of initial token supply.
The contract must be redeployed with a modified constructor in a derived contract that calls _mint to establish the initial token supply and assign it to an appropriate address. Additionally, consider upgrading to a newer Solidity compiler version (e.g., ^0.8.x) to benefit from enhanced security features and gas efficiencies. Users should be educated on using increaseAllowance and decreaseAllowance to mitigate approve front-running risks.
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 Spice (SFI) contract on Ethereum is 0xb753428af26e81097e7fd17f40c88aaa3e04902c. 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 Spice is 54/100 (Medium risk) as of Sep 5, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: Mintable; 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 5, 2026). Total DEX liquidity: $537.5K.
As of Sep 5, 2026, the 10 largest holders own 41.7% 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
