Quantum Audit Logo
Launch App

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

Is Falcon Finance Safe?

FFBNB Chain
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
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance1/10Upgrades3/10Checks passed2 of 5Findings1 High · 1 Medium · 1 Info3
SummaryAI Copilot

The BurnMintERC20 contract implements a standard ERC-20 token with minting and burning capabilities, leveraging OpenZeppelin's AccessControl for role management.

Read the full analysis
What raised the score
  • Ownership not renounced
  • Mintable supply, nominal cap 1945%/year — effectively unbounded
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 98.9%
  • LP top3 unlocked holders = 99.8%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
97.0%Wallets1.9%
97.0%Wallets
ContractsWalletsEveryone elseBubble area = share of supply
98.1%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking1.1%
  • Walletsanonymous holders, free to sell97.0%
  • Everyone elsethe rest of the supply1.9%
Effective concentrationwhat the score reads97.4%
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$4.19M across 7 pairs
Show 1 more pair

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$4.12MShare of depth98.3%
Top-1 Unlocked Holder98.9%
Top-3 Unlocked99.8%
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.

Security Findings

1 High1 Medium1 Info
High

Max Supply Bypass if Zero

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

Issue

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

Fix

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

Status

Unresolved

Medium

Centralized Control by DEFAULT_ADMIN_ROLE

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

Issue

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

Fix

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

Status

Unresolved

Info

Immutable Token Parameters

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical6/10Medium risk

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.

Governance1/10High risk

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.

Upgrades3/10High risk

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.

Final RecommendationWhat to do about this score

It is crucial to ensure that the maxSupply_ parameter in the constructor is always initialized to a non-zero value greater than preMint if a maximum supply limit is intended.

Implement robust operational procedures for the DEFAULT_ADMIN_ROLE to mitigate the risks associated with centralized control, including multi-signature wallets or time-locks for critical actions. Consider the implications of immutable parameters and ensure they align with long-term project goals before deployment.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age10mo
Contract0xac23…4db2
Deployer0xbb5e…4153
Badge for your website
Falcon Finance 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. Aug 12, 202678High

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

Related Audits

6 more on the recordAll audits
Based TokenBASED · BNB Chain78HighGRVTBNB Chain78HighKGENBNB Chain78HighBinance BrokersBBROKERS · BNB Chain78HighBitcoin Cash TokenBCH · BNB Chain78HighAleoBNB Chain78High

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