Skip to content

Potential Risks

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

METADATA
Contract Address 0x41b242c36F7dc5f18be21c1a6B7b5e05b2FD6532 (etherscan)
Network Ethereum Mainnet
Analysis Date 2026-02-04

Risk Assessment Summary

SEVERITY COUNT DESCRIPTION
Critical 0 No immediate critical risks identified
High 3 Immutability constraints, contract detection limitations, precision edge cases
Medium 5 Economic manipulation vectors, fee recipient constraints, refund pricing
Low 4 Self-conducted security testing, gas optimization trade-offs, user experience issues
Informational 3 Design choices and architectural considerations

High Severity Risks

H-1: Permanent Immutability - No Emergency Controls

Risk: Ownership has been renounced to 0x0000000000000000000000000000000000000000, making the contract completely immutable with no pause, upgrade, or parameter adjustment capabilities.

Impact:

  • ☒ No ability to fix discovered bugs or vulnerabilities
  • ☒ No mechanism to adjust fees, limits, or economic parameters
  • ☒ No circuit breaker for unexpected market conditions
  • ☒ No way to update devAddress if private key compromised

Code Reference:

// Owner renounced - all onlyOwner functions permanently disabled
function owner() public view returns (address) {
    return _owner; // Returns 0x00
}

function setDevAddress(address _devAddress) external onlyOwner {
    // Can never be called again
}

function excludeFromFee(address account, bool isExcluded) external onlyOwner {
    // Can never be called again
}

Mitigation:

  • △ Users must accept contract as-is with no future changes possible
  • △ Project publishes test suite and Certora specs on GitHub — testing claims are reproducible but we did not independently run them
  • △ No independent manual security audit by human reviewers was identified; automated third-party scans (CertiK) and self-conducted formal verification (Certora, Foundry) are available

Assessment: This is a design choice for trustlessness, but means any undiscovered edge cases are permanent.

H-2: Contract Detection Heuristics May Misclassify Addresses

Risk: The isContract() function uses interface detection heuristics to identify contracts and exclude them from dividends. This approach may misclassify some addresses.

Impact:

  • △ Smart contract wallets (Safe, Argent) may be excluded from dividends unexpectedly
  • △ Future protocols with novel interfaces may not be detected and could game dividends
  • △ EOAs with delegatecall proxies may behave unexpectedly
  • △ Some legitimate contracts might receive dividends they shouldn't

Code Reference:

function isContract(address _addr) internal view returns (bool) {
    if (_addr.code.length == 0) return false;

    // Checks for: token0/token1, factory, getReserves, getPair, swap, supply, deposit, sendToChain
    // But many other contract types exist (multisigs, DAOs, staking, etc.)
    (bool s0, bytes memory d0) = _addr.staticcall(abi.encodeWithSignature("token0()"));
    (bool s1, bytes memory d1) = _addr.staticcall(abi.encodeWithSignature("token1()"));
    if (s0 && s1 && d0.length == 32 && d1.length == 32) {
        return true;
    }
    // ... 7 more checks ...
    return false;
}

Scenarios:

  • Safe multisig holding zETH: May NOT be detected as contract → receives dividends (possibly unintended)
  • Custom yield aggregator: May NOT match any interface check → receives dividends (potential gaming vector)
  • Gnosis Safe with no checked interfaces: Treated as EOA → earns dividends

Mitigation:

  • ◇ Users should test dividend eligibility before large purchases
  • ◇ Smart contract wallets should verify their status via pendingDividends()
  • ◇ Community should document which wallet types work as expected

Assessment: False negatives (contracts treated as EOAs) are more likely than false positives, potentially allowing dividend gaming.

H-3: Precision Loss in Extreme Scenarios

Risk: While the contract uses Math.mulDiv for critical calculations and 2^128 magnitude for dividends, extreme scenarios could still exhibit precision loss or unexpected behavior.

