On-chain security analysis — is it a scam or legit?
BNB ChainThe FistStandard contract implements a basic BEP20-compatible token.
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 4, 2026
The 19 remaining pairs hold $116 between them and are not listed. 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.
0x3eac…39280x4b52…47230x8dc1…0f460x1779…71ba0xbaf0…e5b50x1e48…b6760x170a…d16c0x413a…244c0x55c9…debf0x5a9f…a9fcNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
The 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.
Consider 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.
Unresolved
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.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.
While 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.
Unresolved
approve() Race Condition (Mitigated)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.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.
Educate 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.
Unresolved
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.
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.
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.
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.
It is recommended to migrate to a more recent Solidity compiler version (e.g., 0.8.x) to benefit from modern security features and gas optimizations.
While the approve function's race condition is mitigated by increaseAllowance and decreaseAllowance, ensure users are aware of the safer methods. Consider documenting the role and responsibilities of the contract owner, especially regarding the transferOwnership function.
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.
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
