Quantum Audit Logo

Is Mog Coin a Scam?

Honeypot, rug-pull and ownership checks

Is this your token? Publish your own audit on this page →

Mog Coin MOG
0xaaee…1c7a
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive 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). 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.

1 Critical2 High1 Medium1 Low1 Informational
i Our automated scanner reviewed Mog Coin (MOG) on Ethereum. 5 of 5 security checks passed — see the full breakdown below.
Volume 24h
$247.0K
Liquidity
$5.47M
Price
$0.0000001104
Age
3y
Top 10 Holders
59.2%

Security Findings

1 Crit2 High1 Med1 Low1 Info
Critical

Irreversible Immutability of Critical Parameters Post-Renunciation

C-01With 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.
IssueWith 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.
FixThis 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.
StatusUnresolved
High

High and Unchangeable Transaction Fees

H-01The 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.
IssueThe 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.
FixThis 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.
StatusUnresolved
High

Unchangeable Max Wallet/Transaction Limits

H-02The `_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.
IssueThe `_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.
FixThis 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.
StatusUnresolved
Medium

Missing Zero Address Checks for Fee Receivers

M-01The `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.
IssueThe `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.
FixFor 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.
StatusUnresolved
Low

Unused `authorizations` Mapping

L-01The `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.
IssueThe `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.
FixRemove 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.
StatusUnresolved
Info

Hardcoded DEX Router Address

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

Category Ratings

TechnicalMedium6/10

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.

GovernanceLow7/10

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

UpgradesLow9/10

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.

Security Checklist

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

Holder Composition

59.2% in top 10
24.6% in wallets34.6% in contracts
Effective Concentration38.5%

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

$5.51M across 6 pairs
Uniswap v2WETHanalysed$5.47M99.2%Uniswap v4rust$28.9K0.5%Uniswap v3WETH$13.3K0.2%Uniswap v4ZIK$2.0K0.0%Uniswap v3USDS$1070.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 Locked100.0% · UNCX
Top-1 Unlocked Holder0.0%
Lock Expiry2092 (verified ≥ 1 year) · UNCX V2

Key Addresses

10 addresses
Deployer
0x20e1…a8b8
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.

What Raised This Score

5 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

Related Audits

6 more on the record
Shiba Inu (SHIB)Medium RiskGrand Theft Auto VI (GTAVI)Medium RiskUnipeg (UPEG)Medium RiskWrapped TAO (WTAO)Medium RiskTelcoin (TEL)Medium RiskStockereum.fun (STOCKER)Medium Risk

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