Quantum Audit Logo
Launch App

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

Is Filecoin Safe?

FILBNB 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
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance3/10Upgrades1/10Checks passed3 of 7Findings1 Medium · 1 Low · 2 Info4
SummaryAI Copilot

The audit of the BEP20 Token implementation contract identified a medium-level risk related to centralized control over token minting, which could lead to supply manipulation if the owner's key is compromised.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Admin is EOA
  • Top-10 concentration > 20%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 59.8%
  • LP top3 unlocked holders = 82.3%
  • 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)
  • Admin is EOA (single key controls upgrades)
  • Top-10 concentration > 20% (30.7% total → 29.9% effective; 29.3% in EOAs, 1.4% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 59.8% (independent LP — depth risk, pool = 34% of DEX liquidity)
  • LP top3 unlocked holders = 82.3% (independent LP — depth risk, pool = 34% of DEX liquidity)
  • 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 43 of 7 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
1.4%29.3%Wallets69.3%Everyone else
29.3%Wallets69.3%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
30.7%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking1.4%
  • Walletsanonymous holders, free to sell29.3%
  • Everyone elsethe rest of the supply69.3%
Effective concentrationwhat the score reads29.9%
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$176.1K across 30 pairs
Show 4 more pairs

The 20 remaining pairs hold $20.1K 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$60.5KShare of depth34.3%
Top-1 Unlocked Holder59.8%
Top-3 Unlocked82.3%
Unlocked LP held by
0x73fe…e24e0x5eec…ab700x90f3…25190x9cbb…3e160xa306…cb4b0x2789…90bf0xf8ac…66660x5e79…ca580x384d…ff6e0x9b4c…7dcb

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

Security Findings

1 Medium1 Low2 Info
Medium

Centralized Control of Token Supply

The _owner address has the sole authority to mint new tokens if the _mintable flag is set to true during initialization. This introduces a single point of failure where a compromised owner key could lead to arbitrary inflation of the token supply, devaluing existing tokens. This impacts access control (7.3) and economic stability (7.4).M-01

Issue

The _owner address has the sole authority to mint new tokens if the _mintable flag is set to true during initialization. This introduces a single point of failure where a compromised owner key could lead to arbitrary inflation of the token supply, devaluing existing tokens. This impacts access control (7.3) and economic stability (7.4).

Fix

Implement a multi-signature wallet for the owner address to control critical functions like mint. This distributes control and requires multiple approvals for sensitive operations, significantly reducing the risk of a single point of compromise.

Status

Unresolved

Low

Immutability of _mintable Flag

The _mintable flag, which controls whether new tokens can be minted, is set only during the initialize function and cannot be changed thereafter. This design choice means the token's minting capability is permanently fixed upon deployment, which might limit future flexibility if the project's requirements evolve. This is a design consideration (7.1) and governance aspect (7.5).L-01

Issue

The _mintable flag, which controls whether new tokens can be minted, is set only during the initialize function and cannot be changed thereafter. This design choice means the token's minting capability is permanently fixed upon deployment, which might limit future flexibility if the project's requirements evolve. This is a design consideration (7.1) and governance aspect (7.5).

Fix

If future flexibility is desired, consider adding an onlyOwner function to toggle the _mintable flag. Alternatively, clearly document this immutability as a core design decision for the token's economic model.

Status

Unresolved

Info

Incomplete _burnFrom Function

The provided source code for the _burnFrom internal function is truncated and therefore incomplete. While this function is not called by any other public or internal function in the provided code, its incompleteness represents a code quality issue and a potential bug if it were intended for future use or if other parts of the system rely on its full implementation. This affects code security (7.2).I-01

Issue

The provided source code for the _burnFrom internal function is truncated and therefore incomplete. While this function is not called by any other public or internal function in the provided code, its incompleteness represents a code quality issue and a potential bug if it were intended for future use or if other parts of the system rely on its full implementation. This affects code security (7.2).

Fix

Complete the implementation of the _burnFrom function to ensure code correctness and maintainability. If it's not intended for use, consider removing it to avoid confusion.

Status

Unresolved

Info

Use of Older Solidity Version

The contract uses pragma solidity ^0.6.0. While functional, newer Solidity versions (e.g., ^0.8.0) offer additional security features (like default checked arithmetic), gas optimizations, and clearer error messages. Migrating to a newer version could improve overall code robustness and efficiency (7.2 Code Security).I-02

Issue

The contract uses pragma solidity ^0.6.0. While functional, newer Solidity versions (e.g., ^0.8.0) offer additional security features (like default checked arithmetic), gas optimizations, and clearer error messages. Migrating to a newer version could improve overall code robustness and efficiency (7.2 Code Security).

Fix

Consider upgrading the Solidity compiler version to ^0.8.0 or higher. Thoroughly test the contract after migration to ensure compatibility and correct functionality.

Status

Unresolved

Analysis

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

The audit of the BEP20 Token implementation contract identified a medium-level risk related to centralized control over token minting, which could lead to supply manipulation if the owner's key is compromised. Minor issues include the immutability of the mintable flag and an incomplete internal function. The contract demonstrates good practices for upgradeability and uses SafeMath to prevent arithmetic overflows. Overall, the contract is well-structured but requires careful management of the owner's privileges.

Technical7/10Low risk

The contract demonstrates good technical practices by utilizing SafeMath for all arithmetic operations, effectively preventing integer overflow/underflow vulnerabilities (7.2 Code Security). It adheres to the BEP20 standard, providing expected token functionalities like transfer, approve, and allowance. The Initializable pattern is correctly implemented for proxy compatibility, ensuring proper state initialization (7.1 Architecture). However, the _burnFrom internal function is incomplete in the provided source, which is a code quality concern (7.2 Code Security). Additionally, the use of an older Solidity version (^0.6.0) means it misses out on some newer compiler optimizations and security features (7.2 Code Security).

Governance3/10High risk

The contract implements a standard Ownable pattern, granting the _owner address significant control over critical functions such as mint and transferOwnership (7.3 Access Control). This centralized control allows the owner to increase the token supply if the _mintable flag is true, posing an economic risk if the owner's key is compromised (7.4 Economic). The _mintable flag is set once during initialization and cannot be changed, fixing the token's minting capability permanently (7.5 Governance). While typical for many tokens, this centralization requires robust owner key management.

Upgrades1/10High risk

The contract is designed as an upgradeable implementation, correctly using the Initializable base contract and an empty constructor (7.7 Upgrades). This setup ensures that state variables are initialized via the initialize function, which is called once through the proxy, preventing re-initialization issues. The use of EIP1967_TRANSPARENT proxy pattern implies that storage layout compatibility must be carefully maintained in future upgrades to avoid storage collisions (7.7 Upgrades). Overall, the upgradeability pattern is well-implemented for this type of proxy.

Final RecommendationWhat to do about this score

It is strongly recommended to secure the owner's private key with robust measures, such as a multi-signature wallet, to mitigate the risk of centralized control over token minting.

Consider the long-term implications of the immutable _mintable flag and ensure it aligns with the project's future vision. Complete the _burnFrom function to improve code quality and prevent potential issues if it is ever intended for use. Finally, evaluate upgrading to a more recent Solidity compiler version to benefit from enhanced security features and optimizations.

Contract & Record

1 audit on record
TypeBEP20UpgradeableProxy
NetworkBNB Chain
Token age3y
Contract0x0d8c…e153
Deployer0x81b7…3cce
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminEOA (single key controls upgrades)
ImplementationVerified source
Badge for your website
Filecoin 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, 202661Medium
  2. Sep 2, 202663Medium

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

Related Audits

6 more on the recordAll audits
BNB AttestationBAS · BNB Chain61MediumGriffinAIGAIN · BNB Chain61MediumStarpower NetworkSTAR · BNB Chain62MediumXRP TokenXRP · BNB Chain62MediumBTCB TokenBTCB · BNB Chain60Medium孙小圣BNB Chain60Medium

Would You Like a More Detailed Audit of Filecoin?

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