Quantum Audit Logo
Launch App

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

Is FLock.io Safe?

FLOCKBase
Not verified This 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 Sep 4, 2026 · 1 audit on record
Chart
Critical RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades1/10Checks passed1 of 5Findings1 Critical · 1 High · 1 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The FlockTokenUpgradeable contract implements an ERC20 token with upgradeability, administrative controls for minting, burning, and blacklisting.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Top-10 concentration > 50%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 86.0%
  • LP top3 unlocked holders = 96.3%
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 41 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
18.5%Contracts52.3%Wallets29.2%Everyone else
18.5%Contracts52.3%Wallets29.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
70.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking18.5%
  • Walletsanonymous holders, free to sell52.3%
  • Everyone elsethe rest of the supply29.2%
Effective concentrationwhat the score reads59.7%
How holder types affect the score

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

Liquidity

as of audit · Sep 4$476.7K across 13 pairs
Show 4 more pairs

The 3 remaining pairs hold $57 between them and are not listed. The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$157.3KShare of depth33.0%
Top-1 Unlocked Holder86.0%
Top-3 Unlocked96.3%
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.

Security Findings

1 Critical1 High1 Medium1 Low1 Info
Critical

Unenforced Daily Mint Limit

The 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.C-01

Issue

The 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.

Fix

Implement 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.

Status

Unresolved

High

High Centralization of Power

The 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.H-01

Issue

The 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.

Fix

It 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.

Status

Unresolved

Medium

Admin Can Transfer Arbitrary ERC20 Tokens

The 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.M-01

Issue

The 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.

Fix

Consider 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.

Status

Unresolved

Low

Blacklist Mechanism Limitations

The 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.L-01

Issue

The 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.

Fix

Clearly 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.

Status

Unresolved

Info

Unused lastMintedDay and amountMintedToday Variables

The 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).I-01

Issue

The 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).

Fix

Either 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.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical4/10Medium risk

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).

Governance1/10High risk

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).

Upgrades1/10High risk

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).

Final RecommendationWhat to do about this score

Prioritize fixing the critical bug where dailyMintLimit is not enforced in the mint function to prevent unintended token inflation.

Implement the daily minting logic using the lastMintedDay and amountMintedToday variables. Strengthen access control by ensuring the DEFAULT_ADMIN_ROLE is managed by a robust multisignature wallet, similar to the proxy admin, to mitigate the risks associated with high centralization and potential misuse of powerful administrative functions.

Contract & Record

1 audit on record
TypeTransparentUpgradeableProxy
NetworkBase
Token age1y
Contract0x5ab3…b691
Deployer0xb145…4816
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Multisig 2-of-3
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
FLock.io security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202685Critical
  2. Aug 13, 202684High

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the FLOCK contract address?

The FLock.io (FLOCK) contract on Base is 0x5ab3d4c385b400f3abb49e80de2faf6a88a7b691. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is FLock.io a scam?

Quantum Audit's risk score for FLock.io is 85/100 (Critical risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Upgradeable. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is FLOCK liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $476.7K.

Who holds FLOCK?

As of Sep 4, 2026, the 10 largest holders own 70.8% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
Coinbase Wrapped MEGACBMEGA · Base85Criticalbasedpad.funBPAD · Base85CriticalCysicCYS · Base84HighWrapped L1coinWL1 · Base84HighStrike RobotSR · Base87CriticalCrynux TokenCNX · Base87Critical

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 Is this your token? Publish your own audit on this page