Quantum Audit Logo

Is Falcon Finance Safe?

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

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

Falcon Finance FF
0xac23…4db2
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The BurnMintERC20 contract implements a standard ERC-20 token with minting and burning capabilities, leveraging OpenZeppelin's AccessControl for role management. The contract exhibits good adherence to established patterns and includes checks to prevent self-locking of tokens. However, a critical design flaw exists where initializing the token with a `maxSupply` of zero effectively bypasses the maximum supply limit, allowing for unlimited minting. Additionally, the contract relies on a centralized `DEFAULT_ADMIN_ROLE` for critical operations, posing a single point of control risk. Immutable token parameters, while providing stability, also limit future adaptability.

1 High1 Medium1 Informational
Volume 24h
$4.10M
Liquidity
$4.12M
Price
$0.102
Token Age
10mo
Top 10 Holders
98.1%

Security Findings

1 High1 Med1 Info
High

Max Supply Bypass if Zero

H-01The `mint` function includes a check `if (i_maxSupply != 0 && totalSupply() + amount > i_maxSupply) revert MaxSupplyExceeded(...)`. If `i_maxSupply` is initialized to `0` in the constructor, the condition `i_maxSupply != 0` evaluates to `false`. Due to short-circuiting in the `&&` operator, the second part of the condition (`totalSupply() + amount > i_maxSupply`) is never evaluated. This effectively bypasses the maximum supply check, allowing for an unlimited supply of tokens to be minted if `maxSupply_` is set to `0` during deployment, contrary to the apparent intent of having a `maxSupply` parameter.
IssueThe `mint` function includes a check `if (i_maxSupply != 0 && totalSupply() + amount > i_maxSupply) revert MaxSupplyExceeded(...)`. If `i_maxSupply` is initialized to `0` in the constructor, the condition `i_maxSupply != 0` evaluates to `false`. Due to short-circuiting in the `&&` operator, the second part of the condition (`totalSupply() + amount > i_maxSupply`) is never evaluated. This effectively bypasses the maximum supply check, allowing for an unlimited supply of tokens to be minted if `maxSupply_` is set to `0` during deployment, contrary to the apparent intent of having a `maxSupply` parameter.
FixModify the `mint` function's condition to explicitly check for a positive `maxSupply` before enforcing the limit. For example, change `if (i_maxSupply != 0 && ...)` to `if (i_maxSupply > 0 && ...)` or restructure the logic to handle `i_maxSupply == 0` as an 'unlimited' case if that is the intended behavior, or revert in the constructor if `maxSupply_` is 0 and a limit is always expected.
StatusUnresolved
Medium

Centralized Control by DEFAULT_ADMIN_ROLE

M-01The `DEFAULT_ADMIN_ROLE` holds significant power within the contract. The address with this role can grant and revoke `MINTER_ROLE` and `BURNER_ROLE`, effectively controlling the token's supply. Additionally, the `setCCIPAdmin` function, which transfers the `s_ccipAdmin` role, is also restricted to the `DEFAULT_ADMIN_ROLE`. This centralization introduces a single point of failure, where compromise of the `DEFAULT_ADMIN_ROLE` key could lead to unauthorized minting, burning, or administrative changes.
IssueThe `DEFAULT_ADMIN_ROLE` holds significant power within the contract. The address with this role can grant and revoke `MINTER_ROLE` and `BURNER_ROLE`, effectively controlling the token's supply. Additionally, the `setCCIPAdmin` function, which transfers the `s_ccipAdmin` role, is also restricted to the `DEFAULT_ADMIN_ROLE`. This centralization introduces a single point of failure, where compromise of the `DEFAULT_ADMIN_ROLE` key could lead to unauthorized minting, burning, or administrative changes.
FixConsider implementing a multi-signature wallet for the `DEFAULT_ADMIN_ROLE` to distribute control and reduce the risk associated with a single point of failure. For critical operations like granting/revoking roles or changing the `ccipAdmin`, consider adding time-locks to allow for community review or emergency intervention periods.
StatusUnresolved
Info

