Quantum Audit Logo

Is mfercoin Safe?

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

mfercoin $MFER
0xe308…54ca
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

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.

1 High1 Medium2 Informational
Volume 24h
$5.7K
Liquidity
$233.4K
Price
$0.0008118
Token Age
2y
Top 10 Holders
41.9%

Security Findings

1 High1 Med2 Info
High

Centralized Control over Token Transfers

H-01The 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).
IssueThe 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).
FixImplement 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.
StatusUnresolved
Medium

Single Point of Failure for Owner Key

M-01The 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).
IssueThe 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).
FixTransfer 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.
StatusUnresolved
Info

Initial Paused State for LP Setup

I-01The 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.
IssueThe 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.
FixEnsure 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.
StatusUnresolved
Info

No Explicit Mechanism to Encourage Ownership Transfer to Secure Entity

I-02While 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.
IssueWhile 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.
FixConsider 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.
StatusUnresolved

Category Ratings

TechnicalLow9/10

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.

GovernanceLow9/10

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.

UpgradesLow10/10

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.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

41.9% in top 10
5.6% in wallets36.3% in contracts
Effective Concentration20.2%

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

$412.0K across 10 pairs
Uniswap v2WETHanalysed$233.4K56.7%Uniswap v3WETH$177.3K43.0%Uniswap v2VIRTUAL$1.2K0.3%Hydrex CLAMMWETH$320.0%9mm V3WETH$200.0%AerodromeBNKR$140.0%
Show 4 more pairsShow less
Uniswap v4wBLT$60.0%SushiswapWETH$50.0%Uniswap v4ETH$50.0%Swapbased V2WETH$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

LP Locked98.7% · Null Address, UNCX
Top-1 Unlocked Holder1.0%

Key Addresses

6 addresses
Deployer
0xd393…0a36
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.

What Raised This Score

3 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

Related Audits

6 more on the record
doginmeLow RiskToshiLow RiskKeyboard Cat (KEYCAT)Low RiskUnit 00 - Rei (REI)Low RiskMr. Miggles (MIGGLES)Low RiskVEIL Token (VEIL)Low Risk

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