Impact:

  • △ Very small dividend amounts (< 1 wei) are lost to rounding
  • △ Extremely large balances (approaching total supply) may overflow in dividend calculations
  • △ Rapid buy/refund cycles could accumulate rounding errors
  • △ Circulating supply near zero creates division by zero risk (checked but economic edge case)

Code Reference:

function _distributeDividends(uint256 amount) private {
    if (amount == 0) return;

    uint256 circulatingSupply = getCirculatingSupply();
    if (circulatingSupply == 0) return;  // Protected, but economic failure

    uint256 dividendPerShare = (amount * MAGNITUDE) / circulatingSupply;
    // If amount < circulatingSupply, dividendPerShare could be very small

    magnifiedDividendPerShare += dividendPerShare;
}

Scenarios:

  • User holds 1 wei of tokens: Dividend share = (1 * dividendDelta) / MAGNITUDE → likely rounds to 0
  • Circulating supply = 1 token, reflection fee = 0.1 tokens: Works, but extreme ratio
  • Many small trades: Each loses sub-wei amounts to rounding

Mitigation:

  • ◇ Minimum 1 token refund threshold (line 2571) partially addresses this
  • ◇ MAGNITUDE of 2^128 provides significant precision buffer
  • ◇ View function pendingDividends() allows users to check before claiming

Assessment: Unlikely in normal operation, but untested in extreme market stress or manipulation attempts.

Medium Severity Risks

M-1: Refund Price Manipulation via Flash Loans

Risk: The refund price calculation uses current contract state (address(this).balance and circulating supply), which could potentially be manipulated within a single transaction using flash loans.

Impact:

  • △ Large ETH flash loan → buy tokens → increases backing ratio → refund at higher price
  • △ Requires circumventing ReentrancyGuard (not possible in standard flow)
  • △ MEV bots could sandwich large refunds to extract value
  • △ 99.9% backing ratio and fees make exploitation economically marginal

Code Reference:

function _handleRefund(address sender, uint256 zETHAmount) private nonReentrant {
    // Uses current balance at time of refund
    uint256 effectiveBacking = (address(this).balance * EFFECTIVE_BACKING_NUMERATOR) / EFFECTIVE_BACKING_DENOMINATOR;

    uint256 grossNativeValue = Math.mulDiv(zETHForUserRefund, effectiveBacking, currentCirculatingSupply);
    // If someone inflates balance right before this, refund price increases
}

Mitigation:

  • ☑ ReentrancyGuard prevents same-transaction re-entry
  • ☑ 0.1% buy markup + 0.25% fees make round-trips costly
  • ◇ No TWAP or oracle, but attack window limited to block boundaries

Assessment: Economically unfeasible under current fee structure, but theoretically possible with MEV extraction.

M-2: Dev Address Compromise - No Recovery Mechanism

Risk: The devAddress receives fees from all transactions but cannot be changed post-renouncement. If the private key is compromised, fees are permanently redirected to attacker.

Impact:

  • ☒ All future dev fees (0.05% of transactions) sent to compromised address
  • ☒ No ability to update or freeze the address
  • ☒ Continued protocol operation but fee loss for intended recipient

Code Reference:

function setDevAddress(address _devAddress) external onlyOwner {
    // onlyOwner = renounced = can never be called
    if (_devAddress == address(0)) revert ZeroMoonAddress();
    address oldDevAddress = devAddress;
    _isExcludedFromFee[devAddress] = false;
    devAddress = _devAddress;
    _isExcludedFromFee[devAddress] = true;
}

Mitigation:

  • ◇ Dev address should use cold storage or multisig
  • ◇ Fees represent small percentage (0.05%), limiting damage
  • ◇ Protocol continues to function normally for users

Assessment: Operational risk for protocol maintainers, minor impact on users.

M-3: Burn Cap Creates Economic Phase Shift

Risk: Once the 20% burn limit (250M tokens) is reached, burn fees redirect to reserves, doubling the reserve fee. This creates a sudden economic phase shift.

Impact:

  • △ Refund economics change abruptly at 250M burned threshold
  • △ Users near the cap boundary see different fee structures
  • △ Reserve accumulation accelerates, backing ratio increases
  • △ No liquidity or market depth concerns, but refund profitability changes

