Quantum Audit Logo

Is FLock.io Safe?

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

FLock.io FLOCK
0x5ab3…b691
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The FlockTokenUpgradeable contract implements an ERC20 token with upgradeability, administrative controls for minting, burning, and blacklisting. While it leverages OpenZeppelin's secure upgradeable patterns and access control, a critical vulnerability exists where the intended daily mint limit is not enforced, allowing for uncontrolled token inflation by the administrator. High centralization of power also presents a significant risk.

1 Critical1 High1 Medium1 Low1 Informational
Volume 24h
$510.9K
Liquidity
$157.3K
Price
$0.03981
Token Age
1y
Top 10 Holders
70.8%

Security Findings

1 Crit1 High1 Med1 Low1 Info
Critical

Unenforced Daily Mint Limit

C-01The `dailyMintLimit` state variable is declared and can be set by the admin, but it is never used or enforced within the `mint` function. The `mint` function only checks against `maxTotalSupply`. This means that the administrator can mint any amount up to the `maxTotalSupply` in a single transaction, completely bypassing the intended daily limit mechanism. This poses a severe economic risk, as the token supply can be rapidly inflated beyond the protocol's stated daily constraints.
IssueThe `dailyMintLimit` state variable is declared and can be set by the admin, but it is never used or enforced within the `mint` function. The `mint` function only checks against `maxTotalSupply`. This means that the administrator can mint any amount up to the `maxTotalSupply` in a single transaction, completely bypassing the intended daily limit mechanism. This poses a severe economic risk, as the token supply can be rapidly inflated beyond the protocol's stated daily constraints.
FixImplement the daily minting logic within the `mint` function. This should involve checking `lastMintedDay` and `amountMintedToday` against the `dailyMintLimit` to ensure that the total amount minted within a 24-hour period does not exceed the set limit. The `lastMintedDay` and `amountMintedToday` variables should be updated accordingly after each mint operation.
StatusUnresolved
High

High Centralization of Power

H-01The `onlyAdmin` role has extensive control over critical functions, including `mint`, `burnNetworkFees`, `addBatchToBlacklist`, `removeBatchFromBlacklist`, `setDailyMintLimit`, `addAdmin`, and `transferERC20`. This grants significant power to a single entity (or a small group if the admin role is a multisig) over the token's supply, transferability, and contract funds. The initial admin is set to `msg.sender` of the `initialize` function, which could be a single EOA, creating a single point of failure.
IssueThe `onlyAdmin` role has extensive control over critical functions, including `mint`, `burnNetworkFees`, `addBatchToBlacklist`, `removeBatchFromBlacklist`, `setDailyMintLimit`, `addAdmin`, and `transferERC20`. This grants significant power to a single entity (or a small group if the admin role is a multisig) over the token's supply, transferability, and contract funds. The initial admin is set to `msg.sender` of the `initialize` function, which could be a single EOA, creating a single point of failure.
FixIt is highly recommended that the `DEFAULT_ADMIN_ROLE` for the token contract be managed by a robust multisignature wallet with a sufficient threshold. This would distribute control, reduce the risk of a single point of failure, and require consensus for critical operations, enhancing the overall security and trust in the protocol.
StatusUnresolved
Medium

Admin Can Transfer Arbitrary ERC20 Tokens

M-01The `transferERC20` function allows the `onlyAdmin` role to transfer any ERC20 token from the contract's balance to any specified address. While restricted to the admin, this function could be misused if other ERC20 tokens are accidentally sent to the contract, or if the admin's private key is compromised. This effectively acts as a powerful backdoor for draining unintended assets from the contract.
IssueThe `transferERC20` function allows the `onlyAdmin` role to transfer any ERC20 token from the contract's balance to any specified address. While restricted to the admin, this function could be misused if other ERC20 tokens are accidentally sent to the contract, or if the admin's private key is compromised. This effectively acts as a powerful backdoor for draining unintended assets from the contract.
FixConsider if the ability to transfer arbitrary ERC20 tokens is strictly necessary. If so, ensure robust operational procedures and multisig control for its execution. If not, remove or restrict this function to only allow transfers of the native token or specific whitelisted tokens. Alternatively, implement a time-locked withdrawal mechanism for non-native tokens to provide a window for users to react to suspicious activity.
StatusUnresolved
Low

Blacklist Mechanism Limitations