Immutable Token Parameters

I-01The `i_decimals` and `i_maxSupply` variables are declared as `immutable`, meaning their values are set once in the constructor and cannot be changed thereafter. While this provides stability and predictability for the token's core properties, it also means that these parameters cannot be adjusted in the future, even if unforeseen circumstances or evolving protocol requirements necessitate a change.
IssueThe `i_decimals` and `i_maxSupply` variables are declared as `immutable`, meaning their values are set once in the constructor and cannot be changed thereafter. While this provides stability and predictability for the token's core properties, it also means that these parameters cannot be adjusted in the future, even if unforeseen circumstances or evolving protocol requirements necessitate a change.
FixEnsure that the chosen `decimals` and `maxSupply` values are thoroughly reviewed and confirmed to meet all current and anticipated future requirements of the protocol. If future flexibility for these parameters is desired, consider an upgradeable contract pattern or a mechanism to migrate to a new token contract.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract is built upon well-audited OpenZeppelin libraries (ERC20, ERC20Burnable, AccessControl), contributing to strong code security (7.2). It includes robust checks in `_transfer`, `_approve`, and `mint` to prevent tokens from being sent to or approved by the contract itself, enhancing operational safety (7.8). However, a significant technical vulnerability (7.2) lies in the `mint` function's `maxSupply` check, which can be bypassed if `i_maxSupply` is initialized to zero, leading to potential unlimited token issuance. The access control (7.3) for minting and burning roles is appropriately enforced via `AccessControl` roles, but the `DEFAULT_ADMIN_ROLE` holds substantial power.

GovernanceHigh1/10

The economic model (7.4) is based on a standard ERC-20 token with a configurable maximum supply and pre-minting. A key economic risk is the potential for unlimited token supply if `i_maxSupply` is initialized to zero, which could devalue existing tokens. Governance (7.5) is centralized, with the `DEFAULT_ADMIN_ROLE` having control over granting `MINTER_ROLE` and `BURNER_ROLE`, as well as setting the `s_ccipAdmin`. This centralization, while common, introduces a single point of failure and requires robust key management for the admin address.

UpgradesHigh3/10

The contract is not designed as an upgradeable proxy (7.7). Therefore, there are no specific upgrade safety issues to assess. Any changes to the contract logic would require a new deployment and migration of assets, if applicable.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

98.1% in top 10
97.0% in wallets1.1% in contracts
Effective Concentration97.4%

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

$4.19M across 7 pairs
Pancakeswap v3USDTanalysed$4.12M98.3%Pancakeswap v3USDf$51.5K1.2%UniswapUSDT$20.5K0.5%Pancakeswap v3USDT$2130.0%Pancakeswap v2火星$40.0%Pancakeswap v2USDT$00.0%
Show 1 more pairShow less
Pancakeswap v2WBNB$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 Holder98.9%
Top-3 Unlocked99.8%

Key Addresses

6 addresses
Deployer
0xbb5e…4153
Unlocked LP Held By
0x3dc3…2f0e0x5ad1…2cb00x4835…1de10x4a61…42010xe90d…1e95

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

What Raised This Score

8 factors
  • Ownership NOT renounced (admin/mint authority retained)
  • Mintable supply, nominal cap 1945%/year — effectively unbounded
  • Top-10 concentration > 70% (98.1% total → 97.4% effective; 97.0% in EOAs, 1.1% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 98.9% (independent LP — depth risk, pool = 98% of DEX liquidity)
  • LP top3 unlocked holders = 99.8% (independent LP — depth risk, pool = 98% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 Medium 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
Based Token (BASED)Critical RiskGRVTCritical RiskKGENCritical RiskBinance Brokers (BBROKERS)Critical RiskSpaceX (SPCXB)Critical RiskLorenzo Governance Token (BANK)Critical Risk

Would You Like a More Detailed Audit of Falcon Finance?

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

Get Detailed Audit