ZeroMoon Boring Paper

---

---

Introduction

ZeroMoon (0Moon) is an advanced reflection (auto-staking) token deployed on the Binance Smart Chain (BSC). It builds upon foundational concepts from earlier reflection tokens but is re-engineered with a primary focus on enhanced safety, programmatic autonomy, and robust scalability. ZeroMoon introduces automated liquidity management, a dynamic fee system that adapts to ecosystem milestones, and a secure, decentralized framework designed to minimize centralized vulnerabilities.

The ZeroMoon contract is optimized for scalability, primarily utilizing constant-time O(1) operations for critical functions like reflections and fee distribution. This design ensures that gas costs remain low and predictable, allowing the system to efficiently support a very large number of users and transactions.

Key Features

• Dynamic Fee Structure: Transaction fees automatically adjust based on the achievement of burn and liquidity provision milestones, ensuring a balanced approach to rewards, deflation, and long-term sustainability.
• Automated Liquidity Addition: The contract programmatically collects a portion of fees to add liquidity to a PancakeSwap V2 pair when defined thresholds are met, fostering a stable and healthy trading ecosystem. LP tokens generated are sent to a dead address, locking the liquidity.
• Burn and Liquidity Caps:
  • Burn Limit: Token burning from fees ceases once 50% of the original total supply has been burned.
  • Liquidity Deposit Limit: Automated liquidity addition from fees stops once the original total supply has been designated for or added to the liquidity pool.
• Scalability: Designed with O(1) time complexity for core operations like reflection distribution, enabling efficient performance even with a large and active user base.
• Programmatically Managed Assets: The contract holds 0Moon tokens (for liquidity/reflection) and BNB (for gas). These assets are managed by the smart contract's predefined logic for their intended purposes and are not arbitrarily drainable by the owner or external parties through direct withdrawal functions.
• Configurable FairLaunch Address: Owner can set a fairLaunchAddress (e.g., for Initial Farm Offerings - IFOs), which is automatically excluded from transaction fees and reflection rewards.
• Fair Distribution of Residual Tokens: After liquidity goals are met, any non-earmarked 0Moon tokens remaining in the contract are distributed to holders via reflection, ensuring no tokens are "stuck" or misused.

Tokenomics

ZeroMoon’s tokenomics are meticulously designed to balance holder rewards, token scarcity through burning, and the overall sustainability of the ecosystem.

• Token Name: ZeroMoon
• Token Symbol: 0Moon
• Total Supply (ORIGINAL_SUPPLY): 100,000,000,000 0Moon (100 Billion 0Moon)
  • Defined in contract as ORIGINAL_SUPPLY = 100_000_000_000 * 10**18.
• Burn Mechanism (BURN_LIMIT): Deflationary burning of tokens from transaction fees continues until 50,000,000,000 0Moon (50% of ORIGINAL_SUPPLY) are removed from circulation.
  • Defined in contract as BURN_LIMIT = ORIGINAL_SUPPLY * 50 / 100.

Transaction Fees (Dynamic Phases)

Fees are percentages of the transaction amount, with a denominator of 10,000 in the contract.

Phase	Total Fee	Reflection	Liquidity	Burn	Developer
Phase 1 (Before Burn Limit)	10%	3.5%REFLECTION_B4_BST = 350	3.0%LIQUIDITY_B4_BST = 300	2.5%BURN_B4_BST = 250	1.0%DEV_B4_BST = 100
Phase 2 (After Burn Limit, Before LP Limit)	10%	4.5%REFLECTION_B4_LPS = 450	4.75%LIQUIDITY_B4_LPS = 475	0%(Burn fee stops)	0.75%DEV_B4_LPS = 75
Phase 3 (After Both Limits Reached)	6%	5.5%REFLECTION_AFTER = 550	0%(Liquidity fee stops)	0%(Burn fee remains stopped)	0.5%DEV_AFTER = 50

• LP Deposit Limit (LP_DEPOSIT_LIMIT): Automated liquidity addition from fees ceases after 100,000,000,000 0Moon (the ORIGINAL_SUPPLY) have been cumulatively designated for (_totalGrossLpCollected reaching LP_DEPOSIT_LIMIT * 2) or added to (_totalLpDeposited reaching LP_DEPOSIT_LIMIT) the PancakeSwap liquidity pool.
  • Defined in contract as LP_DEPOSIT_LIMIT = ORIGINAL_SUPPLY.