L-01The `notBlacklisted` modifier is applied to `transfer` and `transferFrom`, preventing blacklisted accounts from initiating token transfers. However, blacklisted accounts can still *receive* tokens. While this behavior might be intended (e.g., to allow funds to be sent to a blacklisted address for recovery), it could lead to confusion or unexpected scenarios regarding the full scope of the blacklist's impact.
IssueThe `notBlacklisted` modifier is applied to `transfer` and `transferFrom`, preventing blacklisted accounts from initiating token transfers. However, blacklisted accounts can still *receive* tokens. While this behavior might be intended (e.g., to allow funds to be sent to a blacklisted address for recovery), it could lead to confusion or unexpected scenarios regarding the full scope of the blacklist's impact.
FixClearly document the intended behavior of the blacklist, specifically clarifying that blacklisted accounts can receive but not send tokens. If the intention was to prevent all interactions, consider adding checks on the recipient address as well, though this is less common for ERC20 blacklists.
StatusUnresolved
Info

Unused `lastMintedDay` and `amountMintedToday` Variables

I-01The contract declares `lastMintedDay` and `amountMintedToday` mappings, which are typically used to implement daily minting limits. However, these variables are not used anywhere in the provided code. This indicates either an incomplete feature implementation or dead code, further highlighting the issue of the unenforced `dailyMintLimit` (C-01).
IssueThe contract declares `lastMintedDay` and `amountMintedToday` mappings, which are typically used to implement daily minting limits. However, these variables are not used anywhere in the provided code. This indicates either an incomplete feature implementation or dead code, further highlighting the issue of the unenforced `dailyMintLimit` (C-01).
FixEither implement the intended daily minting logic using these variables in conjunction with `dailyMintLimit`, or remove them if the feature is no longer planned. Removing unused variables can slightly reduce contract size and improve clarity.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract utilizes OpenZeppelin's upgradeable standards for ERC20 and AccessControl, enhancing code security (7.2). However, a critical vulnerability exists where the `dailyMintLimit` is declared but not enforced in the `mint` function, allowing an administrator to mint an unlimited supply up to `maxTotalSupply` at any time (7.2, 7.4). Additionally, `lastMintedDay` and `amountMintedToday` variables are unused, indicating an incomplete feature implementation (7.2). The `transferERC20` function, while admin-gated, allows for the transfer of arbitrary ERC20 tokens from the contract (7.2).

GovernanceHigh1/10

The token's economic model is highly centralized, with an `onlyAdmin` role controlling all minting, burning, blacklisting, and critical parameter adjustments (7.4, 7.5). While this offers flexibility, it introduces a significant single point of failure if the admin key is compromised or misused (7.3). The unenforced `dailyMintLimit` poses a severe economic risk, as the token supply can be rapidly inflated without the intended daily constraints (7.4). The blacklist mechanism allows censorship of transfers for specific accounts (7.3).

UpgradesHigh1/10

The contract employs the Transparent Upgradeable Proxy pattern with OpenZeppelin's upgradeable contracts, ensuring a robust and secure upgrade mechanism (7.7). The proxy's admin is managed by a multisig, which significantly reduces the risk of unauthorized upgrades (7.7). The `initialize` function correctly uses `initializer` modifiers for all base contracts, preventing re-initialization issues (7.7).

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Multisig 2-of-3
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

70.8% in top 10
52.3% in wallets18.5% in contracts
Effective Concentration59.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

$476.7K across 13 pairs
AerodromeUSDCanalysed$157.3K33.0%Uniswap v3USDC$132.7K27.8%AerodromeWETH$106.7K22.4%AerodromecbBTC$32.8K6.9%AerodromeVVV$16.2K3.4%Uniswap v3WETH$15.0K3.1%
Show 4 more pairsShow less
AerodromeVIRTUAL$7.8K1.6%AerodromeAERO$7.4K1.6%Uniswap v4USDC$5280.1%Hydrex CLAMMUSDC$1580.0%

The 3 remaining pairs hold $57 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 Holder86.0%
Top-3 Unlocked96.3%

Key Addresses

11 addresses
Deployer
0xb145…4816
Unlocked LP Held By
0xb3c0…29e50xcc67…93a50x81af…780f0xf9f9…3f160xf9b2…cf0b0x9d87…54630xa9f4…e07c0x2a40…3fc90x7c9d…98880x0cf0…a344

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

What Raised This Score

11 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 50% (70.8% total → 59.7% effective; 52.3% in EOAs, 18.5% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 86.0% (independent LP — depth risk, pool = 33% of DEX liquidity)
  • LP top3 unlocked holders = 96.3% (independent LP — depth risk, pool = 33% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 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

6 more on the record
Coinbase Wrapped MEGA (CBMEGA)Critical Riskbasedpad.fun (BPAD)Critical RiskCysic (CYS)Critical RiskStrike Robot (SR)Critical RiskMineBean (BEAN)Critical RiskRatspeakCritical Risk

Would You Like a More Detailed Audit of FLock.io?

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

Get Detailed Audit