Quantum Audit Logo

Is FistToken Safe?

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

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

FistToken FIST
0xc988…bc6a
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The FistStandard contract implements a basic BEP20-compatible token. The code is straightforward, utilizes SafeMath for arithmetic operations, and incorporates the Ownable pattern for administrative control. No critical or high-severity vulnerabilities were identified. The primary areas for improvement relate to using a more recent Solidity compiler version and acknowledging the inherent centralization of the Ownable pattern.

3 Informational
Volume 24h
$776.6K
Liquidity
$7.35M
Price
$0.293
Token Age
4y
Top 10 Holders
48.2%

Security Findings

3 Info
Info

Outdated Solidity Compiler Version

I-01The contract is compiled with Solidity version 0.5.16. This version is outdated and may lack important security features, bug fixes, and gas optimizations present in newer compiler versions (e.g., 0.8.x). Using older versions can potentially expose the contract to known vulnerabilities that have been patched in later releases.
IssueThe contract is compiled with Solidity version 0.5.16. This version is outdated and may lack important security features, bug fixes, and gas optimizations present in newer compiler versions (e.g., 0.8.x). Using older versions can potentially expose the contract to known vulnerabilities that have been patched in later releases.
FixConsider upgrading the Solidity compiler version to a more recent stable release (e.g., 0.8.x). This would allow the contract to benefit from improved security checks, gas efficiency, and modern language features. Thorough testing should be performed after any compiler upgrade.
StatusUnresolved
Info

Centralized Ownership

I-02The contract utilizes the Ownable pattern, which assigns a single address (the owner) exclusive control over critical administrative functions such as `transferOwnership` and `renounceOwnership`. This introduces a point of centralization, as the owner has significant power over the contract's administrative state. If the owner's private key is compromised, it could lead to unauthorized control.
IssueThe contract utilizes the Ownable pattern, which assigns a single address (the owner) exclusive control over critical administrative functions such as `transferOwnership` and `renounceOwnership`. This introduces a point of centralization, as the owner has significant power over the contract's administrative state. If the owner's private key is compromised, it could lead to unauthorized control.
FixWhile common for simple tokens, it's important to acknowledge the centralization risk. Ensure the owner's private key is secured with robust practices (e.g., hardware wallet, multi-signature wallet). If the project aims for decentralization, consider implementing a multi-signature wallet for ownership or transitioning to a community-governed model.
StatusUnresolved
Info

`approve()` Race Condition (Mitigated)

I-03The standard ERC-20 `approve()` function is susceptible to a known front-running vulnerability (race condition). If a user approves an amount `X` for a spender, then decides to change it to `Y` (where `Y` is less than `X`), and the spender spends `X` before the transaction to change to `Y` is mined, the spender could potentially spend `X + Y`. However, the contract provides `increaseAllowance()` and `decreaseAllowance()` functions, which are designed to safely modify allowances without this race condition.
IssueThe standard ERC-20 `approve()` function is susceptible to a known front-running vulnerability (race condition). If a user approves an amount `X` for a spender, then decides to change it to `Y` (where `Y` is less than `X`), and the spender spends `X` before the transaction to change to `Y` is mined, the spender could potentially spend `X + Y`. However, the contract provides `increaseAllowance()` and `decreaseAllowance()` functions, which are designed to safely modify allowances without this race condition.
FixEducate users and integrators to prefer `increaseAllowance()` and `decreaseAllowance()` over directly calling `approve()` when modifying an existing allowance. If `approve()` must be used to change an allowance, it is best practice to first set the allowance to zero before setting the new amount.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The contract demonstrates good technical security practices (7.2 Code Security) by utilizing SafeMath for all arithmetic operations, effectively preventing integer overflow/underflow vulnerabilities. The implementation adheres to the BEP20 standard, ensuring compatibility and expected behavior for token transfers and allowances. However, the use of Solidity compiler version 0.5.16 is outdated, which may lack modern security features and optimizations available in newer versions.

GovernanceLow8/10

The contract employs the Ownable pattern (7.3 Access Control), granting a single address administrative control over functions like `transferOwnership` and `renounceOwnership`. While this introduces a degree of centralization (7.5 Governance), it is a standard and well-understood pattern for simple tokens. The economic model (7.4 Economic) is a fixed-supply token with no complex mechanisms, reducing economic attack vectors.

UpgradesLow9/10

The FistStandard contract is not designed to be upgradeable (7.7 Upgrades) via proxy patterns or other mechanisms. This simplifies its architecture and eliminates upgrade-specific risks. Any changes to the contract's logic would require deploying a new contract.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

48.2% in top 10
38.2% in wallets10.0% in contracts
Effective Concentration42.2%

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

$8.12M across 29 pairs
FstswapUSDTanalysed$7.35M90.4%Pancakeswap v2USDT$524.2K6.5%Pancakeswap v2WBNB$182.7K2.2%Pancakeswap v3USDT$62.5K0.8%Pancakeswap v3WBNB$5.6K0.1%W3swapUSDT$1.4K0.0%
Show 4 more pairsShow less
Pancakeswap v3WBNB$2850.0%Pancakeswap v2Cake$1380.0%JswapUSDT$1210.0%BiswapUSDT$920.0%

The 19 remaining pairs hold $116 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.

LP Distribution

Top-1 Unlocked Holder20.1%
Top-3 Unlocked46.7%

Key Addresses

11 addresses
Deployer
0x6685…409a
Unlocked LP Held By
0x3eac…39280x4b52…47230x8dc1…0f460x1779…71ba0xbaf0…e5b50x1e48…b6760x170a…d16c0x413a…244c0x55c9…debf0x5a9f…a9fc

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

What Raised This Score

2 factors
  • Top-10 concentration > 30% (48.2% total → 42.2% effective; 38.2% in EOAs, 10.0% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug 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

6 more on the record
TCryptochicks (TCC)Low Risk币安人生Low RiskSKYAILow RiskBLow RiskDOYRLow RiskCREPELow Risk

Would You Like a More Detailed Audit of FistToken?

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

Get Detailed Audit