Quantum Audit Logo

Is Four Safe?

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

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

Four FORM
0x5b73…e284
BNB Chain
Not verifiedThis record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked 10d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The FormToken contract is a standard ERC20 token implementation, inheriting from OpenZeppelin's `ERC20` and `Ownable2Step` contracts. The code adheres to well-established patterns, incorporating robust checks for common ERC20 operations and secure ownership transfer mechanisms. The use of `unchecked` blocks is appropriately guarded by prior `require` statements, preventing integer underflows. The contract is not upgradeable. Overall, the contract exhibits a low-risk profile.

1 Low2 Informational
Volume 24h
$482.2K
Liquidity
$572.2K
Price
$0.2556
Token Age
1y
Top 10 Holders
94.0%

Security Findings

1 Low2 Info
Low

Centralized Control by Owner

L-01The contract implements `Ownable2Step`, granting the owner significant control over administrative functions, specifically the ability to transfer ownership. While `Ownable2Step` improves the security of ownership transfers by requiring a two-step process, the owner (even if a multisig) still represents a central point of control. Malicious or compromised owner keys could lead to unauthorized ownership changes.
IssueThe contract implements `Ownable2Step`, granting the owner significant control over administrative functions, specifically the ability to transfer ownership. While `Ownable2Step` improves the security of ownership transfers by requiring a two-step process, the owner (even if a multisig) still represents a central point of control. Malicious or compromised owner keys could lead to unauthorized ownership changes.
FixEnsure the owner's private keys (for the multisig signers) are secured with industry best practices. Implement robust operational security procedures for the multisig wallet, including strict access controls and multi-person authorization for all critical transactions. Consider exploring more decentralized governance models for future iterations if applicable to the project's goals.
StatusUnresolved
Info

Unused Interfaces and Libraries

I-01The contract imports `IERC20Permit` and the `Math` library, but neither is utilized within the provided `ERC20` contract code. While this does not pose a direct security vulnerability, it adds unnecessary code and slightly increases deployment costs and contract size.
IssueThe contract imports `IERC20Permit` and the `Math` library, but neither is utilized within the provided `ERC20` contract code. While this does not pose a direct security vulnerability, it adds unnecessary code and slightly increases deployment costs and contract size.
FixRemove any unused interfaces or libraries to optimize contract size and reduce deployment costs. If these components are intended for future functionality or extensions, consider adding them only when they become necessary.
StatusUnresolved
Info

Standard ERC20 Approval Race Condition

I-02The standard `approve()` function in ERC20 is susceptible to a known front-running attack. If a user approves an amount for a spender, and then attempts to approve a different amount (either higher or lower) before the first transaction is mined, a malicious actor can front-run the second `approve` transaction. This could allow the malicious actor to spend the original approved amount, and then also spend the new approved amount, effectively doubling the spendable allowance or leading to unexpected behavior. While `increaseAllowance()` and `decreaseAllowance()` mitigate this, the base `approve()` function remains vulnerable.
IssueThe standard `approve()` function in ERC20 is susceptible to a known front-running attack. If a user approves an amount for a spender, and then attempts to approve a different amount (either higher or lower) before the first transaction is mined, a malicious actor can front-run the second `approve` transaction. This could allow the malicious actor to spend the original approved amount, and then also spend the new approved amount, effectively doubling the spendable allowance or leading to unexpected behavior. While `increaseAllowance()` and `decreaseAllowance()` mitigate this, the base `approve()` function remains vulnerable.
FixEducate users about the risks associated with directly calling `approve()` to change an existing allowance. Encourage the use of `increaseAllowance()` and `decreaseAllowance()` functions when modifying an existing allowance, as these functions are designed to prevent this specific race condition. If direct `approve()` calls are necessary, advise users to first set the allowance to zero before setting a new value.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical architecture (7.1) is based on battle-tested OpenZeppelin ERC20 and Ownable2Step contracts, ensuring a solid foundation. Code security (7.2) is high, with `unchecked` arithmetic correctly preceded by `require` checks to prevent underflows, such as in `_transfer` and `decreaseAllowance`. Access control (7.3) is well-implemented using `Ownable2Step`, requiring a two-step process for ownership transfers. The contract does not introduce complex external interactions (7.6) or novel economic mechanisms (7.4) that would typically introduce higher technical risk.

GovernanceHigh1/10

The governance model (7.5) relies on the `Ownable2Step` pattern, which enhances security by requiring the new owner to accept ownership, preventing accidental transfers to incorrect addresses. The prefill indicates the owner is a multisig with a 3/6 threshold, significantly decentralizing administrative control and mitigating single points of failure. The economic model (7.4) is a standard ERC20 token without complex DeFi primitives, reducing inherent economic risks. There are no specific oracle dependencies or complex fee structures that could be manipulated.

UpgradesMedium4/10

The contract is not designed as an upgradeable proxy (7.7). This simplifies the architecture and eliminates risks associated with proxy patterns, such as storage collisions or incorrect initialization. While this means the contract's logic cannot be modified post-deployment, it ensures immutability and predictability, which can be a desirable security feature for simple token contracts.

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

94.0% in top 10
91.9% in wallets2.0% in contracts
Effective Concentration92.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

$587.3K across 11 pairs
Pancakeswap v3USDTanalysed$572.2K97.4%Pancakeswap v3Cake$9.9K1.7%Uniswap比特币$2.6K0.4%UniswapUSDT$2.6K0.4%Pancakeswap v3WBNB$620.0%Pancakeswap v2BNBX$50.0%
Show 4 more pairsShow less
Pancakeswap v2WBNB$00.0%Pancakeswap v3U$00.0%Pancakeswap v2USDT$00.0%Pancakeswap v2ASTER$00.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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0xa8a6…f745
Unlocked LP Held By
0x62af…d630

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 — strong Multisig (3-of-6)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 70% (94.0% total → 92.7% effective; 91.9% in EOAs, 2.0% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 97% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 97% of DEX liquidity)
  • 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
Pro Token (PRO)High RiskElonCoinHigh RiskSUMMERHigh RiskSomniaOFT (SOMI)High RiskGoPlus Security (GPS)High RiskAsteroid Shiba (ASTEROID)High Risk

Would You Like a More Detailed Audit of Four?

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

Get Detailed Audit