Code Reference:

uint256 burnFeezETH = (_totalBurned < BURNING_LIMIT) ? Math.mulDiv(zETHAmount, 75, 100000) : 0;
uint256 reserveFeezETH = (_totalBurned < BURNING_LIMIT) ? Math.mulDiv(zETHAmount, 75, 100000) : Math.mulDiv(zETHAmount, 150, 100000);
// Pre-cap:  burn=0.075%, reserve=0.075%
// Post-cap: burn=0%,     reserve=0.15%

Scenarios:

  • User A refunds at 249.9M burned: Pays 0.075% burn + 0.075% reserve
  • User B refunds at 250.1M burned: Pays 0% burn + 0.15% reserve
  • Same total fee (0.25%), but different allocation

Mitigation:

  • ☑ Total fee remains constant (0.25%)
  • ◇ Users can check totalBurned before refunding
  • ◇ Strengthens backing ratio post-cap (more ETH retained)

Assessment: Economically neutral for users, but creates sudden shift in backing accumulation rate.

M-4: Dividend Exclusion May Not Catch All Contracts

Risk: Contracts not matching the 8 interface checks in isContract() are treated as EOAs and receive dividends. This could allow sophisticated protocols to game the dividend system.

Impact:

  • △ Custom contracts designed to bypass detection could earn dividends
  • △ Minimal balance contracts acting as "dividend proxies"
  • △ Unknown future protocols with novel architectures
  • △ Economic impact depends on gaming scale vs. legitimate holders

Code Reference:

function isContract(address _addr) internal view returns (bool) {
    // Only checks 8 specific interfaces
    // Returns false for any contract not matching these patterns
    return false;  // Default if none match
}

Mitigation:

  • ◇ Economic attack requires: contract that passes checks, holds balance, doesn't match interfaces
  • ◇ Gas costs of maintaining bypass contracts may exceed dividend yield
  • ◇ Immutability means no fix possible if gaming discovered

Assessment: Low immediate risk, but surveillance recommended for unusual holder patterns.

M-5: No Minimum Liquidity Requirements

Risk: The contract has no minimum liquidity enforcement. If most tokens are refunded, backing ratio could become unstable with low liquidity depth.

Impact:

  • △ Low liquidity makes refund prices volatile
  • △ Last redeemer timing risk (race to exit)
  • △ Dividend yield becomes extreme with few holders
  • △ No enforcement of minimum circulation

Code Reference:

function getCirculatingSupply() private view returns (uint256) {
    uint256 total = totalSupply();
    uint256 contractBalance = balanceOf(address(this));
    return total - contractBalance;
    // No check if this is too low
}

Scenarios:

  • 99% of tokens refunded: Remaining 1% has 99% of backing
  • Extreme dividend concentration in few holders
  • Refund pricing becomes extremely sensitive to single transactions

Mitigation:

  • ◇ Economic incentives discourage complete drain (refund price increases as supply drops)
  • ◇ 99.9% backing means last redeemers still get value
  • ◇ No artificial minimum circulation requirement

Assessment: Self-correcting through economic incentives, but could see liquidity crises.

Low Severity Risks

L-1: Security Testing is Self-Conducted

Risk: The project has published extensive testing infrastructure and formal verification specs, but all security work appears to be self-conducted rather than commissioned from an independent third party.

Impact:

  • △ Self-run Certora formal verification reported 14 properties verified and 9 violations — all 9 classified as false positives by the team
  • △ Certora Prover job results (prover.certora.com) are behind authentication and cannot be independently reviewed without access
  • △ Foundry test suite (fuzz, invariant, differential) is publicly available but we did not independently execute the tests
  • △ No third-party commissioned audit report was identified during this analysis

