Quantum Audit Logo
Launch App

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

Is mfercoin Safe?

$MFERBase
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
SummaryAI Copilot

The mfercoin contract is an ERC20 token utilizing OpenZeppelin's Ownable pattern.

Read the full analysis
What raised the score
  • Top-10 concentration > 20%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
Exact factors
  • Top-10 concentration > 20% (41.9% total → 20.2% effective; 5.6% in EOAs, 36.3% in contracts — mild)
  • 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 45 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
36.3%Contracts5.6%Wallets58.1%Everyone else
36.3%Contracts5.6%58.1%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
41.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking36.3%
  • Walletsanonymous holders, free to sell5.6%
  • Everyone elsethe rest of the supply58.1%
Effective concentrationwhat the score reads20.2%
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$412.0K across 10 pairs
LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$233.4KShare of depth56.7%
LP Locked98.7% · Null Address, UNCX
Top-1 Unlocked Holder1.0%
Unlocked LP held by
0xf901…73730x53e9…31dc0x13ee…da330x90f8…9f9a0xc0a5…eadf

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

Security Findings

1 High1 Medium2 Info
High

Centralized Control over Token Transfers

The contract owner has the ability to pause and unpause all token transfers for non-owner accounts via the setPause function. While the _update override allows the owner to transfer tokens even when paused (intended for LP setup), this grants significant centralized control over the token's liquidity and functionality. Misuse or compromise of the owner key could lead to a denial of service for all token holders, severely impacting market operations and user trust (7.3 Access Control, 7.4 Economic, 7.8 Operations).H-01

Issue

The contract owner has the ability to pause and unpause all token transfers for non-owner accounts via the setPause function. While the _update override allows the owner to transfer tokens even when paused (intended for LP setup), this grants significant centralized control over the token's liquidity and functionality. Misuse or compromise of the owner key could lead to a denial of service for all token holders, severely impacting market operations and user trust (7.3 Access Control, 7.4 Economic, 7.8 Operations).

Fix

Implement a multi-signature wallet or a timelock contract for ownership to introduce a higher level of security and decentralization for critical functions like pausing/unpausing. Consider a community-driven governance mechanism for such powerful actions in the future. Clearly document the conditions under which the pause function would be used.

Status

Unresolved

Medium

Single Point of Failure for Owner Key

The contract relies on a single owner address for critical administrative functions, including the ability to pause and unpause token transfers. If this private key is compromised, lost, or becomes inaccessible, the project's ability to manage the token's operational state (e.g., unpausing for general trading after LP setup) would be severely impacted or permanently lost. This creates a single point of failure for the protocol's operations (7.8 Operations).M-01

Issue

The contract relies on a single owner address for critical administrative functions, including the ability to pause and unpause token transfers. If this private key is compromised, lost, or becomes inaccessible, the project's ability to manage the token's operational state (e.g., unpausing for general trading after LP setup) would be severely impacted or permanently lost. This creates a single point of failure for the protocol's operations (7.8 Operations).

Fix

Transfer ownership to a robust multi-signature wallet (e.g., Gnosis Safe) or a timelock contract. This distributes control among multiple trusted parties and/or introduces a delay for critical actions, significantly reducing the risk associated with a single compromised or lost key. Ensure the chosen multi-sig or timelock solution is itself well-audited and securely managed.

Status

Unresolved

Info

Initial Paused State for LP Setup

The contract is deployed with the _paused state set to true in the constructor. This means that immediately after deployment, only the owner can transfer tokens, while all other transfers are restricted. The contract comments indicate this is intended for 'LP setup' (7.1 Architecture, 7.8 Operations). Users should be aware that the token will not be generally transferable until the owner explicitly calls setPause(false) to unpause it.I-01

Issue

The contract is deployed with the _paused state set to true in the constructor. This means that immediately after deployment, only the owner can transfer tokens, while all other transfers are restricted. The contract comments indicate this is intended for 'LP setup' (7.1 Architecture, 7.8 Operations). Users should be aware that the token will not be generally transferable until the owner explicitly calls setPause(false) to unpause it.

