Skip to content

Contract Analysis

DISCLAIMER // NFA // DYOR

This analysis is based on observations of the contract behavior. We are not smart contract security experts. This document aims to explain what the contract appears to do based on the code. It should not be considered a comprehensive security audit or financial advice. Always verify critical information independently and consult with blockchain security professionals for important decisions.

⊙ generated by robots | curated by humans

Analysis Date: 2026-02-04

Metadata

Primary Contract

PROPERTY VALUE
Contract Address 0x41b242c36F7dc5f18be21c1a6B7b5e05b2FD6532 (etherscan)
Network Ethereum Mainnet
Contract Type Standalone ERC-20 Token
Deployment Date 2025-11-12 10:28:11 UTC
Deployment Block 23,784,335
Contract Creator 0x1fbaEd378Edf655726C3C2f5ebbD0363043838A6 (etherscan)
Creation TX 0x556a4525ffc51c7edeb73d264cd5c0b0cbc0d6d7bf8cbffac21097f8440a80af (etherscan)
Compiler Version Solidity 0.8.30 (Cancun EVM)
Total Functions 35+ public/external functions
External Contract Dependencies None (OpenZeppelin libraries only)
Upgrade Mechanism ☒ None - Not Upgradable
Verification Status ☑ Verified (Exact Match) on Etherscan
Audit Status ◇ No public audit report identified - Automated CertiK Token Scan available
TYPE ADDRESS NOTES
Owner/Admin 0x0000000000000000000000000000000000000000 (etherscan) Ownership renounced - contract is ownerless
Token Name ZeroMoon Symbol: zETH
Original Owner 0x1fbaEd378Edf655726C3C2f5ebbD0363043838A6 (etherscan) Deployer (renounced ownership post-deployment)

Executive Summary

The ZeroMoon (zETH) contract is an ETH-backed ERC-20 token deployed November 12, 2025, implementing a dividend distribution system where holders earn passive rewards from transaction fees. The contract features direct purchase and refund mechanisms, allowing users to buy tokens with ETH and sell them back to the contract at a calculated backing value (99.9% effective backing ratio).

The token implements a deflationary burn mechanism capped at 20% of total supply (250M tokens), after which burn fees redirect to reserve accumulation. Ownership has been renounced, making the contract immutable with no admin control over core mechanics. The contract excludes smart contracts from dividend distribution to prevent gaming by DEX pools and other protocols.

Key mechanisms:

  • Direct ETH purchase at dynamic pricing (base 0.0001 ETH per token, then refund price + 0.1%)
  • ETH refund at 99.9% backing value with minimum 1 token threshold
  • Dividend distribution from reflection fees (EOA holders only)
  • Deflationary burning up to 20% cap
  • Fee structure: 0.05-0.15% per transaction depending on type
  • ReentrancyGuard protection on all ETH transfers

Significant trust assumptions:

  • Contract is immutable (ownership renounced) - no ability to fix bugs or adjust parameters
  • Dev address receives fees but cannot be changed post-renouncement
  • Dividend system depends on correct contract detection to exclude protocols
  • Refund pricing assumes honest market participation (no MEV/manipulation protections)

Notable risks:

  • Immutability means no recovery mechanism for edge cases or discovered issues
  • Complex dividend calculation could have precision loss in extreme scenarios
  • Contract detection heuristics may misclassify some addresses
  • No circuit breakers or pause functionality

Architecture

graph TB
    User[User/EOA]
    Contract[ZeroMoon Contract<br/>1.25B Total Supply]
    DevAddr[Dev Address<br/>Fee Recipient]
    DEX[DEX Liquidity Pool]

    User -->|"buy() / receive()"| Contract
    Contract -->|"zETH Tokens"| User
    User -->|"transfer to contract"| Contract
    Contract -->|"ETH Refund"| User

    User <-->|"swap"| DEX
    DEX -->|"swap fees"| Contract

    Contract -->|"Dev Fees (5-10 BPS)"| DevAddr
    Contract -->|"Reflection Fees"| Contract
    Contract -.->|"Dividends"| User

    Contract -->|"Reserve Fees"| Contract
    Contract -->|"Burn (up to 20%)"| Burn[🔥 Burn Address]

    style Contract fill:#e1f5ff
    style DevAddr fill:#ffe1e1
    style Burn fill:#f5f5f5
    style User fill:#e1ffe1

System Overview

The ZeroMoon contract operates as a self-contained token system with internal liquidity. Users interact primarily through three pathways:

  • Direct Purchase: ETH sent to the contract (via buy() or receive()) mints tokens from internal supply at dynamic pricing
  • Direct Refund: Tokens sent to the contract trigger automatic ETH refunds at calculated backing value
  • Trading: Standard ERC-20 transfers and DEX swaps with configurable fee structures

The contract maintains its own ETH reserve, using incoming purchase ETH to back the circulating token supply. The backing ratio is 99.9% for refunds, creating a 0.1% spread that accumulates in reserves. This mechanism provides liquidity without requiring external AMM seeding.

  • ☑ The contract holds all unsold tokens and ETH reserves internally
  • ☑ Dividend system redistributes reflection fees proportionally to EOA holders
  • ☑ Burn mechanism is capped and irreversible (no reminting)
  • ☒ No external price oracle or liquidity requirements
  • ☒ No governance or parameter adjustment post-renouncement

Design Patterns Used

The contract employs several battle-tested OpenZeppelin patterns alongside custom mechanics:

  • ReentrancyGuard: All functions involving ETH transfers (buy, refund, claimDividends) are protected with nonReentrant modifier to prevent reentrancy attacks
  • Ownable2Step: Two-step ownership transfer pattern (unused post-renouncement but inherited)
  • ERC20Permit: EIP-2612 gasless approval via signatures (EIP-712 domain separator)
  • Magnified Dividends: Uses 2^128 magnitude for precise dividend-per-share calculations without rounding errors
  • Dynamic Pricing: Token price adjusts based on current backing ratio plus 0.1% markup
  • Automatic Contract Detection: Multi-signature interface checks to exclude contracts from dividends

Access Control

Roles & Permissions

ROLE ASSIGNED BY REVOKABLE CALL COUNT
Owner Constructor (renounced) Yes (renounced to 0x00) None (renounced)
Dev Address Constructor Yes (requires owner, now impossible) Unlimited (receives fees automatically)
Users N/A N/A Unlimited

Permission Matrix

FUNCTION OWNER DEV ADDRESS USER ANYONE
buy() ☑ ☑ ☑ ☑
refund (transfer to contract) ☑ ☑ ☑ ☑
claimDividends() ☑ ☑ ☑ ☑
transfer() ☑ ☑ ☑ ☑
setDevAddress() ☒ (renounced) ☒ ☒ ☒
excludeFromFee() ☒ (renounced) ☒ ☒ ☒
transferOwnership() ☒ (renounced) ☒ ☒ ☒
renounceOwnership() ☒ (already done) ☒ ☒ ☒

Time Locks & Delays

ACTION TIME LOCK CAN CANCEL PURPOSE
Ownership Transfer Yes - Ownable2Step (requires acceptOwnership) Yes ◇ Prevents accidental ownership transfer (N/A post-renouncement)
Parameter Changes None N/A ☒ Immutable - no parameter adjustment possible
Dev Address Change None (requires owner) N/A ☒ Instant if owner existed (now impossible)

Economic Model

Purchase Flow

