Quantum Audit Logo
Launch App

Honeypot, rug-pull and ownership checks

Is Mog Coin a Scam?

MOGEthereum
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
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance7/10Upgrades9/10Checks passed5 of 5Findings1 Critical · 2 High · 1 Medium · 1 Low · 1 Info6
SummaryAI Copilot

The MOG contract is an ERC-20 token with features such as transaction fees, automatic liquidity provision, and anti-whale mechanisms (max wallet/transaction limits).

Read the full analysis
What raised the score
  • Top-10 concentration > 30%
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 30% (59.2% total → 38.5% effective; 24.6% in EOAs, 34.6% in contracts — moderate)
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 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

Our automated scanner reviewed Mog Coin (MOG) on Ethereum. 5 of 5 security checks passed — see the full breakdown below.

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
34.6%Contracts24.6%Wallets40.8%Everyone else
34.6%Contracts24.6%Wallets40.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
59.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking34.6%
  • Walletsanonymous holders, free to sell24.6%
  • Everyone elsethe rest of the supply40.8%
Effective concentrationwhat the score reads38.5%
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$5.51M across 6 pairs

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$5.47MShare of depth99.2%
LP Locked100.0% · UNCX
Top-1 Unlocked Holder0.0%
Lock Expiry2092 (verified ≥ 1 year) · UNCX V2
Unlocked LP held by
0x2908…eb150xc325…bc1d0xae62…b44e0xac6e…83390x39c3…aa800xe945…36650x506c…419d0xb3ac…68a00xb9a1…1f7f

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

Security Findings

1 Critical2 High1 Medium1 Low1 Info
Critical

Irreversible Immutability of Critical Parameters Post-Renunciation

With ownership renounced, all owner-controlled functions (e.g., EditTax, set_Receivers, set_MaxWallet, set_MaxTX, openTrading, clearStuckETH, clearStuckToken) are permanently disabled. This means that if any critical parameter was misconfigured, or if TradingOpen was not called before renunciation, the token's functionality could be severely and irreversibly hampered or bricked, leading to a complete loss of utility or funds. For example, if TradingOpen was not called, trading might never be possible. Similarly, if clearStuckETH or clearStuckToken were needed, they are now unusable.C-01

Issue

With ownership renounced, all owner-controlled functions (e.g., EditTax, set_Receivers, set_MaxWallet, set_MaxTX, openTrading, clearStuckETH, clearStuckToken) are permanently disabled. This means that if any critical parameter was misconfigured, or if TradingOpen was not called before renunciation, the token's functionality could be severely and irreversibly hampered or bricked, leading to a complete loss of utility or funds. For example, if TradingOpen was not called, trading might never be possible. Similarly, if clearStuckETH or clearStuckToken were needed, they are now unusable.

Fix

This issue is irreversible for the current contract due to renounced ownership. For future projects, ensure all critical parameters are meticulously configured and all necessary administrative actions (like enabling trading) are completed and verified before renouncing ownership. Consider a phased approach to decentralization or a multi-sig/timelock for critical functions if full immutability is not desired immediately.

Status

Unresolved

High

High and Unchangeable Transaction Fees

The contract allows for significant transaction fees (liquidity, marketing, dev, buyback, burn) which are now immutable due to renounced ownership. The EditTax function, which could adjust buypercent, sellpercent, and transferpercent (affecting totalFee), is no longer callable. If the initial configuration set high fees, it could permanently deter trading, reduce liquidity, and make the token economically unviable for users, as these fees cannot be lowered.H-01

Issue

The contract allows for significant transaction fees (liquidity, marketing, dev, buyback, burn) which are now immutable due to renounced ownership. The EditTax function, which could adjust buypercent, sellpercent, and transferpercent (affecting totalFee), is no longer callable. If the initial configuration set high fees, it could permanently deter trading, reduce liquidity, and make the token economically unviable for users, as these fees cannot be lowered.

Fix

This issue is irreversible for the current contract. For future projects, carefully model the economic impact of transaction fees. If ownership is to be renounced, ensure that the initial fee structure is sustainable and competitive, as it cannot be altered post-renunciation. Consider community governance for fee adjustments if flexibility is desired.

Status

Unresolved

High

Unchangeable Max Wallet/Transaction Limits

The _maxTxAmount and _maxWalletToken limits are fixed after ownership renunciation. While intended as anti-whale measures, if set too restrictively (e.g., 1% of total supply), they can permanently hinder legitimate large transfers, prevent necessary liquidity pool rebalancing, or even block interactions with certain DeFi protocols. The set_MaxWallet and set_MaxTX functions, which could adjust these limits, are now unusable, potentially bricking the token's utility for certain use cases.H-02

Issue

The _maxTxAmount and _maxWalletToken limits are fixed after ownership renunciation. While intended as anti-whale measures, if set too restrictively (e.g., 1% of total supply), they can permanently hinder legitimate large transfers, prevent necessary liquidity pool rebalancing, or even block interactions with certain DeFi protocols. The set_MaxWallet and set_MaxTX functions, which could adjust these limits, are now unusable, potentially bricking the token's utility for certain use cases.

Fix

This issue is irreversible for the current contract. For future projects, carefully consider the implications of fixed max wallet and transaction limits. If ownership is to be renounced, ensure these limits are set to values that allow for healthy market operation and interaction with other protocols, or consider mechanisms for community-driven adjustments.

Status

Unresolved

Medium

Missing Zero Address Checks for Fee Receivers

The set_Receivers function, if called before ownership renunciation, allowed setting marketingFeeReceiver, buybackFeeReceiver, or devFeeReceiver to address(0) without explicit checks. If this occurred, the corresponding fees would be permanently burned instead of being directed to a functional address, potentially impacting project funding or the intended distribution of funds. While burnFeeReceiver is intentionally set to DEAD, other receivers should typically be valid addresses.M-01