Publicly Available Security Resources:

  • ◇ GitHub repository with full source code, Foundry test suite, and Certora spec files
  • ◇ CertiK Token Scan (automated) — checks for common vulnerability patterns
  • ◇ Self-published Certora report and stress test results
  • ◇ Certora spec files (zeth.spec, zeth-comprehensive.spec) available for review in certora/zeth/
  • ◇ Foundry tests: ZeroMoonFuzz.t.sol, ZeroMoonInvariant.t.sol, ZeroMoonDifferential.t.sol

Mitigation:

  • ◇ Verified source code on Etherscan (Exact Match) allows community review
  • ◇ OpenZeppelin libraries (v4.9.3) are independently audited
  • ◇ Test infrastructure and Certora specs are publicly reproducible
  • ◇ Certora Prover is the same tool used by Uniswap V3, Compound V3, and Aave V3

Assessment: The project has invested in real testing infrastructure using industry-standard tools (Foundry, Certora Prover). The distinction is that this work was self-conducted and self-interpreted rather than commissioned from an independent auditor. Users can review and reproduce the tests themselves, but should understand the difference between self-run verification and an independent third-party audit.

L-2: Gas Costs Vary Significantly by Scenario

Risk: Transaction gas costs vary widely (120k-250k) depending on dividend state, making cost estimation difficult for users.

Impact:

  • △ Users may set insufficient gas limits
  • △ Failed transactions waste gas
  • △ Cost unpredictability especially for first-time users
  • △ Dividend claims can fail if balance insufficient

Scenarios:

  • First buy of the day (distributes dividends): 200k gas
  • Buy when no dividends: 150k gas
  • Refund with burn: 250k gas
  • Transfer between exempt addresses: 120k gas

Mitigation:

  • ◇ Etherscan provides gas estimation before transactions
  • ◇ Wallets auto-adjust gas limits based on simulation
  • ◇ No gas griefing vectors (max bounded by operations)

Assessment: User experience issue, not security risk.

L-3: DEX Swap Fee Exemption May Cause Confusion

Risk: DEX swaps pay 0% fees while direct transfers pay 0.25%. This asymmetry could confuse users or create unexpected arbitrage.

Impact:

  • ◇ Users transferring directly pay fees, but swapping via DEX is free
  • ◇ Incentivizes all transfers to route through DEX (gas inefficient)
  • ◇ Dividend distribution primarily from non-DEX transfers
  • ◇ May lead to questions about "fair" fee application

Code Reference:

bool isDexSwap = (isContract(from) && isLiquidityPair(from)) || (isContract(to) && isLiquidityPair(to));

if (isDexSwap) {
    devFeeBps = DEX_SWAP_DEV_FEE_BPS;  // 0
    reflectionFeeBps = DEX_SWAP_REFLECTION_FEE_BPS;  // 0
    reserveFeeBps = DEX_SWAP_RESERVE_FEE_BPS;  // 0
}

Mitigation:

  • ◇ Design choice to avoid penalizing DEX trading
  • ◇ Documented behavior in code comments
  • ◇ Creates trading efficiency vs. transfer inefficiency trade-off

Assessment: Intentional design, but may require user education.

L-4: Minimum Thresholds May Exclude Small Users

Risk: Minimum purchase of 0.0001 ETH (~$0.40 at $4k ETH) and minimum refund of 1 token may exclude very small participants.

Impact:

  • △ Dust balances cannot be refunded (< 1 token)
  • △ Very small holders locked in unless accumulate to 1+ tokens
  • △ Sub-minimum purchases blocked entirely
  • △ No sweep or dust consolidation mechanism

Code Reference:

if (amountNative < MINIMUM_PURCHASE_NATIVE) revert InsufficientNative();  // 0.0001 ETH
if (zETHAmount < 1 ether) revert InsufficientBalance();  // 1 token minimum refund

Mitigation:

  • ◇ Thresholds prevent dust attacks and spam
  • ◇ Amounts are economically reasonable (~$0.40 minimum)
  • ◇ Users can transfer tokens instead of refunding
  • ◇ Small holders can accumulate to threshold

Assessment: Anti-spam measure with minor accessibility impact.

Informational Risks

I-1: No Emergency Withdrawal for Mistaken Sends

