# Welcome to Lumoz ## What's Lumoz Lumoz is the leading **Modular AI Computing network**, offering robust computing power and verification services for AI and ZK applications across chains with diverse architectures. It is dedicated to providing advanced zero-knowledge proof (ZKP) services, supporting the development of Rollup networks, and delivering substantial computational power for cutting-edge technologies such as artificial intelligence (AI). Committed to enhancing the efficiency and accessibility of zero-knowledge computation, Lumoz Protocol aims to provide an open and fair computing platform for a global audience. Central to the Lumoz Protocol are two key components: Verifier Node and Compute Node. The Verifier Node is designed to verify zero-knowledge proofs for ZK and AI across multiple blockchains, necessitating its deployment across various chains. The other core part of the Lumoz Protocol is the Compute Node, which will be deployed on the Lumoz Chain. Utilizing a Proof of Work (PoW) algorithm, the Compute Node provides computational power for AI and ZK applications on different chains, generating ZK Proofs. In response to the current challenges of high computational costs in the zero-knowledge computing field, Lumoz Protocol draws on its extensive experience in ZKP to innovate and optimize circuits and algorithms, significantly improving computational efficiency. This approach effectively tackles the issues of high costs and low efficiency that Rollup projects face, while also reducing the barriers for ordinary users to engage in the ZK computing market. By harnessing the capabilities of both Verifier Node and Prover Node, Lumoz Protocol not only enhances the efficiency of zero-knowledge proof verification but also minimizes associated costs. This provides users and developers with a more cost-effective and efficient solution. With this innovative framework, Lumoz Protocol is advancing the frontiers of blockchain technology and paving the way for new possibilities in decentralized innovation. # Understand Lumoz # Modular AI Computing Network ## Modular Blockchains Modular rollup technology indeed provides a new approach and solution to address the impossible triangle problem of traditional blockchain. By breaking down the blockchain system into different modules, rollup implements a layered structure to achieve more efficient transaction processing and data management, thereby balancing decentralization, security, and scalability to some extent. Rollup modules typically include: **Settlement Layer:** Responsible for updating the asset status of the blockchain, usually operating on Layer 1 (the main chain). It verifies the data submitted by rollup and updates the results to the main chain to ensure the security and accuracy of assets. **Execution Layer:** Processes transactions on rollup, records, and updates transaction status. It can execute transactions quickly on the rollup network without waiting for confirmation from the main chain, thereby improving transaction processing speed and efficiency. **Consensus Layer:** Ensures consensus on the status of each transaction, ensuring the legality and security of transactions. It usually adopts efficient consensus algorithms such as Proof of Stake or Proof of Authority. **Data Availability Layer:** Records all transaction data that occurs on rollup and provides full data when updating asset status in the settlement layer. This helps ensure data traceability and integrity while enhancing system security and reliability. However, for ZK-Rollup, an additional core module is required, the **Compute Layer**. ### Modular Computing Network for AI and ZK computing The Lumoz computer layer, serving as the computational module, possesses the following characteristics: 1. **Decentralized Computing:** The Lumoz computational layer operates as a blockchain network, employing a hybrid consensus mechanism of Proof of Stake (POS) and Proof of Work (POW) to ensure decentralized computing power. This architecture provides continuous ZKP computing capacity for zkRollups and offers a secure data processing and model training environment for AI applications. 2. **Robust Computational Stability:** Comprised of thousands of GPU/CPU nodes, Lumoz computing nodes ensure not only the continuous computational capacity for ZKP and ZKFP but also support large-scale parallel computing required by AI, guaranteeing the efficient execution of computational tasks. 3. **Wide Compatibility:** Lumoz is highly compatible with mainstream Rollup solutions in the blockchain industry, such as Polygon zkEVM, zkSync, Scroll, and Starknet. It also caters to various computational needs in the AI field, providing strong support for different tech stacks through its unique computing mechanism. 4. **Cost-Efficiency:** The decentralized computing layer of Lumoz combines a comprehensive economic model, resulting in low-cost ZKP generation. This cost-efficiency is equally applicable to AI computational tasks, providing users with an economical and efficient solution for AI and blockchain computing.
# Nodes The Lumoz Protocol, leveraging its deep research and continuous innovation in the zero-knowledge (ZK) field, has significantly reduced the costs and participation barriers of zero-knowledge computing, opening the door for a wide range of users to engage with cutting-edge computing technologies. By joining the Lumoz zero-knowledge computing network, users have multiple flexible options: 1. **Verifier Node:** The Verifier Node plays a pivotal role in the Lumoz protocol, validating zero-knowledge proofs for multi-chain ZK and AI applications. Deployed across multiple blockchains, it rigorously verifies the computation processes and results of the Compute Node, ensuring accuracy and reliability. This makes it a cornerstone in maintaining the integrity of the entire system. 2. **Compute Node:** Acts as the computational engine of the network, responsible for executing AI tasks within the Lumoz network and generating corresponding ZKPs or ZKFPs. These proofs not only verify the correct execution of tasks but also ensure the privacy and security of information during the process. [Verifier Node Explained](/verifier/verifer-node-explained) # Lumoz Chain **Network name:** Lumoz Chain Mainnet **Default RPC URL: ** **Chain ID:** 96370 **Currency symbol:** MOZ **Block explorer URL: ** **Chainlist** [**https://chainlist.org/chain/96370**](https://chainlist.org/chain/96370) # Bridge Lumoz Bridge is the official bridge for seamless asset transfers between Arbitrum One and Lumoz. **From Arbitrum One to Lumoz** Supported Assets: * $MOZ * $esMOZ * OG NFT (coming soon) **From Lumoz to Arbitrum One** Supported Assets: * $MOZ # Overview Artificial intelligence (AI), a revolutionary technology driving the leap in social productivity, is reshaping human civilization at an exponential pace. However, within the centralized AI ecosystem, we are faced with three structural challenges: first, centralized server architectures are prone to single points of failure, meaning service interruptions can bring AI capabilities to a halt; second, the GPU arms race drives up usage costs, creating a gap between technological monopolies and widespread access; and third, the unclear ownership of data assets puts user privacy and information security at systemic risk. Lumoz’s decentralized AI(LDAI) ecosystem combines blockchain and zero-knowledge proof (ZK) technology to create a next-generation trusted AI infrastructure. Our solution brings three major innovations: **Elastic Architecture Redefining AI Availability** Built on the Lumoz Chain, our distributed node network enables decentralized operation of AI models, ensuring 99.99% continuous availability of AI services. The Lumoz blockchain network gives AI applications true industrial-grade reliability. **Democratized Computing Power Breaking Resource Monopolies** As the leading Modular Compute Layer, Lumoz Chain integrates computing resources from multiple countries around the globe. This allows developers to access advanced models like Deepseek and LLaMA at near-zero costs. This groundbreaking innovation removes computing power as a bottleneck for AI development. **Data Sovereignty Returning to Users** Using zero-knowledge proof encryption algorithms and decentralized storage protocols, we have created an encrypted data cube for user data assets: on the transport layer, we apply ZKP for encryption and availability verification; on the storage layer, decentralized DA networks provide distributed encrypted storage; and on the application layer, we offer a privacy-preserving computing sandbox. This three-tier protection ensures that user data sovereignty remains fully with the individual, bringing an end to the era of “data colonialism.” Lumoz is reshaping the underlying architecture of the AI world through blockchain technology, ensuring that the benefits of the AI revolution belong to every creator. Join us in building an open, accessible, and trusted next-generation AI paradigm. # Architecture The architecture of LDAI is designed with decentralization, modularity, and flexibility at its core, ensuring efficient operation in high-concurrency and large-scale computing scenarios.
# Computational Resource Management The computational resources are managed and scheduled through a decentralized cluster system. Each compute node collaborates via the Lumoz chain, with decentralized protocols ensuring efficient communication and resource sharing between nodes.
Core Functions: **• Node Management:** Manages node joining or leaving the network, as well as user rewards and penalties. **• Task Scheduling:** AI tasks are dynamically assigned to different compute nodes based on their load, optimizing resource utilization. **• Model Management:** Stores hot models in mirrored storage to improve user network entry and model computation start-up speed. **• Node Monitoring:** Continuously monitors the health and task load of each node in the cluster to ensure high availability and stability of the system. # Use Cases ## AI Model Training AI model training typically requires significant computational resources. Lumoz Decentralized AI (LDAI) provides a cost-effective and scalable platform through decentralized compute nodes and elastic resource scheduling. On LDAI, developers can distribute training tasks across nodes worldwide, optimizing resource utilization while significantly reducing hardware procurement and maintenance costs. ## Fine-tuning and Inference In addition to training, fine-tuning and inference of AI models also demand high computational power. LDAI’s resources can be dynamically adjusted to meet the real-time needs of fine-tuning and inference tasks. On the LDAI platform, the inference process of AI models can be carried out more quickly, while ensuring high accuracy and stability. ## Distributed Data Processing LDAI’s decentralized storage and privacy-preserving computing capabilities make it particularly strong in big data analysis. Traditional big data processing platforms often rely on centralized data centers, which face storage bottlenecks and privacy risks. LDAI, on the other hand, ensures data privacy through distributed storage and encrypted computing, while making data processing more efficient. ## Smart Contracts and Payments By integrating blockchain technology, LDAI enables decentralized payments for developers, such as payments for AI computational tasks. This smart contract-based payment system ensures transaction transparency and security, while reducing the cost and complexity of cross-border payments. ## AI Application Development Lumoz’s decentralized architecture also offers robust support for AI application development. Developers can create and deploy various AI applications, from natural language processing (NLP) to computer vision (CV), all of which can seamlessly run on the LDAI platform. # Chat with Lumoz Decentralized AI Try to chat with the Lumoz Decentralized AI. {% embed url="" %}
# Plan Lumoz Decentralized AI currently offers three subscription plans to users. **Free：Explore What Lumoz Decentrilized AI can do for you.** * Unlimited access to DeepSeek-R1-Distill-Llama-8B * Real-time data from the web with search **Plus: Creative work powered by Lumoz Decentrilized AI.** * Unlimited access to DeepSeek-R1-Distill-Llama-8B、DeepSeek-R1-Distill-Qwen-14B * Limited access to DeepSeek-R1-Distill-Qwen-32B * Standard Voice Mode * Limits on messaging, file uploads, advanced data analysis * Opportunities to test new features **Pro：Do everything you want by Lumoz Decentrilized AI.** * Everything in Plus * Unlimited access to all models * Advanced Voice Mode * Unlimited access to messaging, file uploads, advanced data analysis # Overview With the development of Web3, decentralized AI Agents have emerged as a key application. These agents operate autonomously without relying on centralized servers, handling user data and interacting with blockchain smart contracts. However, the openness and trustless nature of Web3 pose significant security challenges. AI Agents demonstrate potential in Web3 applications, such as managing private keys, automating transactions, and supporting DAO operations. Yet, their shortcomings in trustworthiness and accountability deviate from core principles like decentralization and transparency. This limits their broader adoption and hinders future development. To ensure a trustless system, Lumoz leverages Secure Enclave (Trusted Execution Environment, similar to Intel SGX) and an innovative key management mechanism. Secure Enclave provides robust hardware security guarantees, including the following features: * **Data Confidentiality:** All memory data is encrypted. * **Execution Integrity:** Even if an attacker gains control of the operating system or physical device, the correctness of the execution process remains intact. * **Remote Attestation:** Users can verify remotely that both hardware and software are operating within a secure environment. # How Lumoz TEE Works Lumoz aims to be the core processing platform for AI computation, playing a critical role in supporting scalable blockchain infrastructure. By integrating Trusted Execution Environment (TEE) technology, Lumoz ensures the security and transparency of its computational processes. This innovative combination merges the decentralization strengths of blockchain with the robust security of TEE, enabling Lumoz to deliver not only a decentralized cloud computing network but also the ability to efficiently execute various computational tasks in a trust-minimized environment.
#### Benefits of Introducing TEE * Hardware-Level Security: The secure hardware enclave ensures privacy, confidentiality, and data integrity. * No Computational Overhead: Applications running in TEE operate at nearly the same speed as those in a standard CPU environment. * Low Verification Costs: Verifying TEE proofs consumes minimal gas, requiring only ECDSA verification. #### TEE Implementation Outcomes * Tamper-Proof Data: Ensures that user request/response data cannot be altered by intermediaries. This requires secure communication channels and robust encryption mechanisms. * Secure Execution Environment: Both hardware and software must be protected from attacks, leveraging TEE to create an isolated environment for secure computation. * Open-Source and Reproducible Versions: The entire software stack, from the operating system to application code, must be reproducible. This allows auditors to verify the system's integrity. * Verifiable Execution Results: AI computation results must be verifiable to ensure that outputs are trustworthy and untampered. #### **TEE (Intel SGX) Framework**
#### TEE Server Security Verification When the service starts, it generates a signing key within the TEE. 1. You can obtain CPU and GPU attestations to verify that the service is running within a confidential VM in TEE mode. 2. The attestation includes the public key of the signing key, proving that the key was generated within the TEE. 3. All inference results are signed using the signing key. 4. You can use the public key to verify that all inference results were generated within the TEE. ### **TEE and ZK Multi-Proof** No single cryptographic system can be guaranteed to be 100% secure. While current Zero-Knowledge (ZK) solutions are theoretically secure, they cannot ensure flawless operation across the entire system, especially from an engineering perspective, given the complexity of ZK implementations. This is where multi-proof systems come into play. To mitigate potential errors in ZK implementations, hardware-based solutions like Trusted Execution Environments (TEE) can act as a dual-factor verifier, providing an additional layer of security for ZK-based projects such as AI Agents.
# The Core Architecture Design ## **Decentralized Root-of-Trust (DROT)** Decentralized Root-of-Trust (DROT) is a core component of the Trusted Execution Environment (TEE) trust chain. Ultimately, user verification relies on remote proofs signed by the CPU, which depend on a set of hardware-stored keys for generation. The hardware components responsible for managing these root keys, verifying firmware and applications, and issuing remote proofs are collectively referred to as DROT.
## **Key Management Protocol** In the overall design, key management follows the principle of least privilege, meaning that the secrets known by each entity are strictly limited to what is necessary to perform its specific task.
## **TEE Controlled Domain Certificates** In the solution design, the certificate management module serves as a reverse proxy for applications running on the network. It is important to note that as part of the overall solution, it operates within the TEE and is managed by smart contracts.
# Lumoz AI Agent Framework
# Compute Node # Why Compute Node Lumoz, a cutting-edge modular computing protocol, is dedicated to providing robust zero-knowledge (ZK) computing power to projects in fields like Rollups and artificial intelligence (AI). ZK technology offers significant advantages in reducing data storage and verification costs. However, the current market is plagued by the issue of centralized ZK computing services. When centralized compute nodes experience failures, attacks, or shutdowns, the entire network can be severely impacted. Moreover, these centralized control nodes may prioritize their own interests by selectively generating proofs or deliberately delaying their creation. This not only harms the rights of network users but also restricts participation to a few well-resourced entities due to the high-performance hardware and specialized skills required for ZK computation, leaving out regular users and decentralized nodes. By optimizing ZK computing algorithms, Lumoz significantly lowers the barriers to entry, allowing regular users to easily join the Lumoz ZK computing network. As a zkProver in Lumoz, participants can contribute decentralized computing power to the network while earning Lumoz protocol tokens as rewards. This not only incentivizes broader community involvement but also ensures the stability and transparency of the network. Lumoz invites individuals and entities with GPUs to join the protocol and help drive the decentralization of ZK computing. # How do Compute Nodes Work Compute Node is one of the core components of the Lumoz Protocol, responsible for computing ZKPs and AI results within the protocol. By utilizing task splitting, parallel computation, and proof aggregation, we effectively enhance the efficiency of ZKP/AI computation and reduce its overall cost. Below is an overview of the workflow of Compute nodes:
1. **Listening for Tasks:** Compute Nodes will continuously monitor the chain for the publication of corresponding tasks based on the type of proof and initiate calculations accordingly. 2. **Proof Calculation:** A single task will be recursively broken down into multiple sub-tasks, allowing for parallel computation. At the same time, nodes will check the local cache for any precomputed or cached results that can be reused to optimize the process. 3. **Sub-task Aggregation:** Once all sub-tasks have been computed, the results will be aggregated into a single, complete proof. 4. **Aggregation and Submission of Multiple Proofs:** Instead of submitting a single proof immediately after generation, nodes will wait to aggregate it with subsequent proofs. The combined proofs and node information will be consolidated into a compact submission, which will then be posted on-chain to minimize cost overhead. 5. **Waiting for Subsequent Verification Steps:** Following submission, nodes will proceed to the next stage of the verification process. # Rewards * 25% Lumoz Token (MOZ) Incentive. # Setup Compute Node Coming soon. # Requirements **Hardware:** GPU **OS Version:** Ubuntu 20.04 + **Nvidia Driver Version:** 535.54.03 + # Guide GitHub: 1. Get an evm address. 2. Download zkwork Nvidia miner: `wget https://github.com/6block/zkwork_moz_prover/releases/download/v1.0.0/moz_prover_cuda.tar.gz`. 3. Download zkwork AMD miner: `wget https://github.com/6block/zkwork_moz_prover/releases/download/v1.0.0/moz_prover_ocl.tar.gz`. 4. On Nvidia: `tar -zvxf moz_prover_cuda.tar.gz && cd moz_prover`, on AMD: `tar -zvxf moz_prover_ocl.tar.gz && cd moz_prover`. 5. Update your Lumoz address in `inner_prover.sh` and set custom name for mining server. 6. Start mining with `sudo chmod +x run_prover.sh && ./run_prover.sh`. 7. Check mining log with `tail -f prover.log`. # Overview Rollup as a Service (RaaS) is an innovative blockchain solution designed to help developers and projects quickly deploy and manage custom rollup networks without the need to build complex infrastructure from scratch. By batching multiple transactions and submitting them to a main chain like Ethereum, rollup technology significantly enhances transaction speed and reduces costs. Features of RaaS： * **Streamlined Deployment:** Lumoz provides comprehensive tools and frameworks to help users effortlessly launch various rollup networks, including zk-rollups and optimistic rollups. * **Highly Customizable:** Projects can tailor rollup networks to their specific needs by adjusting parameters like consensus mechanisms, fee structures, and security settings. * **Enable Efficient Scaling:** With RaaS, rollup networks inherit the main chain’s robust security while significantly boosting transaction throughput, making them ideal for high-frequency use cases like DeFi, gaming, and AI. * **Simplify Maintenance:** Lumoz handles all technical operations and upgrades, reducing developers’ technical barriers and operational costs, making network management effortless. * **Enhance Interoperability:** Seamlessly integrates with the mainchain and other rollup networks, enabling effortless cross-chain asset and data transfers. # Lumoz RaaS Stack
# Rollups Built with Lumoz ## [DuckChain](https://duckchain.io/) The first #TON consumer layer connecting TON with EVM, BTC, and more! ## [UXLINK](https://www.uxlink.io/) UXLINK is a web3 social platform and infrastructure, where super Dapps take off. ## [Merlin](https://merlinchain.io/) Unleashing Bitcoin's potential with native L1 assets, users and protocols. ## [CARV](https://carv.io/) CARV is building the largest modular data layer for gaming and AI. ## [ZKFair](https://zkfair.io/) The first community ZK-Rollup based on Polygon CDK and Celestia DA, 100% token airdrop. No Investors, No Reserve, No Pre-mining, It's All Community. ## [MATR1X](https://matr1x.io/) MATR1X is an innovative cultural and entertainment platform combining gaming, AI, Esports and blockchain infrastructure. We strive to revolutionize the global gaming and digital content industry via blockchain and AI technology. ## [Ultiverse](https://www.ultiverse.io/home) Ultiverse is an integrated Web3 platform combining GameFi, NFTs, DeFi, Marketplace, and Liquid Staking. Ultiverse aims at building the next-generation entrance connecting Web3 with players all around the world. ## [REVOX](https://www.revox.ai/) Agents in Smart Contracts. # Verifer Node Explained # Why Verifier Node Lumoz Protocol, as a pioneer in decentralized computing, undertakes the critical responsibility of managing the entire protocol's data input and output. We perform a series of precise operations on the data, including aggregation, computation, and validation, covering various fields such as blockchain transaction data and AI model training data. The processed data results are impartially published to the blockchain, ensuring transparency and fairness in data dissemination and providing a solid foundation for the healthy development of the entire ecosystem. To ensure the security, accuracy, and decentralization of the data processing process and its results, Lumoz Protocol introduces a mechanism of verification nodes. The core mission of these nodes is to review and verify every step and outcome of data processing to safeguard the security and interests of user data. Data verified by verification nodes will be officially recorded on the blockchain. However, relying entirely on third-party verification systems still has limitations that may affect the fairness of network value distribution. Therefore, Lumoz actively advocates and promotes community participation in the verification process to enhance the network's self-regulatory capabilities. Lumoz aims for a highly transparent, thoroughly decentralized, and censorship-resistant verification network. In such a network, at least two-thirds of the nodes should maintain integrity, accurately publish data, and have the ability to identify, report, and prevent improper data behavior. We are tirelessly advancing towards this goal and globally inviting community members to participate in the operation of verification nodes. Looking ahead to the 2025, Lumoz's verification nodes will shoulder even greater responsibilities. They will serve as a universal verification protocol on the chain, providing data verification services to a wider range of enterprises and users and continuously creating value in the process. We will continue to optimize the responsibility allocation and functionality settings of verification nodes to enhance the efficiency and reliability of the entire network. Lumoz sincerely invites the global community to join hands with us in creating a more prosperous computing future. # How do Verifier Node Work **Verifier Node** is one key component in the Lumoz architecture, responsible for verifying the ZKPs generated by Compute Node. It ensures the correctness and validity of the proofs submitted to the chain, safeguarding the trust and security of the system. Through optimized verification processes, Verifier Node efficiently processes proofs, reducing operational costs and gas consumption. Below is an overview of the workflow of Verifier nodes:
1. **Proof Submission:** Proofs generated by Compute Node are submitted to Lumoz Chain to initiate verification tasks. 2. **Proof Verification:** Lumoz Chain sends verification tasks to multiple Verifier nodes, which independently execute distributed verification. 3. **Collective Decision-Making:** At least two-thirds of the verification nodes confirm the validity of the proof, ensuring the authority and consistency of the verification results. 4. **Verification Result Handling:** Valid proofs and their results are transmitted back to the Lumoz Proof Contract on the blockchain by Lumoz AVS Oracle, and task results are recorded and responded to Lumoz Chain via Task Manager Contract. Through this carefully designed verification mechanism, the Lumoz Protocol not only ensures the security of Rollup transactions but also guarantees the accuracy and integrity of AI service data processing. We are committed to building a decentralized computing environment that supports efficient transaction verification and ensures the quality of AI data processing, providing a solid infrastructure for a wide range of applications. # License License is the official recognition of Verifier Node identity, serving as a necessary binding condition when setting up a Verifier Node. To ensure the quality and decentralization of the protocol, we have set a limit of 100,000 licenses. These licenses exist in the form of non-fungible tokens (NFTs), ensuring the uniqueness and non-replicability of each license. The introduction of NFTs not only provides secure digital ownership proof for licenses but also allows licenses to be freely transferred among users. This flexibility gives users complete control over Verifier Nodes, enabling them to buy, sell, or transfer their licenses according to market demand and personal preferences. Importantly, when a Verifier Node transfers its held license to another party, the node will no longer be eligible to receive any form of reward from the Lumoz network. This mechanism aims to encourage long-term network participation and contribution while ensuring fairness and transparency in network reward distribution. Through the License system, the Lumoz network aims to establish a stable, efficient, and user-friendly environment for Verifier Node operation. We welcome and encourage active participation from the global community to collectively maintain and promote the continuous development and prosperity of the Lumoz ecosystem. # Rewards * 25% Lumoz Token Incentive * Potential token airdrops for the new Lumoz ecosystem chains. ## How to calculate rewards? ### Rewards of one epoch 25% of Lumoz tokens will be released over 3 years, with 95,129.37 esMOZ released per hour(one epoch). ### Rewards of one Node(one epoch) Each epoch, licenses across all nodes are selected based on the reward probability determined by the current [node tier](/verifier/node-tier). Selected licenses are eligible to participate in submissions. The reward for each eligible license equals the current epoch’s total reward divided by the number of eligible licenses in that epoch. The reward a node can earn equals the reward per eligible license multiplied by the number of eligible licenses within the node for the current epoch. Node rewards will be splited 3 parts: Node commission rewards, Staking esMOZ rewards, Delegating license rewards. ### Node commission rewards(one epoch) Node rewards multiplied by the commission rewards split. ### Staking esMOZ rewards(one epoch) Node rewards multiplied by the Staking esMOZ split. #### Rewards of one staker(one epoch) The reward a staker can earn equals the total reward allocated to stakers in the current epoch, multiplied by the ratio of the staker’s stake in the node to the total stake in the node. ### Delegating esMOZ rewards(one epoch) Node rewards multiplied by the Delegating license split. #### Rewards of one delegator(one epoch) The reward a delegator can earn equals the total reward allocated to delegators in the current epoch, multiplied by the ratio of the delegator’s license delegated amount to the node to the total license delegated to the node. # Purchase Verifier Node Lumoz Verifier Node opens a convenient gateway for users to seamlessly integrate into the Lumoz protocol's Zero-Knowledge (ZK) computing ecosystem. By deploying Verifier Node, users can not only rigorously validate the data, computing processes, and results in the Lumoz protocol to ensure the accuracy and integrity of data computation, but also receive rewards from the Lumoz protocol for contributing their verification capabilities. This process not only strengthens the security and trustworthiness of the network but also provides users with a valuable opportunity to participate in and benefit from blockchain technology innovation. # Purchase License ## License Tiers The Licenses is divided into a total of 10 tiers, with each tier having a fixed quantity and a different price. As the tier increases, the price of the License also increases accordingly. [Check tiers.](/verifier/purchase-verifier-node/license-tiers) ## Assets Price | Assets | Network | Price(2024-06-12) | | ------ | ----------------------- | ----------------- | | ETH | Arbitrum One | $3537.58 | | BTC | Merlin、BSC | $67740.98 | | USDT | Arbitrum One、BSC | $1.00 | | USDC | Arbitrum One、ZKFair、BSC | $1.00 | | BNB | BSC | $611.11 | ## Public Sale Ended. # Buyback Guarantee To ensure the rights and interests of our global community users to the greatest extent, we have established a refund mechanism. ## Refund Window The refund window Will open 6 months after the start of TGE(Token Generation Event). The duration of the window is to be determined. ## Refund Terms The refund policy applies to retail users only. If users are dissatisfied for any reason, they may apply for a refund. We will unconditionally refund 80% of the initial payment amount. At the same time, the user needs to return all received benefits and licenses. # License Tiers License is divided into 10 tiers in total, with each tier having a different quantity and price. As the tier increases, the price of the license also increases accordingly. The specific quantity and price of each tier of the license are shown in the table below: **Total Licenses：100000**
TierVerifier Node Price (USD)Total Verifier nodes per TierNodes sold (accumulated)Real-time implied Tier FDV {M}Implied Tier FDV with 50% Projected Participation Rate {M}Implied Tier FDV with 100% Projected Participation Rate {M}
1200 800080006.4 40.0 80.0
2230 90001700015.6 46.0 92.0
3265 100002700028.6 52.9 105.8
4304 120003900047.5 60.8 121.7
5350 120005100071.4 70.0 139.9
6402 1200063000101.4 80.5 160.9
7463 1000073000135.1 92.5 185.0
8532 1000083000176.6 106.4 212.8
9612 900092000225.1 122.4 244.7
10704 8000100000281.4 140.7 281.4
# Invitation To express sincere gratitude to all supporters and participants, Lumoz has launched a special Invitation Program, aiming to ensure that every community member can benefit from the network's growth. ## Rule 1. How to get the invitation code: 1. Once the whitelist sale begins, click the "Generate" button on the sale page to generate your own invitation code. 2. Reward for the inviter: As an inviter, 1. When A invites B to purchase a license using A's invitation code, A will receive a reward equivalent to 7% of the actual token amount paid by B. This is recognition of A's contribution to introducing new members to the network. 2. When B invites C to purchase a license using B's invitation code, B will receive a reward equivalent to 7% of the actual token amount paid by C, and A will also receive a reward equivalent to 3% of the actual token amount paid by C. 3. Discount for the invitee: As the invitee, when you use someone else's invitation code to complete the purchase of a license, you can also enjoy a 1% rebate on the actual token amount paid as a welcome gift for joining the Lumoz network. 4. Reward and rebate inquiry: After linking your wallet on the designated page, you will be able to view the rewards and rebate accumulated as an inviter or invitee in real time. 5. Claim process: After the end of the public sale round, all accumulated rewards and rebate will be available for claim. The Lumoz network will ensure transparency and convenience throughout the process. # FAQ ## Invitation * **How to get an invitation code？** * After 2024-06-25 15:00 (UTC+8), users can generate their exclusive invitation codes by linking their wallets on the license sale page and rewards page, and then clicking the "Generate" button. * **What is the purpose of an invitation code?** * As an inviter, you can earn a 7% reward by inviting others to purchase a license using your invitation code. If the invitees further invite others, the inviter continues to earn rewards. For specific rules, please refer to the[ invitation rules](/verifier/purchase-verifier-node/invitation#rule). * As an invitee, when purchasing a license during the whitelist sale round and the public sale round using an invitation code, you can receive a 1% rebate. * **Where can I see my invitation rewards and rebate from purchasing a license？** * Invitation rewards page : * Rebate page : ## **Running Verifier Nodes** * **How to run a Verifier node?** * Verifier nodes start running after the mainnet launch. Nodes can be operated in various ways, such as via CLI or Docker. Keep the node online to maintain its operation. If you do not want to run the node yourself, you can delegate your license to other nodes. * Is there a penalty mechanism if a node is offline? * A node will not receive rewards while it is offline. * **What are the specific requirements for keeping a mainnet node online?** * The node needs to be continuously running with a stable network connection. * **What is the estimated cost of running a node?** * Please refer to the node operation configuration requirements for cost details. * **What are the estimated fees for node hosting?** * Delegating your license to another operator requires paying a certain commission percentage to the operator. * **Can multiple nodes run on a single IP?** * Yes, multiple nodes can run on a single IP. * **How do community users confirm receipt of their node, and how can they verify ownership or check their address contract?** * After purchase, users can claim the mainnet license form . * **Can nodes be transferred?** * Nodes can be transferred 6 months after TGE. ## Others * **Is there a fee for delegating the license to someone else?** * There may or may not be a delegation fee depending on the specific node owner. Many node partners as well as individual nodes will participate in the Verifier node network, and you can pick the one with the lowest commission to delegate. # Setup Verifier Node # Who can run a node？ Anyone who holds at least one Verifier node license can run a Verifier node by downloading the node client software, installing it, and running it. # Requirements ## **License** Running a node requires holding at least one Verifier node license. ## **Hardware** CPU: **2 CPU Cores** **x86/X64 Processor** RAM: **4 GB RAM** Storage: **60 GB Disk Space** Bandwidth: **Stable Internet Connection** # Setup Node # Node as a Service ## Easeflow ## NodeOps [**https://console.nodeops.xyz/deployNode/lumoz**](https://console.nodeops.xyz/deployNode/lumoz) # Build your own # 1. Build RPC of Lumoz Chain ## Requirements CPU: 8 core + RAM: 16 Gb+ Storage: 500 Gb+
## Docker 1. Download docker-compose.yml ```javascript curl -L -o ./docker-compose.yml https://download.lumoz.org/lumoz-external-node/docker-run/docker-compose.yml ``` 2. Download snapshot of Genesis file under the root path of docker-compose.yml ```javascript curl -L -o /tmp/genesis.tar https://download.lumoz.org/lumoz-external-node/lumoz-external-node/geth/mainnet/config/genesis.tar && tar -xvf /tmp/genesis.tar -C ./ && rm /tmp/genesis.tar ``` 3. Start RPC ```javascript docker-compose up -d ``` 4. Check logs ```javascript docker logs -f lumoz-mainnet-node ``` 5. Test ```javascript curl http://localhost:9545 \ -X POST \ -H "Content-Type: application/json" \ --data '{"method":"eth_blockNumber","params":[],"id":1,"jsonrpc":"2.0"}' ``` ### Note: RPC address(default): device IP+9545 WS address(default): device IP+9546 > If IP is 1.2.3.4, the RPC address will be , and the WS address will be WS://1.2.3.4:9546 #### Customize port Edit the docker-compose.yml if you want to change the port. {% hint style="info" %} Port 33666 needs to be opened for external access. This port facilitates stable P2P connections with other external nodes for block data synchronization. {% endhint %} # 2. Configuring JSONRPC Configuring JSONRPC in Environment Variables. ## [Build RPC of Lumoz Chian](/verifier/setup-verifier-node/setup-node/build-your-own/1.-build-rpc-of-lumoz-chain) ## Configuring Environment Variables ### For Linux/macOS 1. Open the configuration file: ``` nano ~/.bashrc ``` *(For Zsh, use \~/.zshrc instead.)* 2. Add the following line: ``` export JSONRPC_URL=https://your-rpc-endpoint.example.com ``` 3. Save the file and apply changes: ``` source ~/.bashrc ``` 4. Verify: ``` echo $JSONRPC_URL ``` ### For Windows #### Using the System Settings: 1\. Open Environment Variables: • Press Win + R, type sysdm.cpl, and hit Enter. • Go to the Advanced tab and click on Environment Variables. 2\. Add a New Variable: • Under User variables or System variables, click New. • Enter JSONRPC\_URL as the name and {your\_rpc} as the value. • Click OK to save. 3\. Verify: • Open a new Command Prompt and run: ``` echo %JSONRPC_URL% ``` #### Using Command Prompt: ``` setx JSONRPC_URL https://your-rpc-endpoint.example.com ``` Verify: • Close and reopen Command Prompt. • Run: ``` echo %JSONRPC_URL% ``` #### Using PowerShell: ``` [System.Environment]::SetEnvironmentVariable("JSONRPC_URL", "https://your-rpc-endpoint.example.com", "User") ``` Verify: • Close and reopen PowerShell. • Run: ``` $env:JSONRPC_URL ``` ### For Docker [See here](/verifier/setup-verifier-node/setup-node/build-your-own/2.-run-the-node/run-with-docker-recommended-for-multiple-nodes). # 1. Initialize a Node ## **Step1:** Download the CLI client ## **Step2: Open terminal/cmd and e**nter the client directory and run(macOS as an example) ``` ./verifier-node-macos-arm64 ``` ## **Step3:** Init your node. 1. Enter `init`,then press Enter. 2. Enter the private key of the node owner(the wallet holding the license), then press Enter. {% hint style="info" %} Creating a node requires interaction with the smart contract. Since the CLI cannot directly interact with your wallet and the on-chain smart contract, you will need to input your private key. However, the private key remains on your local device and will only be used once during the initialization process. {% endhint %} 3. Enter the address of the node operator, then press Enter. {% hint style="info" %} If you do not enter an address and just press Enter, the address will default to the node owner. This node operator's address is primarily used for interacting with the Lumoz chain, including but not limited to submitting verification task results, and requires some MOZ as gas fee tokens. {% endhint %} 4. Check the operator's address, if it's correct, enter y/Y or just press Enter, else, enter n/N, enter the right address. 5. Enter the number of licenses to delegate to yourself, at least one. 6. Set the reward distribution split: your commission, delegated license rewards, and staked esMOZ rewards. The total must equal 100, or just press Enter to use the default value. {% hint style="info" %} Default split: commission rewards: 5(5%) delegated license rewards: 45(45%) staked esMOZ rewards: 45(45%) {% endhint %} 7. Enter your node name, None as default. 8. Enter your node description, None as default. 9. Enter your node logo URL, None as default. 10. Enter your social media URL, None as default. Congratulations, your node operator has been successfully initialized. # 2. Run the Node Lumoz offers two methods for running nodes. After [initializing a node](/verifier/setup-verifier-node/setup-node/build-your-own/1.-initialize-a-node) through the Command Line Interface (CLI), users can continue to run the node [via the CLI](/verifier/setup-verifier-node/setup-node/build-your-own/2.-run-the-node/run-with-cli). For those who are considering running multiple nodes or managing nodes across multiple servers, the [Docker approach](/verifier/setup-verifier-node/setup-node/build-your-own/2.-run-the-node/run-with-docker-recommended-for-multiple-nodes) is recommended for node deployment. This method provides a streamlined and efficient way to manage and maintain node operations. # Run with CLI ## **Step1:** Run your node. 1. Enter `node-runner`,then press Enter. 2. Enter the private key of the operator's address (Ensure your wallet has enough ETH tokens), then press Enter. ## **Step2:** Run the reward claim program. 1. Enter `reward-claimer`, then press Enter. 2. Enter the private key of the node operator(recommended) or node owner, then press Enter. Congratulations, your node is running successfully. # Run with Docker(recommended for multiple nodes) {% hint style="info" %} If you don’t have Docker yet, [download it here](https://www.docker.com/products/docker-desktop). {% endhint %} ## **Step1: Create the `.env` file** ```Bash NODE_OPERATOR_PRIVATE_KEY={put the private key of your node operator wallet here} NODE_OWNER_PRIVATE_KEY={put the private key of your node owner wallet here} JSONRPC_URL={your_rpc_url} ADDRESS_OF_OWNER_OR_OPERSTOR={put the wallet address of your node owner or operator} ``` ## **Step2: Create the** `docker-compose.yml` file ```Bash version: "3.5" services: lumoz-Verifier-node: container_name: lumoz-Verifier-node image: lumozorg/lumoz-verifier-node:latest environment: - WALLET_PRIVATE_KEY=${NODE_OPERATOR_PRIVATE_KEY} - JSONRPC_URL=${JSONRPC_URL} command: - "/bin/sh" - "-c" - "/app/verifier-node node-runner" lumoz-Verifier-node-claim: container_name: lumoz-Verifier-node-claim image: lumozorg/lumoz-verifier-node:latest environment: - JSONRPC_URL=${JSONRPC_URL} - WALLET_PRIVATE_KEY=${NODE_OWNER_PRIVATE_KEY} - OWNEROROPERATOR=${ADDRESS_OF_OWNER_OR_OPERSTOR} command: - "/bin/sh" - "-c" - "/app/verifier-node reward-claimer" ``` ## **Step3:** Run your node. #### `sudo docker-compose -f docker-compose.yml up -d lumoz-Verifier-node` ## **Step4:** Run the reward claim program. `sudo docker-compose -f docker-compose.yml up -d lumoz-Verifier-node-claim` Congratulations, your node is running successfully. # 3. Update Node Information(optional) After you have completed setting up your node, you can go to to modify your node profile and rewards split. ## Update your Profile Step1: Go to Step2: Click ***My Node*** and connect your wallet
Step3: click ***Update***
Step4: click ***Edit***
Step5: update your profile
## Update your Rewards Split Step1: Go to Step2: Click ***My Node*** and connect your wallet Step3: click ***Update*** Step4: click ***Edit***
Step5: update your Rewards Split
{% hint style="info" %} With nodes there will be time cooldowns for reward split changes to complete. {% endhint %} # FAQ **1. Can one address run multiple nodes?** No, one address can only run one node. If you want to run multiple nodes, you will need multiple addresses. **2. How many licenses can a single node support for delegation?** Up to 500. **3. How many $esMOZ token can a single node support for staking?** Up to 10,000,000. **4. What is the difference between a license and a node?** A license is the authorization required to run a node. Only those who holds a license are allowed to run a node. **5. What is a node owner?** The address with the license used during node initialization. **6. What is a node operator?** When running a node, the node interacts with the blockchain using the operator address. This operator address can either be the node owner’s address or a different address set for this purpose. **7. How long does it take to receive funds after unstaking esMOZ?** Instant. **8. How long does it take to receive funds after undelegating license?** Instant. **9. Do I need to stake esMOZ to run a node independently?** You can run a node without staking esMOZ, but a minimum of 10,000 esMOZ staked per node is required to qualify for rewards. **10. Does running the reward-claimer command once enable automatic reward claims?** Once executed, it will run in the background but requires the terminal to remain open. **11. How long does it take for automatically claimed rewards to arrive?** Rewards for the previous epoch are claimed once per epoch, with each epoch lasting 1 hour. **12. Why are my node rewards showing as 0?** * Please check if you have completed the steps for [running the node and claiming rewards](/verifier/setup-verifier-node/setup-node/build-your-own/2.-run-the-node) after the node initialization. * Please check do you have enough MOZ in your operator wallet. * Please check if your CLI client running well. * Please check if your node tier have been Bronze (10000 staked esMOZ at least). * Maybe your node needs more licenses delegated. * Maybe you need a stable RPC. **13. How to get a JSON-RPC?** Refer to : [Build RPC of Lumoz Chian](/verifier/setup-verifier-node/setup-node/build-your-own/1.-build-rpc-of-lumoz-chain) # Troubleshooting 1. "Delegate:invalid" When entering the operator address, the owner’s address cannot be used. 2. Why does the Windows node client crash immediately after opening? Check if the environment variables are set. # Delegate Licenses ## Overview If the license holder does not want to run a node themselves, they can delegate the license to a node to earn validation rewards. # Claim License All users who have purchased a Lumoz Verifier Node can claim a corresponding number of licenses. ## Guide Step1: Go to Step2: Connect wallet Step3: Enter the number of licenses to claim and the address to receive them. {% hint style="info" %} A single address can only run one node. If you want to run multiple nodes, you can claim licenses to different addresses. {% endhint %}
Step4: Click ***Claim*** button and confirm in your wallet. Step5: [Run a node](/verifier/setup-verifier-node/setup-node) or [delegate your license](/verifier/delegate-licenses/delegate-guide). # Delegate Guide ## Guide Step1: Go to Step2: Connect wallet Step3: Click ***Delegate***
Step4: Select ***Available Nodes***
Step5: Choose a node and click ***Delegate***
Step6: Enter the license amount you want to delegate
Step7: Click the ***Delegate*** button and confirm in your wallet # Undelegate Guide ## Guide Step1: Go to Step2: Connect wallet Step3: Click ***Delegate***
Step4: Select ***Delegated Nodes***
Step5: Click on the node you want to undelegate.
Step6: Click the ***Undelegate*** button.
Step7: Enter the license amount you want to undelegate
Step8: Click the ***Undelegate*** button and confirm in your wallet. # Staking ## Overview Staking is one of the core features of the Lumoz protocol, enhancing its security and decentralization. It is also the primary way for Lumoz community members to participate in the network’s operations. When staking, users need to choose a Node. The more esMOZ staked with a Node, the higher the probability of earning rewards, and the more rewards stakers can receive. # Staking Guide ## Guide Step1: Go to Step2: Connect wallet Step3: Click ***Staking***
Step4: Select ***Available Nodes***
Step5: Choose a node and click ***Stake***
Step6: Enter the esMOZ/MOZ amount you want to stake
Step7: Click the ***Stake*** button and confirm in your wallet # Unstaking Guide ## Guide Step1: Go to Step2: Connect wallet Step3: Click ***Staking***
Step4: Select ***Staked Nodes***
Step5: Click on the node you want to unstake.
Step6: Click ***Unstake*** button.
Step7: Enter the amount you want to unstake
Step8: Click the ***Unstake*** button and confirm in your wallet. # Node Tier ## Overview Running a Node client as a Node allows you to accept user staking of esMOZ. The amount of esMOZ staked by users will determine the current rank of the Node. Different ranks have varying reward probabilities.The following informational table denotes the amount of staked esMOZ per Node required to lift the licenses within that operator by a given Reward Multiplier (Reward Tier Threshold). It also denotes the associated adjustment to the baseline 1% probability for delegating to participate in a Verification Task (Reward Multiplier): ## **Tier** | Tier | Reward Tier Threshold | Reward Multiplier | | -------- | --------------------- | ----------------- | | Iron | 0 | 0 | | Bronze | 10,000 | 1x | | Silver | 1,000,000 | 1.5x | | Gold | 2,000,000 | 2x | | Platinum | 4,000,000 | 3x | | Diamond | 8,000,000 | 7x | Iron: The default Tier is the initial level when a Node starts running, with a 0% probability of being selected to participate in validation tasks. Bronze: When the esMOZ stake reaches 10k, the licenses delegated to the Node have a 1% probability of being selected to participate in validation tasks. Silver: When the esMOZ stake reaches 1 million, the licenses delegated to the Node have a 1.5% probability of being selected to participate in validation tasks. Gold: When the esMOZ stake reaches 2 million, the licenses delegated to the Node have a 2% probability of being selected to participate in validation tasks. Platinum: When the esMOZ stake reaches 4 million, the licenses delegated to the Node have a 3% probability of being selected to participate in validation tasks. Diamond: When the esMOZ stake reaches 8 million, the licenses delegated to the Node have a 7% probability of being selected to participate in validation tasks. # Time Cooldown With nodes there will be time cooldowns for reward split changes to complete.Nodes Reward split changes - when a node changes the reward split, these changes will not go into effect immediately. This is to allow the stakers and delegators within the node time to unstake or undelegate before the new reward split takes effect. 1. To find current values for reward split change times 2. Go to the Staking or Delegate page 3. It is displayed as “updateShares” *Remember, it is up to you to monitor the node rewards split and to satisfy yourself that you are happy with any changes. The Lumoz team takes no responsibility for the reward split. Please refer to the Terms of Use.* # Risk Notice and Disclaimer of Lumoz Verifier Node Sale We highly value every user’s right to be informed and their investment safety. Therefore, we solemnly declare: **Comprehensive Understanding:** All users participating in the purchase of Verifier nodes must fully understand the functions, purposes, and technical details of these nodes. This includes but is not limited to their role in the Lumoz architecture, working principles, profit mechanisms, and related operational requirements. **Informed Consent:** Before purchasing Verifier nodes, users should carefully read and understand all relevant documents and information, including but not limited to the technical whitepaper, user guides, FAQs, and other official materials. Users should ensure they have a comprehensive and accurate understanding of the product. **Investment Risks:** All users must clearly understand that investing in Verifier nodes may involve various risks. These risks include but are not limited to market volatility, technical risks, regulatory risks, operational risks, and other unforeseen risks. Users should be aware of the high risk and volatility in the market. **Risk Tolerance:** Users must confirm their ability and mental readiness to bear investment risks. Before making any purchasing decisions, it is recommended that users thoroughly assess their risk tolerance and decide whether to participate in the investment based on their situation. **Voluntary Purchase:** Users' purchasing actions should be autonomous and voluntary, without any form of coercion, misdirection, or undue influence. Users should make purchasing decisions independently after fully understanding the relevant information and risks. **Liability Statement:** Any losses incurred by users after purchasing Verifier nodes are the users’ sole responsibility. We are not responsible for investment losses due to market fluctuations, technical issues, or other factors. **Country and Region Restrictions:** According to legal regulations, Lumoz must comply with the laws and regulations of specific countries and regions. Therefore, we regret to inform you that users from the following countries and regions will not be able to participate in this purchase: **Countries and Regions Not Accepted for Purchase:** * United States * Mainland China * Hong Kong * Syria * Sudan * Myanmar * Balkans * Democratic Republic of the Congo * Libya * Somalia * Zimbabwe * Other countries and regions sanctioned by the United Nations By participating in the purchase of Verifier nodes, users indicate that they have read, understood, and agreed to the above terms, and are willing to bear all risks and responsibilities associated with the investment. # Roadmap **Q4 2024** * TGE: Token Generation Event. * The launch of the Verifier node network. * Community airdrops and staking system. \ **H1 2025** * Support for SVM(Solana Virtual Machine) for RaaS. * Support for TVM(Ton Virtual Machine) for RaaS. * The launch of more excellent L1/L2 chains, like UXLINK, CARV, DuckChain, Matr1x, Ultiverse, etc. * The launch of the Lumoz chain, along with the Compute network and the ZK-PoW mining pool. \ **H2 2025** * The Lumoz modular computing power network will provide computing power for AI agents and the training of ZK-ML models. * Support for MOVE stack chains for RaaS. * Full Support for Op Stack + ZK Fraud Proof for RaaS. * Integrate more data availability (DA) layers and execution layers. \ **2026+** * Support for seamless integration of Computer & Verifier layers into ZK\&AI apps. * Support for more rollups with Lumoz RaaS. * Interoperability between rollups launched by Lumoz. * The launch of visualized one-click deployment ZK\&AI RaaS Platform. # Utility **MOZ Token: The Core Asset of the Lumoz Protocol.** Lumoz protocol will be deployed on multiple chains, including L1 and L2 chains of ETH, Solana, Move and other ecosystems.Lumoz protocol can provide computing power and validation services for ZK and AI applications on chains with different architectures. The MOZ token is the native token of the Lumoz protocol, playing a crucial role in various key areas of the network: * All transactions conducted within the Lumoz protocol require MOZ tokens as fees. * All applycations builded within the Lumoz protocol require MOZ tokens as fees. * Utilizing the zero-knowledge proof (ZKP) computation and artificial intelligence (AI) services provided by the Lumoz network requires payment of MOZ tokens as resource usage fees. * MOZ tokens can be exchanged for esMOZ tokens at a 1:1 ratio to adapt to a wider range of application scenarios. **esMOZ Token: Symbol of Incentives and Participation.** The esMOZ token plays a significant role in the ecosystem of the Lumoz protocol: * As a reward for nodes providing computational power, security, and stability to the Lumoz protocol (including Compute and Verifier nodes), esMOZ tokens serve as recognition and retribution for participants and contributors. * esMOZ tokens are used in the network's staking mechanism, acting as tokens for participating in staking and promoting decentralized governance of the network. * esMOZ tokens can be redeemed for MOZ tokens based on different redemption periods, with the redemption rate varying according to the length of the redemption period. # Allocation & Distributions The total supply of $MOZ will be 10,000,000,000. ## Allocation