flowchart TD
    Start[User Sends ETH] --> Check1{">= 0.0001 ETH?"}
    Check1 -->|No| Revert1[Revert: InsufficientNative]
    Check1 -->|Yes| CalcPrice[Calculate Token Price<br/>base: 0.0001 ETH<br/>or refund price + 0.1%]

    CalcPrice --> CalcTokens[Calculate Tokens<br/>= ETH ÷ Price]
    CalcTokens --> Check2{Enough Supply?}
    Check2 -->|No| Revert2[Revert: InsufficientBalance]

    Check2 -->|Yes| CalcFees[Calculate Fees<br/>Dev: 0.05%<br/>Reserve: 0.10%<br/>Reflection: 0.10%]

    CalcFees --> Distribute[Distribute Dividends<br/>Update magnifiedDividendPerShare]
    Distribute --> MarkUser[Mark Buyer as Current<br/>Prevent Self-Dividend]
    MarkUser --> SendDev[Send Dev Fee to DevAddr]
    SendDev --> SendUser[Send Net Tokens to User]
    SendUser --> EmitBuy[Emit Buy Event]
    EmitBuy --> End[Complete]

    style Start fill:#e1ffe1
    style End fill:#e1ffe1
    style Revert1 fill:#ffe1e1
    style Revert2 fill:#ffe1e1
    style Distribute fill:#fff4e1

Refund Flow

flowchart TD
    Start[User Transfers Tokens to Contract] --> Check1{">= 1 Token?"}
    Check1 -->|No| Revert1[Revert: InsufficientBalance]
    Check1 -->|Yes| CalcFees[Calculate Fees<br/>Dev: 0.05%<br/>Reflection: 0.05%<br/>Burn: 0.075% or 0<br/>Reserve: 0.075% or 0.15%]

    CalcFees --> NetTokens[Net Tokens After Fees]
    NetTokens --> CalcBacking[Calculate Backing<br/>effectiveBacking = ETH × 99.9%]
    CalcBacking --> CalcETH[ETH = NetTokens × effectiveBacking ÷ circulatingSupply]

    CalcETH --> Check2{Enough ETH?}
    Check2 -->|No| Revert2[Revert: InsufficientNative]
    Check2 -->|Yes| SendDev[Send Dev Fee to DevAddr]

    SendDev --> CheckBurn{totalBurned < 20%?}
    CheckBurn -->|Yes| BurnTokens[Burn Tokens<br/>Up to Remaining Cap]
    CheckBurn -->|No| SkipBurn[Skip Burn<br/>Double Reserve Fee]

    BurnTokens --> DistDiv[Distribute Reflection Dividends]
    SkipBurn --> DistDiv
    DistDiv --> SendETH[Send ETH to User]
    SendETH --> Check3{Transfer Success?}
    Check3 -->|No| Revert3[Revert: NativeTransferFailed]
    Check3 -->|Yes| EmitRefund[Emit Refund Event]
    EmitRefund --> End[Complete]

    style Start fill:#e1ffe1
    style End fill:#e1ffe1
    style Revert1 fill:#ffe1e1
    style Revert2 fill:#ffe1e1
    style Revert3 fill:#ffe1e1
    style BurnTokens fill:#f5f5f5
    style DistDiv fill:#fff4e1

Fee Structure

TRANSACTION TYPE DEV FEE REFLECTION FEE RESERVE FEE BURN FEE TOTAL
Buy 0.05% 0.10% 0.10% — 0.25%
Refund (pre-cap) 0.05% 0.05% 0.075% 0.075% 0.25%
Refund (post-cap) 0.05% 0.05% 0.15% — 0.25%
Transfer 0.05% 0.10% 0.10% — 0.25%
DEX Swap 0% 0% 0% — 0%
Fee-Exempt 0% 0% 0% — 0%

Fee Recipients:

  • Dev Fee: Sent to devAddress (currently immutable post-renouncement)
  • Reflection Fee: Distributed as dividends to all EOA holders proportionally
  • Reserve Fee: Remains in contract to strengthen backing ratio
  • Burn Fee: Tokens permanently destroyed until 20% cap reached (250M tokens)

Funding Sources & Sinks

Inflows (How ETH Enters):

  • Direct token purchases via buy() or receive() functions
  • Initial deployment can include ETH (constructor is payable)

Outflows (How ETH Leaves):

  • Refunds when users send tokens back to contract
  • Dev fees sent to devAddress on every taxed transaction
  • Dividend claims when users call claimDividends()

Economic Invariants