Risk: If users accidentally send ETH or other tokens directly to the contract (not via buy()), there is no recovery mechanism.

Impact:

  • △ Sent ERC-20 tokens are unrecoverable
  • △ ETH sent via non-buy paths may be unrecoverable
  • △ No sweep function for admin (owner renounced)
  • △ Funds increase backing ratio but are effectively donated

Mitigation:

  • ◇ receive() function catches direct ETH sends and executes buy()
  • ◇ Standard ERC-20 transfers to contract address are rejected by ERC-20 standard
  • ◇ Only non-standard token sends at risk

Assessment: Edge case with limited real-world risk (receive handles ETH).

I-2: ERC20Permit Nonce Not Monotonically Increasing

Risk: The ERC20Permit implementation uses Counters.Counter library which has been deprecated in newer OpenZeppelin versions in favor of monotonic nonces.

Impact:

  • ◇ Current implementation (OZ 4.9.3) is secure
  • ◇ No known exploits of Counter-based nonces
  • ◇ Newer OZ versions use different approach
  • ◇ Immutability prevents upgrade to new pattern

Mitigation:

  • ☑ OZ 4.9.3 Counters library is audited and battle-tested
  • ☑ No practical security difference for this use case
  • ◇ Informational note only, not actionable

Assessment: Non-issue, current implementation is secure.

I-3: No Price Feed or Oracle Integration

Risk: Contract has no concept of "USD value" or external price feeds. All economics are ETH-denominated.

Impact:

  • ◇ Token price floats with ETH price
  • ◇ No stablecoin peg or floor price
  • ◇ No oracle manipulation vectors (positive)
  • ◇ Dollar-cost-averaging users face ETH price volatility

Mitigation:

  • ☑ Removes oracle attack surface entirely
  • ☑ Simpler architecture with fewer dependencies
  • ◇ Users must mentally adjust for ETH price changes

Assessment: Design choice with security benefits (no oracle manipulation).

Recommendations for Users

Based on the identified risks, users should consider the following before interacting with the contract:

  1. Verify Immutability: Confirm owner is 0x00 - contract cannot be changed
  2. Test Dividend Eligibility: If using smart contract wallet, check pendingDividends() before large purchases
  3. Monitor Burn Cap: Check totalBurned to understand which fee phase is active
  4. Understand Refund Pricing: Use calculateNativeForZETH() to preview refund amounts
  5. Gas Buffer: Set 20-30% higher gas limits than estimated due to variability
  6. Accept Permanence: Any bugs or issues cannot be fixed - contract is truly immutable
  7. Review Security Resources: Test suite, Certora specs, and CertiK scan are publicly available — no independent third-party audit was identified

Recommendations for Developers (Post-Renouncement)

Since ownership is renounced, these recommendations are informational only:

  1. Consider emergency pause mechanism - Not possible
  2. Implement timelock for parameter changes - Not possible
  3. Add circuit breaker for extreme scenarios - Not possible
  4. Enable dev address rotation - Not possible
  5. Independent security audit - Self-conducted (Certora, Foundry) and automated third-party scan (CertiK)

The immutability is complete and intentional.

Conclusion

The ZeroMoon zETH token contract appears to be a well-structured implementation using established OpenZeppelin patterns with custom dividend and refund mechanics. The primary risks stem from its intentional immutability (renounced ownership) and the complexity of its economic model.

Risk Profile: Medium to High due to immutability constraints, but no obvious critical exploits identified in the code analysis.

Target Users: Sophisticated cryptocurrency users comfortable with:

  • Immutable, ungoverned contracts
  • ETH-backed token economics
  • Dividend distribution mechanics
  • No recourse for bugs or issues

Not Recommended For:

  • Users expecting admin support or parameter adjustments
  • Projects requiring publicly verifiable audit reports
  • Users unfamiliar with dividend-bearing tokens
  • Conservative DeFi participants requiring governance

This analysis should not be considered a substitute for a professional security audit. Users should conduct their own research and risk assessment before interacting with the contract.