• Reflection (Auto-Staking) Eligibility & Exclusions:
  • All holders are eligible for reflections provided they are not explicitly excluded.
  • Excluded by default: The contract itself, the deadWallet, the pancakeSwapV2Pair.
  • A configurable fairLaunchAddress, if set by the owner, is also automatically excluded from both fees and reflections.
  • General smart contracts (identified using isContract()) receiving tokens are typically auto-excluded from reflections to concentrate rewards among user EOAs.
  • There are no minimum token holding requirements to receive reflections.

Safety Mechanisms

The ZeroMoon contract incorporates several design choices to enhance security and mitigate risks:

• Ownership Renouncement (Planned): Post-launch, contract ownership is intended to be renounced. This action would make owner-restricted functions (onlyOwner) permanently inaccessible, moving the contract towards greater decentralization and immutability for those functions.
• Immutable Addresses: Critical infrastructure addresses such as the pancakeSwapV2Pair, deadWallet, primary devWallet, and boxAddress are set at deployment and are immutable, preventing malicious changes.
• Reentrancy Protection: Utilizes OpenZeppelin's ReentrancyGuard modifier (nonReentrant) on key functions involved in external calls or state changes related to liquidity operations (executeLpFromPoke, triggerAutoLiquidity), protecting against reentrancy attacks. Note: _addLiquidityAutomatically is private and not directly nonReentrant but is called by nonReentrant functions.
• Locked Liquidity: LP tokens generated from automated liquidity additions are sent directly to the deadWallet. This effectively burns the LP tokens, permanently locking the underlying 0Moon and BNB in the PancakeSwap liquidity pool and preventing a "rug pull" of this contract-generated liquidity.
• No Arbitrary Withdrawals: The contract does not contain functions allowing the owner or any other address to arbitrarily withdraw 0Moon tokens or BNB held within it. Asset movements are governed by the predefined programmatic logic of the tokenomics (fee distribution, liquidity addition, specific transfers to boxAddress, and distribution of residual tokens to holders via reflection).
• User-Triggerable Liquidity Addition (Decentralized Backup):
  • The triggerAutoLiquidity() function is public and can be called by any user or external actor.
  • If the ZeroMoon contract has accumulated sufficient tokens (MIN_TOKENS_TO_PROCESS_PER_CYCLE) and BNB (MIN_BNB_BALANCE) for an LP event, and the LP_DEPOSIT_LIMIT has not been reached, any call to triggerAutoLiquidity() will initiate the contract's automated liquidity addition process.
  • This permissionless trigger serves as a crucial decentralized backup, ensuring that the liquidity mechanism can always be activated by the community if the primary EchoPinger bot is offline or if there's any delay. It guarantees that accumulated liquidity reserves will be processed and not left indefinitely unused within the contract. This feature underscores the contract's autonomy and resilience, further securing against tokens becoming "stuck."

Contract Overview

• Contract address: 0x928a3a7dcce6d6e168734490577ee772024add15
• Contract Name: ZeroMoon
• SPDX License: MIT
• Solidity Version: 0.8.30
• Inheritance: ZeroMoon inherits from:
  • ERC20 (OpenZeppelin): Provides standard ERC20 token functionality.
  • Ownable (OpenZeppelin): Implements ownership control for administrative functions.
  • ReentrancyGuard (OpenZeppelin): Provides protection against reentrancy attacks.

List of all Functions

(This list summarizes key functions and public state variables accessible like view functions. For full details, refer to the contract code and NatSpec comments.)

1. Constructor

• Function: constructor
• Visibility: Deployment-time only.
• Modifiers: payable
• Parameters: _devWallet, _pancakeSwapRouterAddress, _pancakeSwapFactoryAddress, _deadWalletAddress, _boxAddress.
• Purpose: Initializes the contract, sets up immutable addresses, creates the PancakeSwap pair, mints ORIGINAL_SUPPLY to the deployer, and sets initial exclusions.

2. Public View Functions & State Variables (Data Retrieval)

• name(), symbol(), decimals(), allowance(address, address): Standard ERC20 view functions.
• totalSupply(): Returns ORIGINAL_SUPPLY - _burnedTokens.
• balanceOf(address account): Returns token balance, accounting for reflections.
• isContract(address _addr): Checks if an address has deployed code.
• get0MoonPerBNB(): Returns the current 0Moon price per 1 BNB from PancakeSwap.
• getBNBPer0Moon(): Returns the current BNB price per 1 0Moon from PancakeSwap.
• owner(): Returns the current contract owner (from Ownable).
• echoPingerAddress: Public state variable. Stores the configured EchoPinger address.
• fairLaunchAddress: Public state variable. Stores the configured FairLaunch address.
• holdersCount: Public state variable. Returns the current number of token holders.
• _accumulatedLiquidityTokens: Public state variable. Shows tokens currently held by the contract for LP addition.
• _totalLpDeposited: Public state variable. Shows total net 0Moon tokens deposited into the LP by the contract.
• _totalGrossLpCollected: Public state variable. Shows the total gross 0Moon tokens ever collected from fees for LP purposes.
• _totalReflectionTokensCollected: Public state variable. Shows the total gross 0Moon tokens ever collected from fees for reflection.
• _burnedTokens: Public state variable. Shows total tokens burned via fees.
• _burnStop, _lpStop: Public boolean state variables indicating status of burn/LP mechanisms.
• pancakeSwapV2Pair: Public immutable state variable. Address of the PancakeSwap LP pair.
• pancakeSwapV2Router: Public immutable state variable. Address of the PancakeSwap Router.
• deadWallet: Public immutable state variable. Address of the burn/dead wallet.

3. Public State-Changing Functions (Transactions)

• transfer(address, uint256), transferFrom(address, address, uint256), approve(address, uint256), increaseAllowance(address, uint256), decreaseAllowance(address, uint256): Standard ERC20 functions. transfer and transferFrom trigger fee logic via _update.
• triggerAutoLiquidity(): external nonReentrant. Allows any user to trigger liquidity addition if conditions are met.

4. Owner-Restricted Functions (onlyOwner)

• setEchoPingerAddress(address _pingerAddress): Sets the authorized EchoPinger contract address.
• setFairLaunchAddress(address _newFairLaunchAddress): Sets the FairLaunch contract address and excludes it from fees/reflection.
• setDevWallets(address[] memory wallets): Sets/updates the array of 3 developer wallets for fee splitting.
• renounceOwnership(): Allows the current owner to renounce ownership (from Ownable).
• transferOwnership(address newOwner): Allows the current owner to transfer ownership (from Ownable).

5. External Authorized Functions

• executeLpFromPoke(): external nonReentrant. Callable only by echoPingerAddress. Triggers liquidity processing and maintenance.

6. Internal Core Logic Functions (Private/Internal)

• _update(address sender, address recipient, uint256 amount): Core internal function overriding ERC20, handles all token movements, fee application, reflection accounting, and holder counts.
• _calculateFees(uint256 amount): Calculates fee breakdown based on current contract phase.
• _distributeFees(...): Distributes collected fees to reflection, liquidity, burn, and dev; triggers _applyReflectionTokens and _addLiquidityAutomatically.
• _applyReflectionTokens(): Adjusts _scalingFactor to distribute reflection rewards.
• _addLiquidityAutomatically(): private. Swaps tokens for BNB and adds to LP. (Called by nonReentrant functions).
• handleLpAddFailure(uint256 tokensIntendedForLp): Manages repeated LP addition failures.
• _sendAccumulatedLpTokensToBox(): Sends leftover _accumulatedLiquidityTokens to boxAddress under specific conditions.

7. Fallback Function

• receive() external payable: Allows the contract to receive BNB directly, emitting BNBReceived.

Reflection (Auto-Staking)

Process

Reflection, or auto-staking, is ZeroMoon's mechanism for rewarding holders. A portion of every transaction fee is allocated to reflections. Instead of direct token transfers to each holder (which is gas-intensive), ZeroMoon uses a sophisticated _scalingFactor that is adjusted when reflections are processed. This effectively increases the value of tokens held by eligible participants over time.

How It Works

• Sources of Reflection Tokens:
  • Transaction Fees: The primary source is the reflection fee (3.5%, 4.5%, or 5.5% depending on the contract phase) taken from transactions and added to _accumulatedReflectionTokens.
  • Residual Contract Tokens (Fair Distribution): After liquidity provision goals (LP_DEPOSIT_LIMIT) are fully met and LP operations have stopped (_lpStop is true), any remaining 0Moon tokens held directly by the contract are also added to _accumulatedReflectionTokens.
  • Failed LP Tokens (Fallback): In rare cases where repeated attempts to add liquidity fail, tokens intended for LP might be diverted to the reflection pool as a fallback mechanism.
• Distribution via Scaling Factor: The _applyReflectionTokens function is called to process these accumulated tokens. A decrease in _scalingFactor means that when a user's balance is calculated, their effective token count increases.
• Balance Calculation: The public balanceOf(address account) function reflects these rewards by dividing a user's scaled balance by the current scaling factor.
• Exclusions: The contract itself, the deadWallet, the pancakeSwapV2Pair, a configured fairLaunchAddress, and other smart contracts are typically excluded from receiving reflections. This ensures rewards are concentrated among actual users (EOAs).
• Event: ReflectionShared event logs additions to the reflection pool.

Meaning for Users

• Passive Earnings: Hold 0Moon and automatically earn more from transaction activity.
• Increasing Reward Rates: As the project matures, the reflection fee percentage increases, enhancing rewards.
• Fairness: By excluding most contract addresses, reflections primarily benefit individual holders.
• Efficiency: The O(1) scaling factor method is gas-efficient and highly scalable.

Burning

Process

ZeroMoon incorporates a token burn mechanism to create deflationary pressure. A portion of transaction fees is designated as burnAmount. These tokens are effectively removed from circulation by allocating them to the deadWallet's balance until the BURN_LIMIT (50% of ORIGINAL_SUPPLY) is reached.

How It Works

• Fee Collection & Execution: The burn fee (2.5% before _burnStop) is calculated and transferred to the deadWallet within the _distributeFees function.
• Tracking: _burnedTokens tracks cumulative burns. The deadWallet's balance also reflects total tokens burned.
• Event: A Transfer event with deadWallet as the recipient logs the burn.
• Post-Burn Limit: Once _burnStop is true, the burn fee becomes 0%, and those fee points are reallocated to other components.

Meaning for Users

• Increased Scarcity: Burning reduces the circulating supply, which can positively impact token value.
• Defined Limit: The BURN_LIMIT ensures a predictable end to the burn phase.
• Transparency: Burned amounts are publicly auditable via _burnedTokens and Transfer events.

Automated Liquidity

Process

To ensure a robust and deep trading pool on PancakeSwap, ZeroMoon automatically adds liquidity using a portion of transaction fees. When thresholds are met, the contract swaps half its collected tokens for BNB and pairs them with the remaining half to add liquidity. This process continues until LP_DEPOSIT_LIMIT is reached.

How It Works

• Fee Collection: Liquidity fees are added to _accumulatedLiquidityTokens.
• Trigger Conditions & Execution: Liquidity addition can be initiated internally, by the EchoPinger Bot, or by any user via triggerAutoLiquidity().
• Execution (_addLiquidityAutomatically):
  1. Determines the amount of tokens to process in the current cycle.
  2. Approves the PancakeSwap Router to spend tokens.
  3. Swaps half the tokens for BNB.
  4. Adds the received BNB and the other half of tokens to the liquidity pool.
  5. LP tokens received are sent to the deadWallet, permanently locking this liquidity.
  6. Updates internal tracking variables.
  7. Handles potential failures with retries and fallback mechanisms.
• Events: LiquidityAdded on success, LiquidityAdditionFailed on failure.

Post-LP Limit: Token Management and Fair Distribution of Residuals

To ensure maximum fairness, a specific mechanism within the _distributeFees function handles all other 0Moon tokens held directly by the contract after liquidity goals are met. If the contract still holds a balance of 0Moon tokens, these residuals are automatically added to the _accumulatedReflectionTokens pool. This ensures they are distributed to all eligible token holders through the standard reflection mechanism, rather than being sent to a separate address or remaining idle.

Meaning for Users

• Improved Trading Stability: A growing liquidity pool reduces price slippage.
• Locked Liquidity: Sending LP tokens to the deadWallet is a critical safety feature, preventing rug pulls.
• Sustainable Growth: Liquidity is built organically from transaction volume.
• Ultimate Fairness: After LP goals, all non-earmarked residual tokens in the contract are given back to holders as reflections.

Developer Support

A portion of transaction fees is allocated to developer wallet(s) to fund ongoing project maintenance, innovation, and marketing. ZeroMoon's approach aims for sustainability while demonstrating a commitment to the community by reducing the developer fee share over time.

• Fee Rates: The developer fee starts at 1.0% and reduces in phases to a final 0.5%.
• Distribution: Fees are sent to the configured developer wallets.
• Sharing Mechanism: The 0.5% reduction in the developer fee is effectively reallocated, contributing directly to the increase in the reflection fee percentage as the contract matures.
• Reduced Dev Impact Over Time: The decreasing fee percentage lessens the portion taken by developers as the ecosystem matures.
• Enhanced Holder Rewards: The reallocation of part of the dev fee to reflections directly benefits long-term holders.

Community and Governance

ZeroMoon is designed for autonomous operation. Post-launch, with ownership renouncement (planned), governance may evolve through community consensus for future initiatives outside the immutable contract logic.

Join our community channels: Telegram and X (Twitter).

License

This project, including the ZeroMoon smart contract, is licensed under the MIT License.

---

EchoPinger Bot

1. Introduction

The ZeroMoon EchoPinger Bot is an off-chain application designed to monitor the ZeroMoon smart contract and the Binance Smart Chain (BSC) network. Its primary purpose is to ensure the timely execution of critical contract functions, particularly related to automated liquidity provision and other maintenance tasks defined within the ZeroMoon contract.

Note on Security: While this document describes the bot's functionality, the full source code of the operational bot may not be made public to protect specific operational strategies, advanced error handling, and security measures related to the bot's own wallet and gas management.

2. Core Responsibilities

• Monitor ZeroMoon Contract State: Regularly fetches data from the ZeroMoon contract, such as accumulated tokens for liquidity, total tokens deposited, the contract's BNB balance, and the status of the burn and LP mechanisms.
• Trigger Liquidity Provision: If conditions within the ZeroMoon contract are met for adding liquidity, the bot will call the triggerAutoLiquidity() function.
• Self-Funding for Gas Fees: The bot's wallet is a designated developer fee recipient. It automatically swaps a portion of its received 0Moon tokens for BNB to cover its ongoing operational gas costs.
• Manage Bot's Own Excess BNB: Ensures the bot's wallet maintains an optimal BNB balance, transferring any significant excess to a designated vault address.

3. ZeroMoon Contract Interaction

The bot primarily interacts with the following functions on the ZeroMoon.sol smart contract:

• Read Functions (Views): getAccumulatedLiquidityTokens(), getTotalLpDeposited(), _burnedTokens(), _burnStop(), _lpStop(), balanceOf(address).
• Write Functions (Transactions): triggerAutoLiquidity(), approve(address, uint256). The bot is the authorized echoPingerAddress and calls executeLpFromPoke().
• PancakeSwap Router Interaction: Uses swapExactTokensForETHSupportingFeeOnTransferTokens(...) to swap its dev fees into BNB.

4. Configuration

The bot operates based on several configurable parameters:

• Bot BNB Management: MIN_BOT_BNB_BALANCE and MAX_BOT_BNB_BALANCE to manage its own BNB levels.
• ZeroMoon Contract Parameters: Reads values like LP_DEPOSIT_LIMIT, MIN_TOKENS_TO_PROCESS_PER_CYCLE, and MIN_BNB_BALANCE from the contract to inform its decisions.
• Self-Funding Swap Logic: Uses MIN_ZEROMOON_TO_INITIATE_SWAP and ZEROMOON_SWAP_AMOUNT to manage its conversion of 0Moon to BNB.
• Operational: A CHECK_INTERVAL_MS determines how frequently the bot performs its checks.

5. Operational Logic

The bot runs in a continuous loop, performing the following checks in order:

1. Check and Trigger LP: Reads contract state and calls triggerAutoLiquidity() if conditions are met.
2. Manage 0Moon Balance (Self-Funding): If its own 0Moon balance is high enough, it swaps a portion for BNB to cover gas fees.
3. Manage BNB Balance: If its BNB balance is too high, it transfers the excess to a vault.
4. Wait: Pauses for the configured interval before repeating the cycle.

6. Funding and Maintenance

The EchoPinger Bot is designed to be self-sustaining. Its wallet receives a share of the developer fees in 0Moon tokens, which it automatically converts to BNB to pay for its own transaction costs. This ensures the bot can operate and support the ecosystem's health without requiring manual BNB top-ups.

7. Disclaimer

This bot is a utility to support the ZeroMoon ecosystem. Its operation depends on the off-chain infrastructure it runs on. The ZeroMoon smart contract is designed to function autonomously, but this bot ensures that key functions are triggered proactively. The self-funding mechanism relies on the ongoing collection of developer fees and market conditions for swapping 0Moon to BNB.