Fix

Ensure clear and prominent communication to the community regarding the initial paused state, its purpose, and the expected timeline for unpausing the contract. This transparency helps manage user expectations and builds trust.

Status

Unresolved

Info

No Explicit Mechanism to Encourage Ownership Transfer to Secure Entity

While the Ownable contract provides a transferOwnership function, the mfercoin contract itself does not include any explicit mechanism, such as a post-deployment checklist or a time-locked transfer, to encourage or enforce the transfer of ownership to a more secure entity like a multi-signature wallet or a timelock contract (7.8 Operations). This leaves the decision entirely to the deployer, who might not prioritize this critical security step.I-02

Issue

While the Ownable contract provides a transferOwnership function, the mfercoin contract itself does not include any explicit mechanism, such as a post-deployment checklist or a time-locked transfer, to encourage or enforce the transfer of ownership to a more secure entity like a multi-signature wallet or a timelock contract (7.8 Operations). This leaves the decision entirely to the deployer, who might not prioritize this critical security step.

Fix

Consider adding a comment or a post-deployment script that explicitly recommends transferring ownership to a multi-signature wallet or a timelock contract. This serves as a strong reminder and best practice guidance for the project team to enhance the long-term security and decentralization of the token.

Status

Unresolved

Analysis

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

The mfercoin contract is an ERC20 token utilizing OpenZeppelin's Ownable pattern. It features a fixed maximum supply minted entirely to the deployer at creation and includes a pause mechanism that initially restricts transfers to the owner for LP setup. While the code is well-structured and uses audited libraries, the high degree of centralized control by the owner over token transfers and initial supply distribution presents significant economic and operational risks.

Technical9/10Low risk

The contract leverages battle-tested OpenZeppelin libraries for ERC20 and Ownable functionalities, contributing to robust code security (7.2 Code Security). The _update function correctly prevents zero-value transfers and implements a pause mechanism that exempts the owner for LP distribution. However, the owner's ability to pause all non-owner transfers introduces a significant centralization point (7.3 Access Control), which is a technical risk. No reentrancy or integer overflow vulnerabilities were identified.

Governance9/10Low risk

The economic model is based on a fixed supply ERC20 token, with the entire MAX_SUPPLY minted to the deployer at inception (7.4 Economic). This creates a highly centralized initial distribution. The owner possesses significant power through the setPause function, allowing them to halt all non-owner transfers, which can severely impact market liquidity and user trust (7.5 Governance). This centralized control represents a high economic and governance risk.

Upgrades10/10Low risk

The mfercoin contract is not designed with upgradeability features (7.7 Upgrades). This simplifies the contract's architecture and eliminates risks associated with proxy patterns, such as storage collisions or upgrade path vulnerabilities. The immutability of the contract ensures that its logic cannot be changed post-deployment.

Final RecommendationWhat to do about this score

To mitigate the identified risks, it is strongly recommended that the project owner secure the owner's private key with the highest level of operational security, such as a hardware wallet or a multi-signature wallet.

Consider transferring ownership to a multi-signature wallet or a timelock contract to decentralize control and introduce a delay for critical operations, enhancing trust and reducing the single point of failure risk. Clearly communicate the purpose and duration of the initial paused state to the community to manage expectations and ensure transparency.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age2y
Contract0xe308…54ca
Deployer0xd393…0a36
Badge for your website
mfercoin 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, 20263Low
  2. Jul 28, 20260Low

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

Frequently Asked Questions

What is the $MFER contract address?

The mfercoin ($MFER) contract on Base is 0xe3086852a4b125803c815a158249ae468a3254ca. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is mfercoin a scam?

Quantum Audit's risk score for mfercoin is 3/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is $MFER liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $412.0K.

Who holds $MFER?

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

Would You Like a More Detailed Audit of mfercoin?

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