The contract maintains several economic relationships:

  1. Backing Ratio: Total ETH in contract should approximate (circulatingSupply × averagePrice × 0.999) over time
  2. Burn Cap: totalBurned <= BURNING_LIMIT (250M tokens maximum)
  3. Supply Relationship: totalSupply() = TOTAL_SUPPLY - totalBurned
  4. Circulating Supply: circulatingSupply = totalSupply() - balanceOf(contract)
  5. Dividend Conservation: Sum of all unclaimed dividends + distributed dividends = totalDividendsDistributed

Summary of Observations

The ZeroMoon (zETH) contract implements an ETH-backed token with passive dividend distribution for holders. The core mechanism allows users to purchase tokens directly from the contract at dynamic pricing and refund them at 99.9% of backing value, creating a self-sustaining liquidity system without requiring external AMM pools.

Key Strengths:

  • ☑ Ownership renounced ensures immutability and prevents rug pulls
  • ☑ ReentrancyGuard protects all ETH transfer functions
  • ☑ Verified source code using OpenZeppelin battle-tested contracts
  • ☑ Automatic contract exclusion prevents dividend gaming by protocols
  • ☑ Deflationary burn capped at 20% prevents excessive supply reduction
  • ☑ Minimum thresholds (0.0001 ETH buy, 1 token refund) prevent dust attacks
  • ☑ Precise dividend calculations using 2^128 magnitude
  • ☑ No external dependencies or oracle manipulation vectors

Significant Mechanisms:

The dividend system uses a magnified shares approach where each holder earns proportionally to their balance. When reflection fees are collected, they increase magnifiedDividendPerShare, and users claim accumulated dividends at their convenience. Contracts are automatically excluded to prevent DEX pools from earning dividends on their liquidity.

The refund mechanism calculates ETH return based on current circulating supply and contract balance, applying a 99.9% effective backing ratio. This 0.1% gap between purchase and refund price accumulates in reserves, strengthening backing over time.

Economic Observations:

As of the analysis date (84 days post-deployment), approximately 3.46M tokens have been sold from the 1.25B total supply (0.28% circulation), with 530K tokens burned (0.042% of supply). The contract holds 0.277 ETH backing the circulating tokens. The low circulation suggests either early-stage adoption or significant refund activity.

Concerns & Limitations:

  • △ Immutability means no bug fixes or parameter adjustments possible
  • △ Contract detection heuristics may misclassify some addresses
  • △ Complex dividend math could have edge cases in extreme scenarios
  • △ No pause or emergency mechanisms for discovered issues
  • △ Refund pricing vulnerable to MEV extraction in theory
  • △ Dev address is immutable post-renouncement (cannot update if compromised)

The contract appears designed for long-term operation with no admin intervention. Source code comments reference testing claims ("160M+ fuzz cases, 200M+ invariant calls") which we did not independently verify. An automated CertiK Token Scan is available, but no public manual audit report was identified during this analysis. The economic model depends on balanced buy/refund activity to maintain backing ratio.

This analysis was performed for educational purposes and should not be considered an official security audit or financial advice. The immutable nature of this contract means identified issues cannot be corrected. Potential users should independently verify all claims and understand the risks of interacting with immutable smart contracts.

References

RESOURCE NOTES
Etherscan Contract Page Verified source code, transaction history, and on-chain data
OpenZeppelin Contracts v4.9.3 Reference documentation for inherited contracts (ERC20, ReentrancyGuard, Ownable2Step)
EIP-2612 (Permit) Gasless approval specification implemented via ERC20Permit
EIP-712 (Typed Data) Structured data hashing for permit signatures

Change Log

DATE AUTHOR NOTES
2026-02-04 Artificial. Generated by robots. Gas: 75 tok
2026-02-05 Denizen. Reviewed, edited, and curated by humans.
2026-02-06 Artificial. Revised audit/security language in potential-risks.md and contract-analysis.md. Replaced presumptive "no audit" claims with verifiable observations. Added publicly available security resources (GitHub test suite, Certora specs, CertiK Token Scan). Gas: 12 tok