Quantum Audit Logo

Is flork Safe?

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

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

flork FLORK
0x09db…4444
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
Executive SummaryAI Copilot

The `FourERC20` contract implements a standard ERC-20 token, leveraging well-audited OpenZeppelin libraries for its core functionalities. While the base implementation for transfers and allowances appears robust, the contract as provided lacks a public mechanism to mint tokens, rendering it non-functional as a standalone token. Additionally, a critical portion of the `_transfer` function was truncated in the provided source, which significantly limited a complete security analysis of its internal logic. The contract is not upgradeable, which simplifies its security model but removes future flexibility.

1 Medium1 Low1 Informational
Volume 24h
$17.8K
Liquidity
$41.3K
Price
$0.00005514
Token Age
11mo
Top 10 Holders
57.3%

Security Findings

Medium

Missing Public Token Supply Mechanism

M-01The `FourERC20` contract provides internal `_mint` and `_burn` functions but lacks any public or external functions to create or destroy tokens. As a result, the token's `_totalSupply` will remain zero upon deployment, and there will be no mechanism to issue new tokens, rendering the contract non-functional as a standalone ERC-20 token. This is a design flaw that prevents the token from being used as intended without further development.
IssueThe `FourERC20` contract provides internal `_mint` and `_burn` functions but lacks any public or external functions to create or destroy tokens. As a result, the token's `_totalSupply` will remain zero upon deployment, and there will be no mechanism to issue new tokens, rendering the contract non-functional as a standalone ERC-20 token. This is a design flaw that prevents the token from being used as intended without further development.
FixIf this contract is intended to be a base, ensure that any derived contract implements a public minting function (e.g., `mint(address to, uint256 amount)`) that calls the internal `_mint` function. This public function must be protected by appropriate access control mechanisms (e.g., `Ownable`, `AccessControl`) to prevent unauthorized token creation.
StatusUnresolved
Low

Incomplete Source Code Provided for Audit

L-01The provided source code for the `_transfer` internal function within `FourERC20.sol` is truncated. This prevents a full and accurate security analysis of one of the most critical functions in an ERC-20 token, as the complete logic for balance updates and checks could not be reviewed. While it is likely based on OpenZeppelin's standard implementation, an audit cannot make assumptions about missing code.
IssueThe provided source code for the `_transfer` internal function within `FourERC20.sol` is truncated. This prevents a full and accurate security analysis of one of the most critical functions in an ERC-20 token, as the complete logic for balance updates and checks could not be reviewed. While it is likely based on OpenZeppelin's standard implementation, an audit cannot make assumptions about missing code.
FixAlways provide the complete and final source code for all contracts and functions to be audited. This ensures that all logic, including internal helper functions, can be thoroughly reviewed for potential vulnerabilities, edge cases, and deviations from expected behavior.
StatusUnresolved
Info

Non-Upgradeability of Contract

I-01The `FourERC20` contract is deployed directly and does not implement any upgradeability pattern (e.g., UUPS, Transparent Proxies). This means that once deployed, its logic cannot be modified or updated. While this simplifies the security model by removing upgrade-related risks, it also means that any future bug fixes, feature enhancements, or protocol changes would require deploying an entirely new contract and migrating users/assets.
IssueThe `FourERC20` contract is deployed directly and does not implement any upgradeability pattern (e.g., UUPS, Transparent Proxies). This means that once deployed, its logic cannot be modified or updated. While this simplifies the security model by removing upgrade-related risks, it also means that any future bug fixes, feature enhancements, or protocol changes would require deploying an entirely new contract and migrating users/assets.
FixAcknowledge the implications of non-upgradeability. If future flexibility is desired, consider implementing an upgradeable proxy pattern (e.g., UUPS) for the token contract. If non-upgradeability is a deliberate design choice, ensure that the current implementation is robust and future-proof to minimize the need for redeployment.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The contract leverages well-audited OpenZeppelin libraries (v4.9.4) for its ERC-20 implementation, ensuring a strong foundation for core token functionalities like transfers and allowances (7.2 Code Security). Standard mitigations for allowance race conditions are included via `increaseAllowance` and `decreaseAllowance`. However, the provided code for the `_transfer` function was truncated, preventing a full review of its internal logic and introducing uncertainty regarding its security (7.2 Code Security). Crucially, the contract lacks a public function to mint tokens, making it non-functional as a standalone token without a derived contract (7.1 Architecture).

GovernanceLow8/10

The contract implements a basic ERC-20 token with no complex economic models, fees, or governance mechanisms (7.4 Economic, 7.5 Governance). This simplicity inherently reduces economic and governance risks, as there are no internal parameters or roles that could be manipulated. The token's value is entirely external, and the contract itself does not introduce any specific economic incentives or disincentives.

UpgradesLow10/10

The `FourERC20` contract is not designed to be upgradeable (7.7 Upgrades). This eliminates risks associated with proxy patterns, such as storage collisions, improper initialization, or upgrade path vulnerabilities. Any future changes to the token's logic would require a new contract deployment, which is a clear and transparent process, albeit without the flexibility of an upgradeable design.

Security Checklist

Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

12.7% in wallets44.7% in contracts
Effective Concentration30.5%

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

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

LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

Deployer
0x7780…46ee

What Raised This Score

  • Top-10 concentration > 30% (57.3% total → 30.5% effective; 12.7% in EOAs, 44.7% in contracts — moderate)
  • Liquidity < $50k ($43,052 across 2 pairs — thin market)
  • 1 Medium finding(s) from audit
  • 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

TCryptochicks (TCC)Low Risk币安人生Low RiskSKYAILow RiskBLow RiskDOYRLow RiskCREPELow Risk

Would You Like a More Detailed Audit of flork?

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

Get Detailed Audit