MOZ Allocation

* **Community - 6%** : Reward community users and early adopters * **Ecosystem - 10%** : Reserved for early liquidity, future marketing, hiring expenditure and expanding Lumoz ecosystem * **Contributors - 16%** : Reward team members, core contributors, protocol developers * **Investor Round 1 - 10%** : Seed round fundraising * **Investor Round 2 - 8%** : Pre-A round & strategic fundraising * **Verifier Node - 25%** : Rewards for Verifier Node Operators that provide AI & ZK verification services * **Compute Node- 25%** : Reward Compute Node that provide AI & ZK computing power

MOZ Circulating Supply

# Redemption ## Overview MOZ and esMOZ are separate tokens. $esMOZ can be redeem as MOZ under different circunstances. Upon the completion of a redemption process, one token will be burned and it's counterpart minted. ## **Redeeming MOZ for esMOZ** MOZ may be redeemed for esMOZ at any time without penalty or restriction. The ratio of conversion is always 1:1 (100%) and there is no unlock period. ## **Redeeming esMOZ for MOZ** There are two ways to convert esMOZ to MOZ. ### The unlocked option With a Lumoz OG NFT, you can convert esMOZ to MOZ instantly, with no lock-up period. Three types of Lumoz OG NFTs are available—Sly, Puff, and Claw—each allowing different amounts of esMOZ to be converted: **The Sly:** Converts 200 esMOZ to MOZ. **The Puff:** Converts 1,000 esMOZ to MOZ. **The Claw:** Converts 5,000 esMOZ to MOZ. #### How to obtain a Lumoz OG NFT ? Details on acquiring a Lumoz OG NFT will be shared on [Airdrop page](https://lumoz.org/airdrop). For the latest updates, follow Lumoz on [Twitter](https://x.com/LumozOrg),[ Telegram](https://t.me/Lumozannouncement), and [Discord](https://discord.com/invite/lumozorg). ### The locked option The redeem process to convert esMOZ to MOZ includes an unlock period, the duration of which is selected by the user. The conversion ratio will increase proportionally with the redemption duration: * The minimum redemption duration of 30 days (30 seconds in Quidditch Testnet) will provide a 1:0.25 ratio (25%). * The remaining 75% of esMOZ will be burned upon claim of the redemption. * The middle redemption duration of 90 days (90 seconds in Quidditch Testnet) will provide a 1:0.5 ratio (50%). * The remaining 50% of esMOZ will be burned upon claim of the redemption. * The maximum redemption duration of 180 days (180 seconds in Quidditch Testnet) will provide a 1:1 ratio (100%). Regarding the cancellation of esMOZ redemption: * Any esMOZ redeeming process can be freely cancelled at any time by the user. This cancellation also considers when the unlock period is over, only if the redemption has not been withdrawn. * Any canceled redemption before its end will void the whole process. Users will retrieve their entire amount of esMOZ and won't get MOZ. If users initiate another redemption attempt, they will have to start again with a new unlock period. # Contracts **License contract address** 0xed79595F9B799850f1f56210DE2c69e3C87b04db **esMOZ contract address** 0x62A5F756ED0Bd5e2556DEda17f0a22c4B78D0e44 **nodeFacNode Factory contract address** 0x46ff43385ae9BF6E131454D2F1BBe845a876353c # Technical Reference # Lumoz ZK-PoW ## Motivation Currently, there are multiple ZK-Rollups running on the Ethereum mainnet, including Polygon zkEVM and zkSync era. However, the majority of these ZK-Rollup projects have not implemented a decentralized prover. For example, in the beta mainnet of Polygon zkEVM, trusted aggregators are relied upon for submitting ZKPs, and zkSync era follows a similar approach. While centralized provers are feasible when the number of ZK-Rollups is small, with the maturation of ZK scalability technologies, especially the gradual implementation of zkEVM in the next one to two years, the number of ZK-Rollups will experience significant growth. In the case of a massive number of ZK-Rollups, centralized provers will pose several problems: * Firstly, the cost of provers is high, and maintaining a centralized prover cluster requires specialized equipment and facilities. Not every ZK-Rollup operator has the capability to maintain such a centralized prover setup. Therefore, we need professional miners to fulfill the computing power demand of the future massive ZK-Rollup ecosystem. * Secondly, if there is only one prover, a single node failure could result in the inability to confirm transactions for the entire ZK-Rollup. We need a decentralized prover mechanism to encourage multiple miners to participate in the computation of a ZKP simultaneously and receive corresponding rewards. * Lastly, we require a standardized ZKP optimization algorithm to enhance overall hardware efficiency. ## Lumoz's Solution As a highly decentralized public blockchain, Ethereum has become congested, and gas fees have become extremely expensive. Many Web3 applications, especially financial derivatives, games, social networks, and others, want to migrate to layer 2 or other public chains. Actually, providing a high-performance and low-gas execution environment alone is not difficult, as some centralized solutions can easily achieve this. The challenge lies in maintaining a high level of decentralization while ensuring high performance and low gas fees. In Lumoz's design, each Web3 application can have its dedicated ZK-Rollup and the freedom to choose a base chain. Currently, Lumoz supports four base chains: Ethereum, Lumoz, BNB Chain, and Polygon. This means developers can choose to deploy their ZK-Rollup on any of these four public chains. To support the demand for massive hardware resources resulting from a large number of ZK-Rollups, Lumoz also provides a unified ZKP computing power marketplace, encouraging miners to generate ZKPs for these ZK-Rollups. # ZKP Two-Step Submission ### Two-Step Submissioin Process Lumoz has proposed a two-step submission algorithm for ZKPs to achieve decentralized proof-of-work. This algorithm can prevent ZKP race attacks while allowing more miners to earn rewards, thereby encouraging more miners to stay online and providing stable and continuous ZKP computational power.
{% hint style="info" %} The submission epoch (the number +10 here) is adjustable according to the network's computing power {% endhint %} **Step 1: Submit hash** * After a prover calculates a ZKP for a certain sequence, it first calculates the hash of (proof / address) and submits the hash and address to the chain-level smart contract. Here, proof is a zero-knowledge proof for a certain sequence, and address is the address of the prover. * Assuming that the first prover submits the hash of the ZKP at the Tth block, it is accepted until the T+10th block without any limit. From the T+11th block, new provers cannot submit the hash anymore. **Step 2: Submit ZKP** * After the T+11th block, any prover can submit a ZKP. As long as one ZKP passes verification, it can be used to verify all the submitted hashes. Validated provers receive PoW rewards based on the ratio of miners' staked amounts. * If no ZKP passes verification before the T+20th block, all provers who have submitted hashes will be slashed. The sequence is then reopened, and new hashes can be submitted, returning to Step 1. > A simple case: > > let's assume that each block has a PoW reward of 128 MOZ on the Lumoz network, and there are currently 64 rollup slots available. Each rollup sequence is assigned a PoW reward of 2 MOZ. > > If three miners, A, B, and C, successfully submit the correct ZKP for a sequence in succession, and the three miners' miner stakes (MOZ) are 200K, 500K, and 300K, then, A, B, and C can each earn a PoW reward of 0.4 MOZ, 1 MOZ, and 0.6 MOZ, respectively. ### **Prover's token stake and punishment** To prevent malicious behavior related to provers, the Prover needs to register in a special system contract and stake tokens. If the prover commits the following actions, different levels of punishment will be applied: * The prover submits an incorrect hash. * For a certain sequence, if no corresponding ZKP passes verification, all provers who have submitted hashes will be punished. The slashed token will be burned. ### Considerations **Why allow multiple provers to submit hashes?** * If only the first prover to submit a hash is rewarded, other provers may not have an incentive to submit a proof after the first prover submits a hash. * If a malicious attacker delays submitting the proof for a long time after submitting a hash, it may slow down the verification of the entire sequence. Therefore, it is necessary to allow multiple provers to independently and simultaneously submit hashes to avoid monopoly of ZKP verification by a single attacker. **Why is there a time window (submission epoch)?** * If anyone can submit a proof immediately after submitting a hash, the proof may still be stoled. Attackers can immediately submit a hash associated with their address and then submit a proof to earn rewards. By setting a time window, provers who have submitted hashes have no incentive to submit proofs within the window, thereby avoiding the possibility of being raced. **Why is the reward allocated based on stake?** * Multiple provers can submit hashes for the same sequence within a time window. In fact, miners can submit multiple hashes using their generated proof (only needs multiple addresses). This can lead to the majority or even all of the PoW rewards being taken by several miners. To avoid this attack, the reward for a sequence will be allocated based on the ratio of miner's stake amount. # Cross-Rollup Communication ## Motivation Rollups have gained significant attention and adoption for their ability to enhance blockchain scalability, reduce transaction costs, and improve overall efficiency. Lumoz provides ZK-RaaS services for Web3 applications, enabling developers to create their own Rollups through the Lumoz Rollup Launchbase. In this era of multiple Rollups, we anticipate a growing coexistence of various Rollups, making seamless interoperability between different Layer 2 solutions crucial. Currently, interactions between Rollups remain relatively isolated, lacking real-time cross-chain communication and asset interoperability. This isolation has led to a fragmented landscape, where assets are confined within specific Rollups, restricting their free flow and utilization across different networks. The absence of efficient cross Rollup communication not only limits the potential of individual Rollups but also impacts the overall user experience. Users attempting to transfer assets or execute cross-chain transactions between Rollups face cumbersome and time-consuming processes. This suboptimal experience weakens the appeal of Rollups and to some extent hinders the widespread adoption of Layer 2 scaling solutions. Existing cross Rollup bridging solutions often involve deploying new sets of interchain contracts on Rollup chains and utilizing multi-chain liquidity incentives to achieve asset cross-chain functionality. However, these solutions are not universally applicable for message-based cross-chain interactions and come with risks of centralization and trust. To fully unlock the potential of the multi Rollup era, there is an urgent need for a trustless and universal cross Rollup communication protocol. ## Lumoz's Solution In fact, each ZK-Rollup comes with an L1<>L2 bridge inherently, which we refer to as the Native bridge. Unlike third-party bridges that utilize liquidity-based schemes, the Native bridge operates as the unique "mint-burn" cross-chain mechanism. It ensures security through zero-knowledge proofs while maintaining trustlessness. All assets on a Rollup originate from deposit transactions through the native bridge and receive ultimate security endorsement from it. We firmly believe in the principle of Occam's Razor – "Entities are not to be multiplied beyond necessity." Third-party bridges may offer cheaper and faster cross-chain experiences, but they introduce additional trust costs and security risks. The recent Multichain incident is a case in point. Therefore, **from the outset, Lumoz's inspiration for cross-Rollup communication was elegantly straightforward: leverage the native bridge directly for achieving multi-Rollup interoperability, rather than introducing an additional third-party bridge**. This concept gave birth to the NCRC (Native Cross Rollup Communication) protocol. # Prerequisits and Compatibility ### NCRC Prerequisites To enable NCRC among multiple Rollups, the following two prerequisites need to be met: * These Rollups must belong to the ZK-Rollup type. * These Rollups must reside on the same L1. Rollups satisfying these two conditions theoretically possess the same level of security as the underlying L1. Similarly, the security level of the native bridge among these Rollups is identical and requires no trust between them. All NCRC transactions are verified by validity proofs, serving as the fundamental source of security assurance for NCRC. ### Rollup Recognition Contract (RRC) As of August 2023, several ZK-Rollups have gone live on the mainnet, including Polygon zkEVM, zkSync era, Linea, and more. However, these ZK-Rollups are independent and unrelated, leading to fragmentation of user assets. The fundamental reason for this issue lies in the fact that their contracts on L1 (Ethereum mainnet) are unrelated. They remain unaware of each other's existence and are unable to directly communicate through native Rollup bridges. Therefore, the first step we need to take is deploying a specialized contract on L1 to enable Rollups to discover and recognize each other. This is referred to as the RRC (Rollup Recognition Contract). The RRC is responsible for managing all participating ZK-Rollups in the NCRC, including additions, pauses, and exits of Rollups. Each Rollup within the RRC is assigned a dedicated Rollup ID, while the ID for L1 remains fixed at 0. When initiating cross-Rollup transactions through the native bridge on a Rollup, addresses can specify the target Rollup ID: * If the Rollup ID is 0, it signifies crossing the message to L1, such as withdrawal. * If the Rollup ID is not 0, it indicates sending the message to another Rollup. Lumoz will deploy an RRC contract on every L1 layer and allow corresponding ZK-Rollups to join or exit without permission. This RRC contract will be used to maintain information for each Rollup ID, including the bridge contract address on L1. It's important to note that the RRC contract solely provides data retrieval services and does not directly interact with cross-chain assets. ### Compatibility with Native Bridge Smart Contracts and Services Generally, Rollup's native bridge is divided into three components: the bridge contract on L1, the bridge contract on L2, and a bridge service responsible for message relay. The NCRC protocol leverages these components at the underlying level and adds higher-level encapsulation. The main modifications are as follows: * Bridge contract on L2: While preserving the original methods, a new method named bridgeAsset is added. This method allows users to specify the target Rollup's ID in the destinationNetwork parameter. * Bridge contract on L1: A new method is encapsulated to handle the cross-chain messages of the new bridgeAsset method. The bridge contract, based on the Rollup ID found in the RRC contract, locates the information of the target Rollup and transfers the cross-chain assets to the bridge contract of the target Rollup. The cross-chain assets are deposited into the target Rollup there. * Bridge service: Responsible for message relay and charges users fees for cross-Rollup transactions. Once a Rollup completes the NCRC-related compatibility adaptation mentioned above, it can register with the RRC to join the native cross-Rollup communication network. # Process of Native Cross-Rollup Transactions For users, the operation of NCRC is entirely consistent with that of Rollup's native bridge. Initiating a cross-Rollup transaction from Rollup1 to Rollup2 is an automated process, including the following steps: 1. The initiator, User1, on Rollup1, invokes the bridgeAsset method of the native bridge to initiate the cross-chain transaction. The `destinationNetwork` parameter in this transaction is set to the Rollup ID of Rollup2. This Rollup ID will be used to retrieve the corresponding L1 bridge contract address. If the Rollup ID is 0, it signifies the target network as L1. 2. Subsequently, this transaction is packaged by Sequencer1 of Rollup1. The initiator, User1, bears the cost of the cross-Rollup transaction, paying it to Sequencer1 on Rollup1. Rollup1's Bridge service then transfers the cross-chain asset to the Rollup1 bridge contract on L1. At this point, both Rollup1 and L1 complete the burn and release operations of the asset. 3. To complete the cross-Rollup asset transfer, Rollup1's Bridge service queries the RRC contract to retrieve information about the target Rollup2 corresponding to the `destinationNetwork` parameter. This information provides the L1 bridge contract address of Rollup2. Then, the bridge contract of Rollup2 takes control of these assets and maps them to Rollup2 through the `bridgeAsset` method. 4. Finally, once the transaction is successfully packaged and the proof is generated, Rollup2's Bridge service executes the `claimAsset` operation. Consequently, the cross-chain assets initiated by Rollup1 safely arrive at the designated address on Rollup2. {% hint style="info" %} It's worth mentioning that throughout the cross-chain process, the user's assets flow through the following path: Rollup1 -> Rollup1's L1 bridge contract -> Rollup2's L1 bridge contract -> Rollup2. In other words, the user's assets do not go through any third-party protocol; they leverage Rollup's native bridge. The entire process is **secure** and **trustless**. {% endhint %}
When users execute cross-chain operations on Rollup1, selecting Rollup2 as the destination, the technical process actually involves three entities: Rollup1, L1, and Rollup2. However, users do not need to be aware of the existence of L1 in this process; their experience is simply a direct cross from Rollup1 to Rollup2. The underlying reality is that cross-chain assets undergo two bridging operations on L1, creating a seamless connection from Rollup1 to Rollup2 in the user's perception. During this process, operations on L1 are handled automatically, and users do not need to perform any additional actions. From the user's perspective, their current Rollup can perform cross-chain operations to both L1 and any other Rollup. This design enhances user experience fluidity while concealing underlying complexities. # Glossary ## A
Application-specific rollup Application-specific rollup is a proprietary rollup that typically serves only one application. Developers can focus solely on the application rather than deploying the chain. In addition to bringing excellent user experience to the application, certain special capabilities can be customized, such as Opside's ability to provide 0 gas for the application.
## B
Block An ordered list of [transactions](#transaction) and chain-related metadata that gets bundled together and published to the [DA](#data-availability) layer. [Nodes](#node) execute the transactions contained within blocks to change the [rollup](#rollup) chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over.
Batch Execution layer sequencers gather executed transaction related data and store it on the base layers for security. The frequency of data batching is decided by the Sequencer but may be enforced by the underlying protocol.
## C
Client Sometimes labelled interchangeably as a “[node](#node)”, they are tasked with processing transactions and managing the [rollup](#rollup)’s state. They run the computations for each transaction according to the rollup’s virtual machine and protocol rules. If comparing to Ethereum clients, these would be execution clients such as Geth, as opposed to [consensus](#consensus) clients.
Consensus An agreement on the latest and correct state of a blockchain. Unlike L1 blockchains which coordinate participating [nodes](#node) with consensus rules, [rollups](#rollup) rely on L1s for reaching consensus by checking the state of the rollup smart contract deployed thereon.
## D
Deposit Contract A smart contract deployed on L1, you can think of the deposit contract as a transfer of funds from an Opside account to a proof-of-stake validator account.It specifies who is staking, who is validating, how much is being staked, and who can withdraw the funds.
Data Availability The block proposer must publish all of the data and anyone would be able to detect transactions.
## E
Epoch **1 Epoch = 32** [**Slots**](#slot)\ Represents the number of 32 [slots](#slot) and takes approximately **6.4 minutes.**
## F
Fraud Proof Fraud proofs indicate that a state transitions was invalid. This is proven by replaying the transaction which caused the state transition onchain and comparing the resulting state root with the one that was published by the sequencer. If the state roots do not match, then the fraud proof is successful and the state transition is cancelled.
## M
Miner Miner is an actor who participates in cryptocurrency transactions, and in turn, plays a crucial role both in creating new cryptocurrencies and in verifying transactions on the blockchain. It adds new blocks to the existing chain, and ensures that these additions are accurate. To Opside, miner is an actor who submits the ZKP (Zero-Knowledge-Proof) to L1 layer.
## N
Node A software [client](#client) that participates in the network.
## O
Optimistic rollup A [rollup](#rollup) that optimistically updates state with the possibility of [fraud proofs](#fraud-proof) being generated to revert faulty state transitions. Optimistic rollups have primarily been EVM-compatible to date. Compared to [ZK-Rollups](#zk-rollup), they have longer time to finality as there is a time window (challenge period) during which anyone can challenge the results of a rollup transaction by computing a fraud proof.
## P
Prover An entity that generates the cryptographic proof to convince the verifier that the statement is true (without revealing its inputs). In a [ZK-Rollup](#zk-rollup), the prover generates the [ZK (validity) proof](#validity-proof) to submit to the verifier contract. If used in the context of an [optimistic rollup](#optimistic-rollup), the prover generates the [fraud proof](#fraud-proof) to show that an incorrect state was submitted.
## R
Rollup Rollups are one of several scaling systems, which are simply methods to make a slow blockchain faster and cheaper.
RaaS An SDK or service that allows anyone to launch [rollups](#rollup) quickly.
## S
Slash Slashing has two purposes: (1) to make it prohibitively expensive to attack the network, and (2) to stop validators from being lazy by checking that they actually perform their duties. If you're slashed because you've acted in a provably destructive manner, a portion of your stake will be destroyed. If you're slashed you're prevented from participating in the protocol further and are forcibly exited.
Slot **32 Slots = 1** [**Epoch**](#epoch) A time period of **12 seconds** in which a randomly chosen validator has time to propose a block. Each slot may or may not have a block in it. The total number of validators is split up in committees and one or more individual committees are responsible to attest to each slot. One validator from the committee will be chosen to be the aggregator, while the other 127 validators are attesting. After each [Epoch](#epoch), the validators are mixed and merged to new committees.\ There is a minimum of 128 validators per committee.
Sequencer A party responsible for ordering and executing transactions on the [rollup](#rollup). The sequencer verifies transactions, compresses the data into a [block](#block), and submits the batch to Opside L1 as a single transaction.
## V
Validator A [node](#node) in a blockchain system responsible for processing transactions, and adding or verifying new [blocks](#block) to the blockchain.
Validator Key As seen in the cutout below the validator signing key consists of two elements: * Validator **private** key * Validator **public** key The purpose of the **validator private key** is to **actively** sign on-chain (ETH2) operations such as block proposals and attestations. Therefore these keys have to be held in a hot wallet. The **validator public key** is included in the *deposit data* which allows ETH2 to identify the validator.
Validity proof The output of a cryptographic proving system attesting to correct computation. [ZK-Rollups](#zk-rollup) use succinct validity proofs (also called zero-knowledge proofs) to prove a batch of rollup transactions and [blocks](#block) were properly executed. Validity proofs are submitted to a verifier, such as an Ethereum smart contract, which accepts them if properly constructed.
## W
Withdraw Credencial Withdrawal Credentials is a 32-byte field in the deposit, for verifying the destination of valid withdrawals. Currently, there are two types of withdrawals: BLS withdrawal and Opside address withdrawal. 1. BLS withdrawal: By default, the deposit-cli would generate withdrawal credentials with the **withdrawal key** derived via mnemonics in [EIP2334](https://eips.ethereum.org/EIPS/eip-2334) format. 2. Opside address withdrawal: If you want to withdraw to your execution wallet address after the Shanghai/Capella upgrade, you can set `--opside_withdrawal_address ` when running deposit-cli. **Please ensure that you have control over the keys to this address.**
## Z
ZK-Rollup A [rollup](#rollup) that uses ZKPs (also often called [validity proofs](#validity-proof) to validate the correctness of the state transition function and update the rollup state. This is one of two main types of rollup constructions, along with [optimistic rollups](#optimistic-rollup). In general, ZK-Rollups do not provide privacy preserving properties; privacy preserving ZK-Rollups are sometimes called ZK-ZK-Rollups.
# Resources #### Lumoz Website: #### Lumoz Docs: [https://docs.lumoz.org/](https://docs.opside.network/) #### Lumoz Github: #### Lumoz Blogs： #### Lumoz Twitter: #### Lumoz Discord: