The Tokenomics of Mog Coin (MOG)

What MOG is, mechanically

Mog Coin (MOG) is an ERC-20 memecoin whose “product” is culture distribution, not a protocol that needs to pay for its own consensus security. The official site frames MOG as having no formal team or roadmap, and explicitly disclaims intrinsic value or expectation of financial return.

From a token design standpoint, that matters because it pushes almost every meaningful question away from emissions and validator incentives, and toward execution risk in the smart contract and in bridging. MOG’s official site lists contract addresses on Ethereum, Base, Solana, and BNB Chain. For a point of comparison with another culture-first memecoin, see our memecoin-style design review of MEW.

The project also publishes a short PDF whitepaper that positions MOG as a community-bootstrapped ERC-20 launched with a fixed initial supply, and states the token is bridgeable to multiple chains (Ethereum, Base, Solana, BNB Chain).

CoinGecko’s market listing corroborates that this is the Ethereum contract most markets reference, and it surfaces the same Ethereum contract address.

Security-budget lens: because MOG is not a base-layer network token, it does not create a native “security budget” through issuance. It inherits security from the settlement layer you transact on, and inherits bridge security assumptions when you move it cross-chain.

Supply: fixed cap, burn history, no ongoing emissions

MOG’s published initial supply is 420,690,000,000,000 tokens. For contrast with an emissions-driven network, see our EOS tokenomics review.

The whitepaper also reports 30,122,473,566,783.2942 tokens burned, leaving a circulating supply of 390,567,526,433,216.71 at the time of that document.

On market data aggregators, the commonly displayed “now” supply is in the same range. CoinGecko shows a circulating supply of 390,561,998,053,223, a total supply of 390,561,998,053,223, and a max supply of 420,690,000,000,000.

On Ethereum, the token contract source code sets the initial _totalSupply to 420,690,000,000,000 (with 18 decimals).

That same contract includes logic that reduces _totalSupply when burn-tokens are applied in takeFee, which is consistent with a declining “current total supply” over time.

Critically, there is no emissions schedule described in the project’s own documentation. The contract’s supply is instantiated at deployment and then can move down via burn logic. There is no described mechanism for protocol-driven inflation that would continuously fund participants.

Allocations and distribution are not presented as a structured “token allocation plan” in the project’s primary docs. The on-chain reality at deployment is straightforward.

• Genesis mint to deployer: 100% / 420,690,000,000,000 tokens were assigned to msg.sender in the constructor (the deploying address), and emitted via a Transfer from the zero address.

That is not a judgement. It is just the baseline you need if you care about distribution credibility. A “fair launch via Uniswap” can still be true socially, while the technical starting point is one address holding the entire supply before liquidity provisioning and market distribution. The official site does describe a Uniswap V2 LP fair launch.

Fees, burns, and fiscal flows: what the contract can do vs what it claims today

The official site states 0% tax.

The Ethereum contract source code, however, is not a minimal ERC-20. It contains a fee system, a burn component, and swapback logic that can convert accumulated fee-tokens into ETH and route that ETH into liquidity and receiver wallets.

At the source-code level, the fee parameters are initialized as liquidityFee = 2 and burnFee = 2, with other fee components at 0, and feeDenominator = 100. That implies a base totalFee of 4 out of 100 before applying the buy/sell/transfer multipliers.

The contract also defines three multipliers (buypercent, sellpercent, transferpercent). Fees are computed as:

feeAmount = amount × totalFee × percent ÷ (feeDenominator × 100).

Those multipliers can be changed by the owner through setStructure.

More importantly, startTrading (owner-only) flips TradingOpen to true and sets buypercent = 1400, sellpercent = 800, and transferpercent = 1000 in the contract source code.

Then reduceFee (owner-only) sets all three multipliers back to 100.

That design pattern is common in memecoin launches. It is also why “0% tax” claims should always be treated as a live state question, not a branding statement.

We do have an external check: CertiK’s token scan reports Buy tax: 0% and Sell tax: 0% at the time of its scan.

Even if taxes are currently 0%, the historical burn reported in the whitepaper implies there has been meaningful supply reduction already.

One more hard point for infrastructure-minded readers: Etherscan shows no submitted audit on the contract page.

Net takeaway: the tokenomics are not “emissions-driven.” They are “market-flow-driven.” Burns and any fee extraction happen only if transfers happen, and only if fees are turned on. That gives you a clean mental model for sustainability. There is no autonomous security budget. There is, at best, an optional transactional rake and optional burn.

Governance and parameter control: who can change what

MOG’s Ethereum contract has explicit owner-only controls over fee structure (setParameters and setStructure), wallet receivers (setWallets), swapback settings (setSwapBackSettings), and launch gating (startTrading).

It also contains limit controls: at initialization, the source code sets both _maxTxAmount and _maxWalletToken to 1% of total supply, and provides owner-only functions to remove limits or adjust the max wallet rule.

For governance, there is no on-chain DAO system documented in primary sources. The meaningful question is whether the owner still exists.

CertiK reports the owner address as 0x000…000 and explicitly states “Owner privilege has been renounced.”

If owner renunciation is accurate, then the admin surface becomes inert. That is a material change in risk profile. A fee-capable contract with an active owner is a governance risk. A fee-capable contract with ownership renounced is a monitoring problem, not a governance problem.

Monitoring problem because even with a renounced owner on Ethereum, the token’s multi-chain representations introduce their own administrative control planes. The official site says the “Official MOG Bridge” is powered by the canonical Base bridge and LayerZero, and claims bridged MOG is “100% backed 1:1 with mainnet.”

Security budget maximalist view: MOG outsources security, and that is both fine and limiting

MOG does not and cannot “pay validators” because it has no validator set. Ethereum and the other execution environments do not secure themselves with MOG. They secure themselves with their own native economics.

This has a clean upside. MOG avoids the classic trap where projects slash issuance to look “sound,” then discover they have no replacement security budget via fees, and end up with a brittle validator market. That entire failure mode does not apply here, because MOG is not a chain asset.

It also has a hard limit. MOG cannot fund its own infrastructure permanence in-protocol. There is no mandatory fee flow into a treasury described in primary docs, and no emissions program to subsidize liquidity or security-adjacent participation. The official posture is closer to “tokenized culture” than “tokenized cashflow.”

So the economic sustainability question is not “will issuance taper too fast.” It is “can off-chain coordination and exchange liquidity keep this asset tradable and meaningfully distributed across venues over time.” That is a social sustainability problem, not a protocol one.

Where security does show up is bridging. If you accept the official claim that non-mainnet MOG is 1:1 backed by mainnet, then the asset’s cross-chain integrity depends on bridge correctness, bridge governance, and the operational security of any relayers and message-passing systems involved.

Risk analysis

Public docs are thin on the parts that matter for modeling long-run behavior. The whitepaper gives supply numbers and a positioning story. It does not specify governance processes, bridge trust assumptions, or parameter immutability guarantees beyond what you can infer from on-chain ownership state. If you need definitions for the moving parts, our tokenomics FAQ covers the basics.

On-chain, the Ethereum contract is more complex than “plain ERC-20.” It has fee mechanics, swapbacks, and launch gating. That is manageable if ownership is renounced, but it raises the cost of continuous monitoring.

Top 3 risks

1. Bridge integrity and cross-chain supply drift. Trigger: a bridge exploit, compromised message layer, or operational failure in the bridge stack. Mechanism: “1:1 backed” representations on Base, Solana, or BNB Chain can become undercollateralized, overissued, frozen, or redeemed asymmetrically if bridging invariants break. Who bears it: users holding non-mainnet MOG, liquidity pools on destination chains, and any protocols accepting bridged MOG as collateral. Measurable indicators: unexpected mint events on destination contracts, halted bridge withdrawals, widening price gaps between mainnet and destination-chain pools, and changes to official bridge messaging.

2. Parameter uncertainty around taxes and trading controls. Trigger: discovery that “0% tax” differs by venue, router path, or chain representation, or that transfer controls behave differently under stress. Mechanism: the Ethereum contract includes fee logic, swapback logic, and trading gating, and scanners explicitly flag that token tax can be modified by privileged roles even while also reporting renounced ownership. Who bears it: market makers and LPs (fee uncertainty changes expected inventory loss), and retail users (execution outcomes differ from expectation). Measurable indicators: buy/sell simulation outputs changing across scanners, unusual contract token balances (fee accumulation), and discrepancies between official tax claims and observed transfer deltas.

3. Concentration and liquidity reflexivity. Trigger: large-holder distribution shifts, exchange delistings, or liquidity migration away from core venues. Mechanism: high concentration amplifies volatility, which can degrade liquidity and widen spreads, which then further increases price impact and accelerates adverse selection in LPs. Who bears it: LPs first, then all holders through price impact and impaired exit liquidity. Measurable indicators: top-holder ratios, dead-address share, exchange net flows, and persistent drops in pool depth.

Dominant risk: bridge integrity and cross-chain supply drift

The dominant risk is bridge security because it is the one risk that can destroy the asset’s coherence without any warning from “tokenomics” in the narrow sense. For a comparable case study on a bridged asset, see our bridged asset review.

The official site makes a strong claim: bridged MOG is the “same MOG,” “100% backed 1:1 with mainnet,” and the bridge is powered by the canonical Base bridge and LayerZero.

Those statements are directionally reassuring, but they are not a formal security model. “Canonical” solves one class of risk on one route. It does not automatically solve multi-route risk across four chains. LayerZero-based designs, in general, shift the question to the security of the message verification path, the configuration of DVNs or oracle/relayer sets (depending on version), and the governance around upgrades. None of that is specified in primary MOG documentation.

As a result, you cannot model “supply” as a single number unless you pin the chain context. You also cannot treat a DEX price on a destination chain as equivalent to mainnet price without continuously validating redeemability.

For a security-budget maximalist, this is the key asymmetry. On Ethereum mainnet, MOG’s safety mostly reduces to Ethereum execution correctness plus MOG’s contract correctness. On a destination chain, MOG’s safety becomes: destination chain correctness + destination token program correctness + bridge correctness + bridge governance correctness + operational security. Each layer can fail independently.

This is not theoretical. Bridges fail more often than base layers. If the bridge fails in a way that traps assets, “1:1 backed” becomes a statement about a frozen backing, not a usable redemption path. If the bridge fails in a way that overissues, destination-chain MOG becomes a credit instrument against a broken custodian model. In both cases, market pricing can decouple violently, and holders who thought they owned “the same MOG” discover they own a chain-local claim with different risk.

Concrete monitoring that actually matters here:

Track the official contract addresses on each chain and reconcile them with the official site before interacting.

Track bridge health as a first-class metric. If redemption is impaired, you should expect persistent basis between chains. The tokenomics do not fix that. They cannot.

If you’re doing tokenomics consulting or token economy design work around assets like MOG, your deliverable should be a live monitoring spec, not a one-time spreadsheet. Our methodology overview explains the best-practice framing for that kind of work.

If you want hands-on support, see our design services for tokenomics design.

This article is part of our Tokenomics Deep Dive series.