Issue

The set_Receivers function, if called before ownership renunciation, allowed setting marketingFeeReceiver, buybackFeeReceiver, or devFeeReceiver to address(0) without explicit checks. If this occurred, the corresponding fees would be permanently burned instead of being directed to a functional address, potentially impacting project funding or the intended distribution of funds. While burnFeeReceiver is intentionally set to DEAD, other receivers should typically be valid addresses.

Fix

For future contracts, implement explicit require(newReceiver != address(0), "Receiver cannot be zero address") checks in functions that set critical addresses like fee receivers. This prevents accidental or malicious burning of funds intended for project operations.

Status

Unresolved

Low

Unused authorizations Mapping

The authorizations mapping in the Ownable contract is declared and initialized in the constructor by setting authorizations[_owner] = true. However, this mapping is never utilized by any other function within the contract (e.g., the onlyOwner modifier directly checks _owner == _msgSender()). This represents dead code, increasing contract size and potentially causing confusion for auditors or developers.L-01

Issue

The authorizations mapping in the Ownable contract is declared and initialized in the constructor by setting authorizations[_owner] = true. However, this mapping is never utilized by any other function within the contract (e.g., the onlyOwner modifier directly checks _owner == _msgSender()). This represents dead code, increasing contract size and potentially causing confusion for auditors or developers.

Fix

Remove the unused authorizations mapping and its initialization from the Ownable contract to reduce contract size and improve code clarity. If its functionality was intended, ensure it is properly integrated into the access control logic.

Status

Unresolved

Info

Hardcoded DEX Router Address

The Uniswap V2 router address (0x7a25…488D) is hardcoded within the contract's constructor. While common for established protocols, this design choice means the contract cannot adapt if the router address changes, is deprecated, or becomes compromised. Any such event would render the contract's internal swap and liquidity functions inoperable.I-01

Issue

The Uniswap V2 router address () is hardcoded within the contract's constructor. While common for established protocols, this design choice means the contract cannot adapt if the router address changes, is deprecated, or becomes compromised. Any such event would render the contract's internal swap and liquidity functions inoperable.

Fix

For future contracts, consider making critical external contract addresses configurable by an authorized entity (e.g., via an onlyOwner function) or through a governance mechanism. This allows for adaptability to changes in the ecosystem without requiring a new contract deployment.

Status

Unresolved

Analysis

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

The MOG contract is an ERC-20 token with features such as transaction fees, automatic liquidity provision, and anti-whale mechanisms (max wallet/transaction limits). The contract utilizes the Ownable pattern, and the prefill data indicates that ownership has been renounced. This renunciation makes all owner-controlled parameters and functions immutable, which is the primary driver of the identified high and critical risks. The provided contract code was truncated, specifically the core transfer logic, but the analysis assumes the fee and limit mechanisms are correctly implemented within the missing sections based on the declared state variables and mappings.

Technical6/10Medium risk

The contract employs SafeMath for arithmetic operations, mitigating common integer overflow/underflow vulnerabilities (7.2 Code Security). A swapping modifier is used to prevent reentrancy during internal swap operations, which is a good practice (7.2 Code Security). However, the renunciation of ownership has rendered all owner-controlled functions permanently inaccessible, meaning critical operational parameters cannot be adjusted (7.1 Architecture, 7.3 Access Control). This immutability poses a significant technical risk if any initial configuration was suboptimal or if the TradingOpen flag was not set before renunciation.

Governance7/10Low risk

Before ownership renunciation, the contract had a highly centralized governance model, with the owner able to modify transaction fees, set receiver addresses, and adjust max wallet/transaction limits (7.5 Governance). Post-renunciation, these parameters are permanently fixed. This creates a high economic risk if initial fees were set too high or if max limits are overly restrictive, potentially hindering trading and liquidity (7.4 Economic). The inability to recover stuck ETH or tokens (via clearStuckETH/clearStuckToken) after renunciation also poses an operational risk (7.8 Operations).

Upgrades9/10Low risk

The MOG contract is a standard (non-proxy) implementation and is not designed to be upgradeable (7.7 Upgrades). Therefore, there are no upgrade-specific risks associated with this contract. All deployed logic is final and immutable.

Final RecommendationWhat to do about this score

For projects considering renouncing ownership, it is paramount to conduct exhaustive pre-deployment testing and verification of all configurable parameters.

Ensure that all critical functions, such as enabling trading and setting appropriate fee structures and limits, are correctly executed before renunciation. Once ownership is renounced, the contract's behavior is permanently fixed, making any misconfiguration irreversible. Future projects should consider implementing a multi-signature wallet or a time-locked contract for critical administrative functions if full decentralization via ownership renunciation is not the immediate goal, allowing for controlled parameter adjustments.

Contract & Record

1 audit on record
TypeRouter, Token
NetworkEthereum
Token age3y
Contract0xaaee…1c7a
Deployer0x20e1…a8b8
Badge for your website
Mog Coin 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 11, 202626Low

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

Related Audits

6 more on the recordAll audits
Shiba InuSHIB · Ethereum26LowGrand Theft Auto VIGTAVI · Ethereum26LowUnipegUPEG · Ethereum26LowWrapped TAOWTAO · Ethereum26LowTelcoinTEL · Ethereum26LowStockereum.funSTOCKER · Ethereum26Low

Would You Like a More Detailed Audit of Mog Coin?

Paste the contract address into our AI-powered scanner for a deeper real-time report — free, with every scoring factor shown.

Get Detailed Audit Is this your token? Publish your own audit on this page