# HashCloud (HCLD) Amplify your mining power through staked computation. HashCloud (HCLD) is pioneering the next generation of decentralized infrastructure by transforming idle GPU power into a productive, utility-driven compute economy. Rather than wasting energy on arbitrary hash puzzles like traditional Proof-of-Work, HCLD introduces a **Proof-of-Compute** model where every computation performed by miners serves a verifiable and meaningful purpose. #### **A New Era of Mining Has Begun** We are entering a world where compute is the new gold. Artificial Intelligence (AI), Zero-Knowledge (ZK) cryptography, and scientific research all require massive amounts of parallel processing power. However, today’s compute infrastructure is highly centralized controlled by cloud monopolies and large data centers that dictate pricing, access, and availability. HCLD **is changing that.**\ Our protocol empowers everyday GPU owners to participate in the global compute revolution earning rewards not just for mining, but for powering the future of AI, cryptography, and decentralized infrastructure. *** ### **Our Vision: GPUs Powering the Future** HCLD’s mission is to democratize access to high-performance computing. By transforming GPUs into decentralized compute nodes, we are building the foundation for a permissionless network that can support: * **AI model inference and training** * **ZK-rollup proof generation for scaling blockchains** * **Scientific and engineering simulations** * **Decentralized cloud rendering and 3D compute tasks** We envision a world where **millions of GPUs across homes, offices, studios, and gaming rigs** contribute to a shared compute economy secured by cryptographic proofs and rewarded with HCLD tokens. *** ### **The Problem** HCLD **Solves** Today’s crypto mining is fundamentally inefficient and increasingly centralized: * **Traditional PoW is dominated by ASIC hardware**, which is expensive, non-recyclable, and controlled by a small group of manufacturers. * **Energy is wasted on arbitrary hashes**, providing no real-world utility beyond securing the blockchain. * **Most crypto networks are VC-controlled**, launching tokens with pre-mines, insider allocations, and unequal access. As a result: * Retail miners are being **priced out and excluded**. * Token economies are often **inflationary and unsustainable**. * Blockchain infrastructure does **not contribute meaningful compute capacity to society**. *** ### HCLD**’s Breakthrough Solution** HCLD introduces a compute-mining paradigm built for fairness, performance, and real-world utility: * ✅ **GPU-first protocol** with built-in hardware fairness and anti-centralization measures * ✅ **No VC pre-mine, no unfair private allocation** – mining is the primary distribution method * ✅ **Staking is used only to unlock compute multipliers and GPU slots**, not to generate passive yield * ✅ **Deterministic matrix computations provide verifiable work**, usable for AI and ZK applications * ✅ **Every GPU cycle contributes toward decentralized compute, not wasteful hashes** *** #### 🔥 *In short, HCLD is not just another mining network it is the foundation of a decentralized supercomputer powered by the people, for the future.* #### **How** HCLD **Works: The Evolution Beyond PoW and PoS** Traditional mining uses raw energy to solve meaningless cryptographic puzzles, while Proof-of-Stake relies on token holdings centralizing power among early investors and institutions. HCLD **introduces a third paradigm: Proof-of-Compute (PoC)**, where mining is based on executing real, deterministic computational workloads using GPU hardware. These workloads are: * **Mathematically verifiable** * **Resource-intensive (proving real work)** * **Useful for real-world AI, ZK, and compute tasks** * **Impossible to fake due to hardware identity validation** Instead of wasting energy, each GPU performs **matrix multiplications and linear algebra operations** that simulate real computing applications. Once completed, the miner submits a cryptographic proof of computation. The network then validates the result, measures performance, and distributes HCLD tokens according to real compute power not token wealth or hash guessing luck. *** ### **Why GPU-Based Proof-of-Compute Is Superior** | Feature | Proof-of-Work (PoW) | Proof-of-Stake (PoS) | **Proof-of-Compute (**HCLD**)** | | ------------------ | ----------------------- | ------------------------------------- | ----------------------------------------- | | Reward Based On | Hash power | Token holdings | Actual GPU computing performance | | Hardware Access | Dominated by ASICs | Favorable to wealthy stakers | Accessible to everyday GPU owners | | Energy Use | Wasted on random hashes | Minimal | Used for real, useful computation | | Decentralization | Declining | Minimal | Designed to maximize miner participation | | Real-World Utility | ❌ None | ❌ None | ✅ Yes – AI, ZK, computing workloads | | Entry Barrier | High (ASIC costs) | Very high (token staking requirement) | Low – any GPU can participate | #### Core Benefits of HCLD’s Proof-of-Compute Protocol: * 🔹 **Fair:** GPU validation prevents centralization by ASIC or stake whales * 🔹 **Efficient:** Every joule of energy provides real value to the compute network * 🔹 **Scalable:** Adaptive difficulty ensures that both low-end and high-end GPUs are competitive * 🔹 **Future-Proof:** Matrix operations can be extended into real compute services for AI and Web3 *** #### **A Mining System Designed for Human Miners** Instead of rewarding the wealthiest token holders or industrial ASIC factories, HCLD rewards genuine GPU compute power. Whether you are a gamer with a single GPU or a data center operator, your rewards scale based on actual performance **not speculation or network influence**. This ensures long-term sustainability and true miner-first economics. *** # The Core Innovation of HCLD: Deterministic Computation & Verifiable Proofs At the heart of HashCloud lies a breakthrough concept: **deterministic GPU computation that is cryptographically verifiable.** Unlike traditional PoW hashing or arbitrary GPU workloads, HCLD ensures that **every computation can be reproduced, validated, and verified with mathematical certainty.** #### 🔷 **How It Works** 1. **Challenge Issuance** * The network sends a miner a deterministic matrix challenge. * The challenge is generated using a cryptographic seed tied to the miner’s hardware identity, wallet address, and timestamp. 2. **GPU-Based Matrix Computation** * The miner’s GPU performs matrix multiplication operations. * These operations are intensive enough to prove real work, but structured for deterministic output. 3. **Result Hashing** * The output matrix is hashed using SHA-256 or another secure hashing standard. * This prevents pre-computation and ensures the miner must complete the work. 4. **Proof Submission** * The miner submits the matrix size, computation time, and result hash as a proof-of-compute. * No raw matrix data is required only the hash, making validation extremely efficient. 5. **Network Verification** * The network recalculates the expected hash from the same deterministic challenge. * If the hash matches, the proof is valid, and the miner’s performance score is recorded. *** #### ✅ **Why Deterministic Compute Is Revolutionary** | Advantage | Description | | -------------------------------- | ------------------------------------------------------------------------------------------------------- | | **100% Verifiable** | Every result can be recreated using the same challenge, ensuring there is no cheating. | | **No ASIC Advantage** | The tasks are optimized for GPUs and memory bandwidth, making ASIC dominance impractical. | | **Useful Computation** | These matrix operations can be directly extended to AI inference, ZK provers, and scientific computing. | | **No Guesswork** | Unlike PoW, there is no “luck.” Rewards are purely performance-driven. | | **Anti-Spoof Hardware Security** | GPU UUIDs and VRAM validation ensure miners cannot fake hardware. | *** #### 🔬 **The Mathematical Basis** The deterministic compute process revolves around performing: C=A×BC = A \times BC=A×B Where matrices **A** and **B** are generated using the secure seed: $$\text{seed} = \text{SHA-256}(\text{wallet} + \text{gpu\_id} + \text{timestamp} + \text{loop\_index})$$ This guarantees: * Every miner receives a unique challenge * Every challenge is reproducible * Any deviation from the correct computation results in invalid proof *** #### 🔒 HCLD **Ensures:** * **No shortcutting:** Miners must execute the compute workload fully. * **No duplication:** Challenges are time-bound and cannot be reused. * **No fake GPUs:** Hardware identity is bound cryptographically to the challenge. *** 🔥 **Proof-of-Compute transforms mining from random hash guessing into a deterministic compute race where every GPU cycle has purpose and earns fair rewards.** # Abstract HashCloud (HCLD) introduces a breakthrough Proof-of-Compute (PoC) protocol that transforms GPU mining from wasteful hashing into verifiable, mathematically useful computation. Unlike traditional Proof-of-Work systems that rely on arbitrary hashing and centralized ASIC dominance, HCLD leverages deterministic matrix operations to create a fair, decentralized, and purpose-driven token distribution mechanism. HCLD serves as a GPU-powered compute network where token issuance is not based on speculation or staking yield, but on real computational work performed by miners. This aligns economic incentives around useful compute, ensuring long-term sustainability and real-world utility. ### Core Innovations of HCLD * **Useful GPU Computation:** Miners perform deterministic linear algebra workloads (matrix multiplications) that can be extended to AI, ZK proofs, and scientific computing. * **Performance-Based Rewards:** Token emissions are distributed proportionally to compute output, using a transparent formula based on matrix size and execution time. * **Fair Staking Mechanism (VIP Scaling):** Staking does not generate passive rewards it unlocks GPU slots and multipliers to maintain fairness and prevent hardware monopolization. * **Hybrid Architecture:** Off-chain deterministic computation is combined with on-chain verification and staking contracts, providing efficiency, trustlessness, and scalability. ### Why HCLD Matters HashCloud restores the original ethos of decentralization by enabling any GPU owner to become a meaningful participant in token issuance. It eliminates ASIC centralization, removes VC control, and ensures tokens are earned not allocated. HCLD **is more than a mining protocol; it is the foundation of a future decentralized supercomputing network where GPU compute becomes the backbone of Web3 infrastructure. By aligning economic incentives with real computational work,** HCLD **ensures long-term token value stability, broad miner participation, and continuous expansion into high-demand sectors such as AI inference, decentralized rendering, ZK-proof generation, and scientific research. This creates a self-sustaining ecosystem where every token issued represents verifiable compute power delivered to the network bridging blockchain technology with real-world utility at global scale.**
#### **Vision Statement** HCLD envisions a world where decentralized computation surpasses traditional cloud services in scale, accessibility, and efficiency. By empowering millions of GPU owners to contribute to a unified compute layer, HCLD will become the backbone for next-generation digital infrastructure spanning AI, Web3, and scientific innovation. ### Mission Declaration Our mission is to democratize access to high-performance computing, eliminate centralized control over computational resources, and create a fair economic model where every participant earns based on verifiable contribution not financial privilege. HCLD is committed to building a future where compute power is permissionless, borderless, and owned by the people. # Introduction HashCloud (HCLD) redefines the very concept of blockchain mining by shifting from purposeless computational waste to a high-utility, performance-based compute economy. In traditional Proof-of-Work systems, miners expend massive amounts of electrical energy solving arbitrary puzzles that hold no value outside of network security. HCLD transforms this paradigm by enabling miners to perform deterministic matrix computations calculations that not only secure the network, but also form the foundational operations used in artificial intelligence (AI), zero-knowledge (ZK) cryptography, physics simulations, engineering modeling, and other real-world computational workloads. Unlike Proof-of-Stake systems, where token ownership dictates control and reward distribution, HCLD places computation not capital at the center of the network. Performance is determined by measurable GPU output rather than luck or wealth. Every mining cycle becomes a verifiable contribution to a decentralized compute fabric designed to scale across millions of GPUs worldwide. This positions HCLD as the first protocol to merge the economic power of mining with the utility of a decentralized AI and compute marketplace. HCLD establishes a permissionless, trustless environment where anyone with a GPU whether a home miner, gamer, content creator, AI developer, or enterprise can participate in global token issuance. The protocol is built with embedded fairness principles designed to prevent centralization through ASICs or staking monopolies. Staking within HCLD does not generate passive income or inflationary yield; instead, it enables miners to access additional GPU slots and performance multipliers in a manner that scales linearly with actual compute power. This ensures that HCLD’s economic incentives always remain aligned with genuine network contribution. By harnessing deterministic computation, HCLD introduces a mining methodology that is mathematically provable, cryptographically secure, economically fair, and infinitely scalable. The protocol not only restores the original decentralized ethos of mining it extends it into a new era where every second of GPU power fuels a global, utility-driven compute economy. Through this approach, HCLD establishes itself as the foundational infrastructure for AI-driven blockchain applications, decentralized cloud rendering, and ZK-powered privacy systems, positioning it as a pivotal force in the evolution of Web3. ### Key Objectives * **Revolutionize Mining with Real-World Utility:** Replace arbitrary hashing with deterministic computation that can be directly applied to AI and cryptographic workloads. * **Eliminate Centralization Risks:** Ensure that consumer GPUs remain viable participants without being displaced by industrial ASIC operations or staking wealth concentration. * **Guarantee Verifiable Output:** Use performance scoring based on matrix size, compute time, and deterministic output hashing to ensure transparent and tamper-proof validation. * **Enable Global Participation:** Provide frictionless access for miners across operating systems, GPU types, and geographic regions. * **Establish a Compute Economy:** Lay the economic framework for HCLD tokens to evolve from mining rewards into the native currency of a global decentralized compute layer. HCLD is not merely an improvement upon existing mining systems it represents a fundamental evolution. By transforming GPU performance into economic value with real-world impact, HCLD bridges the gap between decentralized finance, artificial intelligence infrastructure, and the future of permissionless compute networks. # Architecture Overview ### **System Design Philosophy** HashCloud (HCLD) is built around a **hybrid compute-verification architecture** that balances the performance of off-chain GPU computation with the security of on-chain accountability.\ The protocol ensures that every computation task is both **deterministic** and **verifiable**, allowing miners to contribute real GPU power while the network maintains trustless validation and transparent reward distribution. HCLD’s architecture emphasizes three foundational goals: 1. **Utility:** Every computation contributes to meaningful and reproducible mathematical work. 2. **Fairness:** Rewards and slot access are determined by measurable performance, not capital ownership. 3. **Security:** Results are cryptographically verifiable, resistant to spoofing, and anchored by identity-bound GPU signatures. ### **Core Components** #### **1. Miner Client (**HCLD**-CLI)** * The **command-line interface** serves as the miner’s primary node agent. * It manages GPU registration, challenge requests, computation execution, and proof submission. * Includes built-in diagnostics (`hcld-cli diagnose`) and benchmarking modules for performance tuning. **Responsibilities:** * Detect available GPUs and gather hardware metadata (UUID, VRAM, compute capacity). * Retrieve assigned matrix computation challenges. * Execute matrix operations deterministically (e.g., multiplication, inversion, eigenvalue tests). * Generate proof packages containing result hashes and performance signatures. * Submit proofs to the backend for validation. #### **Backend Verification Layer** * The backend serves as the **verification and orchestration layer** for all computational proofs. * It receives results from miners, validates computation integrity, and records verified performance data. **Core Functions:** * **Challenge Distribution:** Issues deterministic matrix problems tied to specific time intervals and difficulty weights. * **Proof Verification:** Confirms the mathematical correctness of returned results and validates authenticity. * **Performance Scoring:** Normalizes computational throughput based on hardware class and task duration. * **Reward Scheduling:** Updates miner accounts and prepares reward snapshots for daily distribution. #### **On-Chain Settlement Layer** * The blockchain component manages **staking, slot registration, and token issuance**. * It does not perform the heavy computation itself instead, it maintains trustless state transitions linked to verified backend data. **Responsibilities:** * Register verified miners via wallet authentication. * Apply **VIP-tier multipliers** based on non-reward staking. * Distribute HCLD tokens proportionally to verified compute contributions. * Store an immutable record of all mining epochs and emissions. ### **Data Flow Overview** The data pipeline between miner and network can be summarized as follows: 1. **Challenge Assignment**\ The backend sends a time-bound deterministic matrix challenge to each registered miner. 2. **Compute Execution**\ The miner’s GPU performs the assigned matrix operations locally via the HCLD-CLI. 3. **Proof Creation**\ The miner hashes the computation output and attaches a performance signature (including GPU ID, runtime, and checksum). 4. **Verification**\ The backend cross-verifies the hash against the expected mathematical outcome and validates authenticity. 5. **Reward Settlement**\ The verified performance score is written to the on-chain ledger and tokens are distributed based on relative compute output. ### **Security and Validation** HCLDintegrates multiple cryptographic and hardware-level safeguards: * **Deterministic Task Seeds:** Ensures that all challenges are reproducible and consistent across miner environments. * **GPU Identity Hashing:** Prevents GPU spoofing and duplicate submissions. * **Proof Nonce and Timestamp:** Protects against replay attacks. * **Challenge Expiration Windows:** Ensures real-time computation integrity. * **Cross-Verification Pools:** Periodically recheck submitted proofs through redundancy sampling. These mechanisms guarantee that computational trust is earned not simulated maintaining network integrity even under decentralized participation. ### **Architectural Advantages** | **Feature** | **Benefit** | | --------------------------------- | --------------------------------------------------------------------------------- | | Hybrid compute-verification model | High performance off-chain, with trustless on-chain settlement | | Deterministic computation | Fully reproducible and mathematically verifiable tasks | | Hardware-linked miner identity | Prevents spoofing and ensures fairness | | Modular scalability | Easily extendable to future compute workloads (AI, ZK, or scientific simulations) | | Transparent performance scoring | Open benchmark-based miner ranking system | ### **Summary** The HashCloud architecture bridges raw GPU performance with blockchain verifiability.\ Through its modular compute engine, secure verification backend, and transparent on-chain distribution layer, HCLD achieves a new equilibrium one where **decentralized mining produces useful results** while maintaining the trustless incentives that make Proof-of-Work resilient. This architecture establishes the foundation for the next-generation **Proof-of-Compute economy**, where computational labor translates directly into both token value and practical utility. ### **Treasury and Sustainability** A percentage of each daily emission (e.g., 5 %) is allocated to the HCLD **Treasury**, governed by the community.\ Treasury funds support: * Development bounties and protocol audits * Research grants for GPU optimization and AI/ZK modules * Liquidity incentives and exchange integration * Community rewards and educational initiatives **Treasury Operations Cycle** ``` Proposal → Voting → Fund Release → Audit Report ``` This closed-loop ensures continual reinvestment into protocol innovation and miner empowerment. ### **Long-Term Utility and Ecosystem Growth** Over time, HCLD tokens evolve from mining rewards into a **multi-purpose digital commodity** supporting the entire Proof-of-Compute ecosystem: * **Cross-Protocol Compute Leasing:** Third-party AI or ZK projects rent verified HCLD GPU capacity using HCLD tokens. * **Marketplace Integration:** Token-based settlements for compute, software modules, and data services. * **Reputation-Linked Identity:** Long-term miners build verifiable reputations, improving job matching in decentralized compute markets. * **Governance Expansion:** DAO extends beyond HCLD to influence allied decentralized infrastructure projects. HCLD thus matures into a **self-sustaining computational economy** one in which every participant, from hobbyist miner to enterprise partner, shares governance responsibility and tangible network value. ### **Summary** Governance and utility are the connective tissue of HashCloud.\ Through its DAO-driven structure, utility-anchored token, and transparent treasury, HCLD transforms mining from a competitive hash race into a collaborative, economically sustainable digital ecosystem.\ The result is a **truly decentralized compute governance model** where computation, community, and capital move together toward the same goal: scaling useful work for the decentralized future. # System Architecture ### **Overview** The HashCloud **System Architecture** is designed around a **hybrid computation model**, combining high-efficiency off-chain GPU processing with secure on-chain validation and reward settlement. This model allows the network to scale compute performance linearly while retaining full transparency, traceability, and verifiability of miner contributions. Through modular layering, HashCloud achieves both **operational speed** and **decentralized trust**, allowing the network to manage thousands of active GPU nodes without burdening the blockchain with raw computational data. ### **Core Components** The architecture is composed of four interlinked components, each responsible for a critical stage of the compute lifecycle: 1. **Miner CLI:** * Handles GPU-based matrix computations locally on the miner’s hardware. * Receives deterministic challenge data from the Backend API. * Generates cryptographic proofs of computation integrity before submission. 2. **Backend API:** * Acts as the network’s coordination layer. * Issues computation challenges, collects proofs, and performs off-chain verification. * Ensures fairness by matching tasks to GPU profiles and monitoring network-wide performance balance. 3. **Performance Database:** * Stores validated performance metrics, miner history, and ranking data. * Functions as the source of truth for reward calculation and transparency. * Includes safeguards against spoofing or duplicate proof submissions. 4. **Reward Engine:** * Calculates daily HCLD distributions proportionally to verified compute output. * Applies VIP multipliers, normalization coefficients, and difficulty scaling. * Communicates with the on-chain contract for final settlement. Together, these components ensure a seamless loop of **Compute → Verification → Reward**, forming the computational backbone of the HashCloud ecosystem. ### Architecture Summary #### **Process Flow** ``` 1. Local Compute → 2. Proof Submission → 3. Backend Verification → 4. Reward Calculation → 5. On-Chain Settlement ``` {% stepper %} {% step %} ### Miners compute locally Miners run the **AmplifyMiner CLI**, which performs deterministic matrix multiplications and hashing operations. This off-chain process maximizes computational efficiency and leverages the full potential of the GPU. {% endstep %} {% step %} ### Submit proofs Upon completing a task, miners generate a cryptographic proof and submit it via the **Backend API**.\ Each proof includes hash outputs, timestamps, and device metadata for verification. {% endstep %} {% step %} ### Backend verifies The **Backend API** verifies proofs by cross-checking computation results and validating timing integrity.\ Invalid or tampered proofs are automatically rejected to preserve network reliability. {% endstep %} {% step %} ### Rewards calculated Verified performance data is recorded in the **Performance Database**, where the **Reward Engine** determines each miner’s proportional share of daily emissions using the established reward formula. {% endstep %} {% step %} ### On-chain settlement The on-chain contract finalizes payouts, ensuring transparent, traceable reward distribution.\ This hybrid approach minimizes blockchain congestion while maintaining full auditability of all token flows, {% endstep %} {% endstepper %} ### **Security and Integrity Mechanisms** To protect against manipulation and false submissions, HashCloud integrates multiple integrity layers: * **Cryptographic Proof Validation:** Each result is derived deterministically, ensuring verifiable reproducibility. * **Hardware Fingerprinting:** GPU UUIDs and performance profiles are recorded to prevent hardware spoofing. * **Rate Limiting:** The backend enforces proof submission limits to block spam or fraudulent activity. * **Consensus Integrity:** Final reward settlements are validated through the on-chain governance contract, ensuring no centralized alteration. This security framework guarantees that only *authentic compute work* performed by verified GPUs translates into HCLD rewards. ### **Architectural Advantages** * **Scalable Efficiency:** Off-chain GPU processing eliminates the computational limits of traditional blockchain mining. * **Transparent Verification:** On-chain settlement ensures full accountability and immutable recordkeeping. * **Energy Optimization:** Tasks produce useful computational output rather than arbitrary hashing. * **Fair Competition:** Integrated VIP and difficulty systems maintain balance across varied GPU tiers. The result is a next-generation hybrid architecture blending the *speed of off-chain computation* with the *trust of blockchain validation.* # HashCloud System Architecture ### Overview This document explains the high-level architecture of the HashCloud mining platform, including the Staking Contract, Backend Server, and Miner CLI interactions. *** ### 🧩 System Components #### **1. Staking Contract (On-Chain Smart Contract)** * Controls **14-day reward cycle**. * Issues a new **poolId** at the start of each cycle. * Stores **user tiers** (VIP0 to VIP4). * Provides **multiplier values** based on user tier. * Source of truth for: * `activePoolId` * `user tier` **Used by:** Backend server and Miner CLI to read current `activePoolId` and tier multipliers. *** #### **2. Backend Server** * Subscribes to events from the staking contract. * Caches current `activePoolId`. * Maps **user tier → reward multiplier**. * Receives and stores **miner submissions (scores)**. * After each cycle ends: * Calculates final rewards. * Signs reward claim data for miners. **API Endpoints Example:** * `GET /api/pool/active` → Returns current active `poolId`. * `POST /api/submit` → Miner submissions with scores and wallet address. *** #### **3. Miner CLI (Mining Client Application)** * Fetches the current `activePoolId` from Backend. * Begins mining **only when a pool is active**. * Tags every submission with the `poolId`. * Sends mined scores to Backend for reward calculation. *** ### 🔄 Workflow Summary 1. **Staking Contract** starts a 14-day cycle and sets `activePoolId`. 2. **Backend Server** listens, stores `poolId`, and prepares multiplier logic. 3. **Miner CLI** requests `activePoolId` and starts mining. 4. Miners submit scores → Backend collects and logs them. 5. At cycle end, Backend calculates rewards and signs claim data. *** ### ✅ Benefits of This Architecture * **Fair Reward Distribution** via tier system and multipliers. * **Decentralized Trust** (pool data is from on-chain contract). * **Scalable** — miners only depend on minimal API endpoints. * **Secure** — reward claims require server-side cryptographic signature. *** ### 📌 Next Steps * Add diagrams to GitBook. * Document exact API request/response payloads. * Provide sample Miner CLI configuration. *** Would you like me to add diagrams, API specs, or format this into Markdown for GitBook directly? ### 📊 System Diagram ``` graph TD; A[Staking Contract] -->|activePoolId + user tier| B[Backend Server]; B -->|API: /api/pool/active, /api/submit| C[Miner CLI]; subgraph A1[Staking Contract] A1A[Controls 14-day cycle] A1B[Issues new poolId each cycle] A1C[Stores user tier] end subgraph B1[Backend Server] B1A[Listens to contract events] B1B[Caches current poolId] B1C[Maps tier to multiplier] B1D[Receives miner submissions] B1E[Signs reward claims per cycle] end subgraph C1[Miner CLI] C1A[Fetches active poolId] C1B[Starts mining only when active] C1C[Tags submissions with poolId] C1D[Sends scores to backend] end ``` # Attested Proof-of-Compute Mining Architecture ## #### *A-MPoC-SBA: Attested Merkle Proof-of-Compute with Stake-Bound Authenticity* *** ### **Overview** This document outlines a next-generation mining architecture designed for secure GPU-based proof-of-compute networks.\ The system defends against: * fake or scripted miners * reverse-engineered clients * fraudulent compute proofs * stake spoofing * botnet-scale replay attacks * GPU identity impersonation The architecture combines cryptographic attestation, stake-derived proofs, hardware-bound identity, and Merkle-based compute validation to form **A-MPoC-SBA** — a layered, tamper-resistant mining protocol. *** ## **1. Stake-Bound Seed Proof (SBA)** A miner cannot participate without presenting a **stake-derived on-chain proof**, reducing RPC load and eliminating fake staking states. #### **Stake parameters included in the proof** * staked amount * tier / class * stake start time * locked/unlocked status * pool ID * challenge seed * block number #### **Contract-derived proof** The smart contract generates: ``` proofHash = keccak256( user, amount, startTime, tier, unlocked, seed, blockNumber ) ``` The miner: 1. fetches this proof 2. attaches it to the challenge response The server verifies the proof **without querying RPC**, ensuring: * tiers cannot be spoofed * stake cannot be inflated * pool ID cannot be faked * miners cannot fake lock/unlock status * extremely low server overhead This approach is cutting-edge and rarely seen in PoW/PoUW systems. *** ## **2. Merkle Proof-of-Compute (M-PoC)** Each GPU loop produces a digest. All digests are committed into a Merkle tree. #### **Miner submits** * Merkle root * loop digests (raw or compressed) * Merkle branches / levels * total loop count #### **Server verifies** * integrity of all loop outputs * honest loop count * compute duration validity * no skipped iterations * no forged GPU output This provides **verifiable compute integrity**, preventing miners from falsifying GPU speed or fabricating workload results. *** ## **3. Embedded Private Key + HMAC Attestation** Every official miner includes a `.pyd` extension containing a hidden 32-byte private key, obfuscated into multiple fragments to resist extraction. #### **Each request contains** * HMAC-SHA256 signature * timestamp * nonce #### **Security effects** * prevents fake clients / scripts * blocks modified or reverse-engineered miners * stops replay attacks * mitigates DDOS via pre-HMAC verification * ensures only authentic miners receive challenges This is similar to security practices used in enterprise GPU compute and AAA game anti-cheat systems. *** ## **4. Hardware-Bound Miner Identity** To prevent miner duplication and GPU impersonation, each compute proof is tied to hardware identity: * GPU UUID * persistent hardware fingerprint #### **Prevents** * multi-spawn miner abuse * sharing one miner across many machines * GPU spoofing * botnet-style farm impersonation Combined with stake identity, this forms a multi-factor miner authentication pipeline. *** ## **5. Challenge-Binding & Pool-Binding** Each challenge is cryptographically locked to: * the miner’s wallet * the stake state * the mining pool * the contract seed * the epoch block number #### **Properties** * challenges must be freshly requested * cannot be precomputed * cannot be shared or cached * cannot be replayed * require stake + key + hardware identity This eliminates precomputation attacks entirely. *** ## **6. High-Level Security Flow** #### **A. Challenge Phase** 1. Miner signs request with HMAC (`seed="challenge"`). 2. Server verifies HMAC before generating challenge. 3. Only authenticated `.pyd` miners receive seeds. #### **B. Proof Submission Phase** 1. Miner executes GPU loops. 2. Builds Merkle tree over digests. 3. Obtains stake-bound proof from contract. 4. Signs final submission with new HMAC + nonce. 5. Server verifies: * HMAC * stake proof * Merkle proof * timestamps * hardware identity * nonce validity Any failure → immediate rejection. *** ## **7. Advantages Over Traditional Mining** * Impossible to fake shares * Impossible to spoof GPU throughput * Impossible to farm rewards with scripts/bots * Stake state cannot be falsified * Eliminates RPC load for stake verification * Strong defense against DDOS on challenge endpoints * Protects against reverse-engineered miners * Ensures real GPU computation * Stops miner duplication / impersonation This design meaningfully improves the security posture of decentralized proof-of-compute networks. *** ## **8. Summary** A-MPoC-SBA integrates techniques from: * blockchain staking verification * GPU verifiable compute * enterprise hardware attestation * cryptographic challenge binding * Merkle tree integrity proofs * anti-cheat security engineering The architecture prevents the full spectrum of miner cheating vectors: from GPU spoofing and fake loops to stake manipulation and replay attacks. It represents a modern, highly secure approach to hybrid **proof-of-compute × proof-of-stake** mining — and a substantial leap forward compared to traditional PoW or PoUW systems. # Mining Workflow Overview Proofs in HashCloud are deterministic and cryptographically verifiable. ```json { "wallet": "0x5063...", "gpuId": "GPU-041ae03...", "gpuName": "NVIDIA GTX 1650", "matrixSize": 512, "elapsed": 4.85, "resultHash": "a1b2c3d4...", "timestamp": 1735130000 } ``` Each proof includes:\ **Wallet:** Identifies the miner.\ **GPU ID & Name:** Ensures UUID-based validation.\ **Matrix Size:** Defines compute difficulty.\ **Elapsed Time:** Used to derive performance.\ **Hash:** Ensures deterministic verification. HashCloud redefines the traditional mining cycle by replacing probabilistic hash guessing with deterministic GPU computation. Instead of competing in a lottery like Proof-of-Work, miners perform a guaranteed sequence of verifiable compute tasks. This ensures that **performance not luck or ASIC dominance determines reward outcomes**. The network issues computation challenges to miners, each tied to their GPU identity and time window, ensuring fairness and preventing precomputation exploits. Miners compute the matrix results, generate a hash, and submit a lightweight proof to the verification engine. The mining flow is designed so that every stage from challenge generation to reward distribution maintains transparency, reproducibility, and resistance to manipulation. Because workloads are deterministic, the network can independently recompute the challenge to confirm correctness without requiring the miner to upload large matrices. This makes the system extremely bandwidth-efficient and scalable across everyday consumer GPUs. *** ### **Workflow Diagram** Challenge Issued\   ↓\ GPU Performs Deterministic Matrix Computation\   ↓\ Output Matrix → Hashed → Proof Generated\   ↓\ Proof Submitted to Network\   ↓\ Network Verifies Computation\   ↓\ Performance Scored + Rewards Distributed *** ### **Deterministic Matrix Computation** At the heart of HashCloud is the use of deterministic linear algebra workloads. These tasks are chosen because GPUs naturally excel at matrix operations, providing perfect alignment between hardware capability and protocol requirements. Each miner receives a unique matrix pair derived from a cryptographic seed combining wallet address, GPU UUID, and timestamp. This ensures that challenges cannot be copied, predicted, or precomputed. Because matrices differ by miner, time window, and hardware identity, the protocol achieves strong resistance to spoofed submissions or fraudulent compute outsourcing. *** ### **Cryptographic Proof Submission** Miners do not submit raw matrix outputs. Instead, they create a **compact hashed proof** that includes metadata such as elapsed time and matrix size. The verification engine reconstructs the challenge and recomputes the expected hash. If the values match, the proof is validated. This ensures:\ ✅ low bandwidth usage\ ✅ protection from cheating or synthetic compute\ ✅ scalable participation across many hardware types *** ### **Proof Flow Diagram** Matrix Output → Hash Function → Proof Packet\   ↓\ Network Regenerates Challenge\   ↓\ Network Recomputes Expected Hash\   ↓\ Hash Match? → **Yes** → Valid Proof\        → **No** → Rejected Submission *** ### **Performance Scoring & Reward Allocation** HashCloud allocates rewards using a transparent scoring model based on matrix size and computation time. Larger matrices increase difficulty, while faster completion times represent higher GPU performance. This avoids unpredictable PoW-style variance and ensures every miner receives a reward proportional to their actual computational contribution. VIP staking multipliers increase point earnings but never inflate token emission, keeping economic integrity intact. *** ## ✅**14-Day Reward Distribution + Community Voting** ### **14-Day Mining Reward Distribution Cycle** HashCloud distributes mining rewards using a fixed **14-day epoch cycle**: * All valid proofs submitted within the 14-day window accumulate compute points. * At the end of the epoch, each miner’s total contribution is calculated. * Rewards are released proportionally based on accumulated points. * After payout, the epoch resets and the next 14-day cycle begins. This model ensures predictable payouts, stable economics, and fair competition across different GPU tiers. *** ### **Community Voting / Team or Partnership Decision on Reward Token** Before each 14-day epoch begins, the reward token for the upcoming cycle is determined through one of two governance paths: #### ✅ **1. Community Voting** The community miners, stakers, or token holders votes on: * Which token will be used for reward distribution * Seasonal or promotional reward choices * Partner token events or bonus cycles Voting can occur through: * Governance dashboard * Snapshot-style off-chain voting * Integrated polls (Discord, Telegram, Website) This ensures decentralized influence over reward economics. #### ✅ **2. Team / Partnership Decision** When strategic flexibility is needed, the reward token may be selected by: * The VIP Amplify core team * Strategic partnerships * Ecosystem collaborations * Market-driven initiatives This ensures HashCloud can adapt reward tokens aligned with partnerships, liquidity opportunities, and long-term sustainability. Both governance paths ensure the protocol remains **adaptive, community-aligned, and strategically flexible**. # One-GPU-Per-PC Policy - Design Rationale ### 🧠 Overview The **One-GPU-Per-PC policy** is a deliberate architectural decision at the core of the **HashCloud (HCLD)** mining protocol. This rule limits each miner instance to one active GPU per installation. While it might seem restrictive from a traditional mining perspective, it serves as a crucial foundation for ensuring **network fairness, system stability, and broad decentralization**.\ By standardizing miner configuration, HashCloud prevents excessive consolidation of compute power within a single operator or machine, ensuring that rewards are distributed equitably based on genuine network participation.\ Users who wish to deploy multiple GPUs are still fully supported they can simply run multiple installations on different systems, each operating as an independent node under the same wallet or account. This preserves scalability while maintaining decentralization and verifiability at the protocol level. *** ### ⚙️ Technical Design Rationale #### **Simplified GPU Management** Supporting multiple GPUs per instance introduces complex engineering challenges, such as driver conflicts, VRAM contention, and synchronization delays between GPU threads. HashCloud minimizes these technical burdens by enforcing a one-GPU-per-instance rule, resulting in a **lightweight, highly stable miner** that functions consistently across a wide variety of devices. This design choice enables the miner to run efficiently on everything from entry-level gaming rigs to enterprise-grade servers without specialized configuration. #### **Cross-Platform Consistency** HashCloud is built to support diverse hardware ecosystems including **NVIDIA, AMD, and Intel GPUs** across different operating systems. Multi-GPU environments often behave inconsistently due to driver or platform differences, leading to performance variability and frequent bugs. By focusing on a single-GPU architecture, HashCloud ensures that **each miner behaves predictably**, simplifying updates, performance tuning, and network-wide compatibility. This uniform behavior makes it easier for developers to roll out optimizations and for users to maintain their systems without technical expertise. #### **Simplified Troubleshooting and Maintenance** In multi-GPU rigs, diagnosing failures can become an operational nightmare. An issue in one GPU may cascade across others, causing miner crashes, driver resets, or system instability. HashCloud’s single-GPU model isolates potential failures **if one machine fails, only that individual node is affected**. This reduces downtime, simplifies error tracking, and allows for rapid issue resolution. The result is a network composed of many independently stable nodes, each contributing reliably to the overall compute fabric. *** ### 💰 Fairness and Decentralization #### **Equal Opportunity Mining** HashCloud’s mining model is designed to empower the individual, not the industrial miner. By enforcing a one-GPU-per-PC rule, **large mining farms cannot dominate rewards through hardware stacking**. Instead, compute performance per node becomes the core measure of contribution. This fosters a fair, decentralized ecosystem where home miners, developers, and small operators have equal opportunity to participate in token distribution. #### **Balanced Network Contribution** Every node in the HashCloud network represents a unique, verifiable contributor. The single-GPU policy ensures **balanced compute distribution**, preventing situations where massive GPU clusters distort network statistics or accumulate disproportionate rewards. Each device contributes predictably, allowing HCLD emissions to follow a mathematically fair curve that reflects actual compute power rather than centralized hardware advantage. #### **Lower Entry Barriers** This policy also supports HashCloud’s mission of **mass adoption**. Anyone with a standard consumer-grade GPU can begin mining without needing specialized or expensive hardware. This inclusivity encourages community participation from a global audience spanning hobbyists, students, developers, and AI enthusiasts making decentralization a natural outcome of accessibility rather than exclusivity. *** ### 🔐 Security and Anti-Cheating Measures #### **Hardware-Based Device Identification** To uphold fairness and prevent manipulation, each miner instance generates a **unique device ID** derived from immutable hardware signatures such as the GPU’s UUID, system BIOS serial, and MAC address.\ This cryptographic fingerprint ensures that **no two miners can operate on the same machine**, effectively preventing multi-instance spoofing, virtual GPU emulation, or synthetic workload attacks. #### **Exploitation Prevention** HashCloud’s verification layer is designed to identify and block attempts at **multi-GPU spoofing, container-based mining duplication, or virtualized farm simulations**. Because every miner is cryptographically bound to its hardware identity, even advanced users cannot create artificial GPU replicas to gain an advantage. This protection layer preserves integrity and ensures that every token earned corresponds to real, physical computation. #### **Controlled Network Growth** The one-GPU-per-PC approach gives HashCloud’s backend infrastructure enhanced visibility into the network’s structure. Each registered node can be validated, monitored, and benchmarked independently, allowing the protocol to track global compute capacity accurately. This control mechanism enables **secure network scaling**, adaptive difficulty adjustment, and transparent miner registration all of which are essential for long-term sustainability. *** ### 🚀 Future Compatibility and Scalability Despite its limitations, the One-GPU-Per-PC policy does **not** restrict scalability. It encourages it through distributed deployment. Users who wish to scale their mining operation can run multiple independent nodes on different machines, each connected to the same wallet. This mirrors distributed computing models used in major cloud systems, ensuring that HashCloud grows through **horizontal scalability** (more devices) rather than **vertical monopolization** (more GPUs per machine).\ This model also future-proofs the protocol for **edge computing, mobile GPUs, and low-power devices** such as portable consoles or mini PCs. HashCloud’s modular miner architecture allows these devices to contribute meaningful computation without complex configuration, supporting a diverse and adaptive global compute network. *** ### ✅ Summary | **Goal** | **Benefit** | | ------------------------------ | ------------------------------------------------------ | | Simplified code and deployment | Eliminates multi-GPU complexity and improves stability | | Fair token distribution | One GPU = One node = One verifiable reward | | Security & authenticity | Hardware IDs prevent miner duplication and spoofing | | Lower entry barriers | Anyone can mine with a consumer-grade GPU | | Stronger decentralization | Promotes a global network of many small contributors | *** #### **In Summary** The **One-GPU-Per-PC Policy** is not a restriction it is a **principled foundation** that protects fairness, improves performance, and enforces genuine decentralization across the **HashCloud (HCLD)** ecosystem.\ By combining simplicity with security, HashCloud ensures that every participant regardless of hardware scale has equal opportunity to contribute, earn, and strengthen the network. This approach keeps the system stable, sustainable, and fundamentally aligned with its mission: **to build a decentralized compute cloud owned and powered by the people.** # Protocol Mechanics Proof-of-Compute System ## High-Level Overview HashCloud’s mining process follows a predictable, verifiable, and performance-driven compute cycle. Instead of relying on probabilistic hashing or nonce-based mining, every miner executes a deterministic sequence of GPU computations linked to their hardware identity. This ensures fairness, eliminates luck-based variance, and makes mining more accessible to everyday GPU owners. #### **High-Level Flow Diagram** ``` Miner CLI → Challenge Fetch → GPU Compute → Proof Creation → Verification → Reward Distribution ``` *** ### **Extended Workflow Breakdown** #### **Step 1 — Miner Installs the** HashCloud **CLI** The mining process begins when the user installs the HashCloud command-line interface (CLI). The CLI serves as the miner’s gateway to the network, managing hardware detection, challenge retrieval, computation dispatch, proof creation, and communication with backend validators. The installation is lightweight and optimized for cross-platform use, enabling participation from Windows, macOS, and Linux systems without requiring specialized knowledge. *** #### **Step 2 — CLI Detects and Registers GPU Hardware** Upon initialization, the CLI automatically scans the system for compatible GPUs. Each detected GPU’s unique identifiers such as GPU UUID, VRAM size, compute capability, and memory bandwidth are securely registered. This registration process is critical for maintaining fairness, as it prevents miners from spoofing hardware or simulating devices. By binding compute challenges to GPU identities, the protocol ensures that all work is executed on real physical hardware. *** #### **Step 3 — Backend Assigns Deterministic Compute Challenge** Once hardware is registered, the miner requests a challenge from the backend. The network generates a deterministic matrix computation challenge using a cryptographic seed derived from: * the miner’s wallet address * GPU UUID * timestamp * challenge index This ensures every miner receives a unique task that cannot be predicted, duplicated, or precomputed. The difficulty of the matrix operation adjusts dynamically based on the miner’s performance tier, ensuring competitive fairness across a wide range of GPU models. *** #### **Step 4 — GPU Performs Matrix Computation** The miner’s GPU begins executing the assigned computation workload, consisting of deterministic linear algebra operations optimized for parallel processing. Unlike hashing puzzles, these workloads reflect real computational value and are structured so that every miner must complete the full task no shortcuts or brute-force randomness exist. The deterministic nature ensures identical inputs always produce identical outputs, enabling fast and trustless verification. *** #### **Step 5 — Results Are Hashed and Packaged Into a Proof** After the GPU completes the computation, the output matrix is transformed into a compact cryptographic hash. The proof includes: * matrix size * compute time * GPU identity metadata * output hash This proof is formatted into a lightweight submission package that preserves verifiability without requiring large data transfers. By compressing the computation into a hash, the system remains efficient for miners on low-bandwidth networks. *** #### **Step 6 — Proof Submission to Backend Validators** The CLI transmits the proof packet to the verification backend. Validators reconstruct the same deterministic matrices and recompute the expected output hash. If the miner’s hash matches the validator’s result, the proof is accepted as valid. Invalid or inconsistent submissions are automatically rejected, preventing fabricated workloads or fraudulent participation. *** #### **Step 7 — Backend Stores Performance Data** Once validated, performance data from the miner such as completion speed, challenge accuracy, GPU behavior, and consistency is stored in the backend’s telemetry system. This ensures miners are scored fairly based on their real computing output. Performance logs also allow the network to optimize difficulty levels, ensure fairness across heterogeneous hardware, and protect against exploit attempts. *** #### **Step 8 — Daily Reward Distribution Based on Relative Performance** At the end of each mining epoch, the system calculates total network compute output and determines each miner’s share relative to the total. Rewards are distributed daily, ensuring predictable emissions and long-term sustainability. High-performing GPUs earn proportionally more, while lower-end devices still receive fair rewards based on their contribution. VIP staking multipliers adjust the miner’s score but never mint extra tokens preserving economic integrity. *** ### **Mining Philosophy** HashCloud replaces the randomness of hash-based mining with deterministic compute tasks that deliver real value while preserving the core fairness of Proof-of-Work. Every miner competes based on genuine computational strength, not luck, ASIC monopolies, or capital advantage. This design realigns mining with decentralization, accessibility, and meaningful compute utility. # Transaction Fee Allocation Into Reward Pool ### **Overview** HashCloud introduces a **sustainable reward model** where a portion of network-related transaction fees is redirected into the mining reward pool. This creates a self-reinforcing ecosystem in which platform activity directly benefits miners and stakers, reducing dependency on inflationary token emissions. This mechanism ensures that HashCloud’s economy grows based on usage, not uncontrolled token minting. *** ### **How Transaction Fee Allocation Works** Certain network transactions generate fees. These can include: * Mining reward claims * Staking and unstaking operations * Smart contract interactions within VIP Amplify A defined percentage of these fees is automatically routed into the **Reward Pool Contract**. #### ✅ **Example Flow** 1. User performs a transaction (e.g., staking, claiming,). 2. Smart contract charges a small fee. 3. A portion of this fee is directed to the **Reward Pool**. 4. The reward pool changes for every 14-day epoch distribution. 5. Miners and stakers receive enhanced rewards. This creates a passive and automatic growth mechanism for rewards. *** ### **Why This Model Matters (Key Insights)** #### ✅ **1. Reduces Token Inflation** Traditional mining systems rely heavily on constant token minting.\ HashCloud reduces reliance on emission by: * Supplementing rewards with real economic activity * Lowering long-term inflation pressure * Increasing sustainability of reward cycles This makes the token more resilient and long-lasting. *** #### ✅ **2. Aligns Miner Rewards With Ecosystem Growth** As the platform grows, transaction volume increases.\ Higher volume → More fees → Bigger reward pool. This means: * More users = More miner rewards * More stakers = More miner rewards * More governance actions = More miner rewards Growth of the ecosystem becomes growth of miner income. *** #### ✅ **3. Encourages Genuine User Participation** Users interact with the system not just to mine, but to: * Stake * Vote * Use partner features * Claim or boost rewards * Upgrade GPU slots Every meaningful interaction benefits the miners who secure the compute layer. *** #### ✅ 4**. Supports Long-Term Sustainability** By combining: * **Deterministic compute mining** * **14-day epoch rewards** * **Community or team token selection** * **Transaction-fee-fed reward pool** HashCloud becomes highly sustainable without relying on unlimited token emissions. *** ### ✅ **How Fees Integrate With the 14-Day Cycle** The reward pool is dynamic during each epoch: 1. Rewards accumulate from computation scoring. 2. Additional funds from transaction fees are added continuously throughout the 14 days. 3. At the epoch end, the total pool is distributed proportionally based on: * Compute score * Matrix workload difficulty * GPU performance * VIP multipliers This ensures each cycle grows naturally with platform usage. *** ### ✅ **Governance Influence on Fee Allocation** Community or team governance can decide: * What percentage of fees goes into the reward pool * Which operations generate fee contributions * If partner tokens or partner protocol fees should be added * If multiplier bonuses should be enabled for specific periods This creates room for: * Seasonal events * Partner-sponsored bonus pools * Community-chosen reward cycles * Token-specific reward experiments # Deterministic Compute Challenges ### Overview of Deterministic Workloads HashCloud’s Proof-of-Compute system is built around deterministic workloads mathematical operations that produce the *same exact result* every time given identical inputs. Unlike probabilistic hash-based puzzles, deterministic tasks eliminate randomness, allowing miners to compete purely on computational throughput. This design ensures that every GPU performs real work, every challenge can be independently verified, and no miner gains an advantage through chance or specialized ASICs. The deterministic nature of these workloads makes them ideal for large-scale verification and future expansion into AI, ZK-proof generation, and scientific computing. It turns GPU mining from arbitrary hashing into a predictable, reproducible compute process that forms the backbone of HCLD’s decentralized compute network. ### Challenge Generation Using Cryptographic Seeds Each miner receives a unique matrix challenge derived from a cryptographic seed. This seed ties the challenge to the miner’s identity, hardware, and time window ensuring fairness, preventing duplication, and blocking precomputation. #### **Seed Inputs Include:** * **Miner Wallet Address** – binds the challenge to a specific account * **GPU UUID** – prevents GPU spoofing or virtual device emulation * **Timestamp** – ensures time-bounded challenge validity * **Challenge Index** – supports continuous mining loops These variables are concatenated and hashed to form the **challenge seed**, which defines the structure and values of the matrices the miner must compute. ### Challenge Generation Diagram ``` (wallet + gpu_uuid + timestamp + loop_index) ↓ Cryptographic Hash ↓ Deterministic Matrix Seed ↓ Matrix A + Matrix B Generation ``` Because matrices are derived from a secure hash, miners cannot predict or manipulate future challenges. Every workload is unique, reproducible, and cryptographically anchored to the miner. ### **Matrix Construction & Compute Complexity** From the seed, the protocol generates two matrices: **Matrix A** and **Matrix B**. Their dimensions are determined by the active difficulty level of the miner. Larger matrices require significantly more GPU resources, ensuring that compute power directly correlates with reward share. #### **Characteristics of** HCLD **Matrices** * Generated fully from deterministic rules * Sized according to miner difficulty band * GPU-efficient structure (ideal for CUDA/OpenCL operations) * Zero ambiguity same seed always produces same matrices This operation forms the compute challenge: C=A×BC = A \times BC=A×B The miner must compute the resulting matrix **C**, which becomes the basis of the proof. All values are deterministic, meaning any validator can reconstruct the same computation independently. ### **Hashing the Output for Lightweight Proofs** To avoid sending large matrices over the network, HCLD converts the computed result into a compact cryptographic hash. This ensures the proof is: * Small enough for low-bandwidth connectivity * Unforgeable without performing the computation * Easily verified by regenerating the same matrices The output hash represents a fingerprint of the full computation, enabling fast, trustless validation. #### **Proof Generation Flow** ``` Matrix Output C ↓ Hash Function (SHA-256 or equivalent) ↓ Output Hash ↓ Proof Packet for Submission ``` This approach retains the computational integrity of the workload while keeping network requirements minimal. ### **Verifying Deterministic Compute Proofs** Upon receiving a proof, the verification backend reconstructs the challenge step-by-step using the miner’s submitted metadata. Because all operations are deterministic, the verification process is straightforward: 1. Rebuild challenge seed from miner data 2. Reconstruct Matrices A and B 3. Recompute C = A × B 4. Hash the recomputed output 5. Compare to the miner’s submitted hash A match confirms the miner executed the computation correctly. A mismatch indicates invalid compute or an attempt at fabrication. #### **Verification Diagram** ``` Received Proof → Rebuild Seed → Regenerate Matrices ↓ ↓ ↓ Recompute Matrix Output → Hash → Compare → Valid/Invalid ``` This process ensures: * No miner can cheat * No shortcuts exist * All rewards are based on genuine GPU computation ### **Why Deterministic Challenges Ensure Fairness** Deterministic computation solves the fundamental fairness issues of PoW and PoS: ✅ **No Luck Advantage** — Every miner completes the same class of work\ ✅ **No ASIC Domination** — Matrix workloads are memory-intensive and GPU-optimized\ ✅ **No Fraud** — Outputs cannot be faked without performing the computation\ ✅ **No Centralization** — Any consumer GPU can participate\ ✅ **No Precomputation** — Challenges are tied to timestamps and GPU IDs This model enables a sustainable and decentralized compute ecosystem where performance alone determines miner success. # Difficulty Matrix Policy ### **Overview** The Difficulty Matrix Policy defines how computational tasks scale across the HashCloud network. By dynamically adjusting matrix sizes based on GPU performance, the system maintains equilibrium between miners of different capacities while ensuring that every participant contributes meaningfully to network throughput. Matrix sizes serve as the quantitative representation of mining difficulty larger matrices correspond to more complex computations and therefore require greater GPU capability and energy investment. This mechanism forms the backbone of HashCloud’s adaptive Proof-of-Compute ecosystem, ensuring that difficulty progression remains transparent, fair, and computationally verifiable. ### **Matrix Size Parameters** Each compute task issued to a miner involves the multiplication of two matrices (**A** and **B**) generated deterministically from the miner’s cryptographic seed. The size of these matrices directly determines task complexity. #### **Matrix Size Range** * **Minimum:** 256 × 256 * **Maximum:** 1024 × 1024 These bounds represent the controlled limits of difficulty scaling. Smaller matrices are assigned to lower-performance GPUs or new miners entering the network, while high-performance GPUs or established nodes receive proportionally larger matrices to maximize network efficiency. ### **Scaling Behavior** The difficulty adjustment algorithm automatically benchmarks each miner’s compute speed during participation. Based on performance telemetry, it assigns future workloads that scale appropriately, ensuring balanced contribution and eliminating wasteful over- or under-utilization. #### **Adaptive Scaling Rules** * **Dynamic Load Assignment:** Faster GPUs are matched with larger matrices to ensure full hardware utilization. * **Equilibrium Maintenance:** The network constantly re-evaluates miner performance and adjusts matrix difficulty to maintain global compute stability. * **Anti-Cheat Measures:** Difficulty adjustments occur through backend calibration, preventing miners from falsifying performance reports to gain an advantage. This feedback loop ensures that no miner can dominate through hardware brute force alone, as computational fairness is reinforced by proportional scaling. ### **Reward Impact** Rewards in the HashCloud system are derived from the measurable efficiency of GPU computation. The reward formula incorporates both **matrix size** (as a representation of workload magnitude) and **elapsed computation time** (as a measure of speed and efficiency). #### **Reward Formula** $$ \text{reward} \propto \frac{\text{matrixSize}^2}{\text{elapsedTime}} $$ This proportional relationship incentivizes two outcomes: 1. **Higher Efficiency:** Miners with optimized GPUs complete larger matrices faster, increasing reward output. 2. **Network Balance:** Rewards remain fair across hardware tiers, as slower GPUs may receive smaller matrices, balancing competition. #### **Conceptual Flow** ``` Matrix Size ↑ → Compute Demand ↑ → Elapsed Time ↑ → Reward Balanced by Efficiency ``` Through this formula, HashCloud achieves a synergy of fairness and performance each miner is rewarded according to actual, verified compute work rather than random outcomes or speculative staking. ### **Governance and Future Calibration** The Difficulty Matrix Policy is not static. As GPU technology evolves and the HCLD network expands, new matrix ranges and scaling coefficients can be introduced through on-chain governance proposals. Community-approved upgrades may include: * Expanding maximum matrix size to accommodate next-generation GPUs * Introducing non-linear scaling for advanced compute tiers * Refining reward normalization curves based on empirical performance data This flexible policy framework ensures the protocol remains future-proof while continuing to uphold the principles of decentralization, verifiable computation, and reward integrity. # Auto Difficulty Scaling ### **Overview** Auto-Difficulty Scaling (ADS) is the mechanism that keeps the HashCloud network balanced and efficient as miner hardware diversity grows. By dynamically adjusting computational difficulty in real time, the system ensures that miners of varying GPU capabilities compete on equal terms while maintaining stable block intervals and predictable network output. This adaptive model replaces static difficulty systems common in traditional Proof-of-Work chains with an intelligent, feedback-driven algorithm. The result is a self-regulating mining environment where network performance remains consistent, and no single miner can dominate due to raw hardware advantage. ### **How It Works** Auto-difficulty scaling continuously monitors **elapsed compute time** for each miner’s submitted proof. Using this data, the system evaluates whether the miner completed the assigned task too quickly or too slowly compared to the network’s target time threshold. * **If computation is completed faster than expected**, it implies that the miner’s GPU is under-challenged. The system automatically **increases matrix size**, assigning larger workloads in the next challenge cycle. * **If computation is slower than expected**, the system **reduces matrix size** to align performance with the global average. This creates a smooth, adaptive equilibrium where GPU performance differences are normalized across all miners. #### **Process Flow** ``` Monitor Compute Time → Compare to Target Time → Adjust Matrix Size ↓ Faster GPUs → Larger Matrices Slower GPUs → Smaller Matrices ``` ### **Benefits of Adaptive Scaling** The Auto-Difficulty Scaling system provides multiple benefits for both miners and the overall network: ✅ **Balanced Network Performance**\ Each GPU contributes compute proportional to its capacity, preventing bottlenecks and ensuring efficient resource utilization. ✅ **Prevention of Hardware Dominance**\ High-end GPUs cannot monopolize emissions, as their tasks automatically scale in difficulty to offset raw speed advantages. ✅ **Stable and Predictable Mining Experience**\ Miners enjoy a smoother, more consistent performance curve no sudden difficulty spikes or reward volatility. ✅ **Fair Participation Across Devices**\ From gaming GPUs to professional compute cards, every miner remains relevant within the ecosystem. {% hint style="success" %} #### Benefits * Ensures balanced performance across all miners. * Prevents high-end GPUs from dominating rewards. * Provides consistent mining experience. {% endhint %} ### Formula Concept The HashCloud protocol expresses its auto-difficulty logic using a simple yet powerful mathematical model. The algorithm continuously adjusts matrix size according to each miner’s performance relative to the network’s **target compute time**. $$ \text{newMatrixSize} = \text{previousMatrixSize} \times \text{adjustmentFactor} $$ Where the adjustment factor is defined as: $$ \text{adjustmentFactor} = \frac{\text{targetTime}}{\text{actualTime}} $$ #### **Interpretation** * If a miner computes faster than the target (actualTime < targetTime), the factor becomes >1, **increasing matrix size**. * If a miner is slower (actualTime > targetTime), the factor becomes <1, **decreasing matrix size**. This closed-loop feedback ensures continuous equilibrium, where computation time per challenge naturally converges toward the desired target range. ### **Network-Wide Stability Mechanism** To prevent oscillation or over-adjustment, HashCloud introduces a dampening coefficient within the adjustment factor. This ensures that changes in matrix size occur gradually rather than abruptly, preventing destabilizing fluctuations across mining epochs. The backend aggregates telemetry from all active miners to calculate a **global adjustment curve**, preserving synchronization between individual difficulty levels and the network’s overall compute throughput. ### **Future Evolution** As the network grows, Auto-Difficulty Scaling may evolve into a **multi-tier calibration model**, incorporating: * Predictive difficulty adjustment using machine learning * Regional or pool-based scaling for decentralized performance balancing * Integration with compute leasing markets for real-time optimization By making difficulty dynamic and intelligent, HashCloud establishes a foundation for sustained scalability and fairness across a diverse GPU ecosystem. # HashCloud Mining Rewards Protocol ### **Overview** HashCloud introduces a **dynamic and transparent mining rewards framework** purpose-built for decentralized GPU compute.\ The model evaluates every miner based on: * **Real computational throughput** * **Staked token contribution** * **VIP tier multipliers** * **14-day epoch scoring** Unlike static mining systems, HashCloud’s reward model adapts each epoch to reflect network activity, compute supply, and governance updates. *** ## **1. Reward Formula** The core of the reward mechanism is built on three components: ``` base_power = loops_done / compute_time final_score = base_power * stake_multiplier * vip_multiplier ``` Each miner’s reward is proportional to the verified compute they provide and their economic + community participation. *** ## **2. Base Power** #### **Definition** `base_power` measures the miner’s raw GPU throughput. * **loops\_done** — Total validated GPU computation loops in an epoch * **compute\_time** — Total active processing time (seconds) ``` base_power = loops_done / compute_time ``` #### **Purpose** * Normalizes differences between GPUs * Rewards consistent uptime * Reflects real performance without vendor bias #### **Integrity** * Every loop undergoes **Merkle Subset Auditing** * Invalid or manipulated results are rejected * Timestamped logs ensure session integrity This ensures base power represents *real* computation. *** ## **3. Stake Multiplier** Staking increases a miner’s reward potential while strengthening ecosystem liquidity. ``` stake_multiplier = 1 + (staked_amount / stake_ratio) ``` #### **Key Notes** * Multiplier increases linearly up to a capped maximum (e.g., 2.5×) * Unstaking before epoch end may reduce multiplier credit * Boost is recalculated every epoch #### **Benefits** * Stabilizes token circulation * Rewards long-term participation * Supports predictable liquidity flow *** ## **4. VIP Multiplier** HashCloud’s VIP system enhances rewards for active community members. ``` vip_multiplier = 1.0 → 3.0 ```
VIP TierRequirementsBonus
BronzeDefault1.25x
Silver2 active epochs + minimum stake1.5x
GoldContributor / consistent miner1.75x
DiamondGovernance role / validator participation2.0x
VIP tiers reset and update every epoch. *** ## **5. Epoch Distribution Model** HashCloud operates using **14-day epochs**. #### **Epoch Steps** 1. Aggregate all verified compute data 2. Compute every miner’s `final_score` 3. Sum global network score 4. Distribute rewards: ``` miner_reward = (final_score / total_network_score) * reward_pool ``` #### **Adaptive Reward Pool** Reward pool recalibrates each epoch based on: * Protocol revenue * Marketplace fees * DAO contributions * Unclaimed or penalized rewards The system scales naturally with ecosystem growth. *** ## **6. Reward Pool Inflow** The reward pool is fed from multiple on-chain sources: #### **Sources** * % of network transaction fees * Revenue from compute or marketplace integrations * Community/DAO injections * Adjustment factors (penalties, unused allocations) #### **Sustainability** By tying rewards to network activity, the system creates a **self-balancing economic loop**. *** ## **7. Verification & Anti-Fraud** HashCloud uses **Merkle Subset Auditing** to verify compute results while keeping bandwidth low. #### **Security Features** * Miner submits all loop digests * Server verifies a random subset * Any failed proof invalidates the entire batch * Probabilistic detection defeats fake-loop attempts This ensures the network rewards **only honest computation**. *** ## **8. Governance Integration** The governance council or DAO can modify system rules: * Adjust stake multiplier ratios * Change epoch length * Select reward pool token composition * Update VIP rules * Approve mining protocol upgrades Governance ensures the system evolves fairly and transparently. *** ## **9. Future Extensions** Planned upgrades include: #### **Coming Soon** * **Dynamic GPU Benchmarking** * **Smart Epoch Rebalancing** * **Cross-chain reward distribution** * **AI-driven compute difficulty tuning** These expansions aim to scale HashCloud into a global decentralized computation layer. *** ## **Summary** HashCloud unifies *verified compute*, *staking economics*, and *community governance* into a single reward protocol. The result: * Fair * Transparent * Scalable * Hard to cheat * Sustainable long-term Miners who provide real GPU power — and participate in the ecosystem — earn the highest rewards. # VIP Amplify ### **Overview** The VIP Amplify system introduces an innovative, non-passive staking mechanism designed to enhance miner performance without compromising fairness or token integrity. Unlike traditional staking systems that generate yield through inflationary minting, HCLD’s VIP Amplify model focuses solely on improving active mining output through a performance multiplier applied to verified compute results.\ **Staked tokens must be locked for a minimum of 14 days** to qualify for VIP benefits; this lock period aligns incentives, reduces immediate sell pressure, and ensures that multiplier privileges reflect sustained network commitment. This approach transforms staking from a passive wealth mechanism into an *active participation enhancer*, rewarding miners who commit to network stability and long-term alignment. Staked tokens do not earn rewards by themselves; rather, they unlock enhanced compute efficiency and GPU slot privileges that scale performance rewards in proportion to effort. #### **Philosophy of Fair Staking** HCLD’s staking model was built around the principle of **“Proof of Commitment, not Proof of Capital.”**\ By decoupling staking from passive income and requiring a **14-day minimum lock**, HashCloud ensures that all network rewards remain performance-driven. Staking simply amplifies the miner’s effectiveness within verifiable computation tasks, ensuring decentralization and fair participation at every tier. This 14-day commitment discourages speculative, short-term staking and instead promotes operational loyalty miners who genuinely contribute computational value over time receive the amplified benefits. #### **VIP Tiers & Locking Rules** HCLD introduces four staking tiers (VIP Levels). Each tier provides a proportional multiplier to verified compute results and requires that the staked HCLD be **locked for at least 14 days** to activate multipliers and GPU slot allowances. | **Tier** | **Stake (**HCLD**)** | **Multiplier** | **Lock Requirement** | | -------------- | ------------------------------ | -------------- | ----------------------------- | | VIP1 (Bronze) | 10,000 | ×1.25 | 14 days locked | | VIP2 (Silver) | 25,000 | ×1.50 | 14 days locked | | VIP3 (Gold) | 50,000 | ×1.75 | 14 days locked | | VIP4 (Diamond) | 100,000 | ×2.00 | 14 days locked + verification | **Activation rule:** multipliers and GPU slot increases only apply after the stake has been locked for 14 continuous days. Stakes in an unlocking state do not confer multiplier benefits; any new stake must complete the 14-day period before being counted. {% hint style="info" %} Staking increases reward output but does not mint tokens. Multipliers apply to normalized performance results. {% endhint %} #### **Key Properties (including duration behavior)** * **No Passive Yield:** Tokens staked in the VIP system do not accrue standalone rewards. * **14-Day Lock:** All staking tiers require a **minimum 14-day lock** before multiplier and GPU slot privileges become active. * **Unstake & Cooldown:** After initiating an unstake, a cooldown (e.g., 7 days) may apply before tokens become withdrawable; during cooldown, multiplier benefits are revoked. * **Early Unstake Penalty (optional):** To discourage repeated short-term staking, a slashing or forfeiture of a small percentage of accrued multiplier benefit may apply for unstaking before 14 days (policy configurable by governance). * **Compute-Linked Multipliers:** Amplification only applies to normalized compute results, preserving emission stability. * **Non-Inflationary Design:** No new tokens are minted through staking; amplified rewards are drawn from the existing daily emission pool. * **Hardware-Aware Limits:** Multipliers are bounded by GPU verification to prevent abuse via low-end hardware paired with high-tier staking. These rules together ensure economic balance: the 14-day lock ties multiplier access to genuine commitment, preventing capital-only actors from exploiting short windows of advantage. ### Reward Formula #### **Reward Formula (clarified)** The VIP Amplify reward mechanism mathematically integrates the miner’s compute output, efficiency, and staking tier into a unified expression **applicable only after the 14-day lock period has completed**: $$ \text{reward} = \left(\frac{\text{matrixSize}^2}{\text{elapsedTime}}\right) \times \text{vipMultiplier} \times \text{baseReward} $$ #### **Concept Explanation** * **matrixSize² / elapsedTime** — Represents normalized compute throughput. * **vipMultiplier** — Enhances miner output proportional to their staking tier. * **baseReward** — The epoch’s emission constant defining total available rewards. Code-style: ``` if stake.lockedDays >= 14: reward = (matrixSize^2 / elapsedTime) * vipMultiplier * baseReward else: reward = (matrixSize^2 / elapsedTime) * baseReward ``` **Note:** Stakes that have not met the 14-day requirement receive normal (non-amplified) rewards until the lock completes. If a miner begins unstake/cooldown, the multiplier is immediately suspended for subsequent epochs. #### **Network Impact & Rationale** Requiring a 14-day lock creates multiple positive effects: * **Reduces short-term sell pressure**, improving token stability. * **Aligns incentives** between long-term contributors and the protocol. * **Discourages abuse** via repeated stake/unstake loops. * **Provides predictable governance eligibility** since long-term stakers are demonstrably committed. Example: a miner who stakes 25,000 HCLD (VIP2) will only see the ×1.5 multiplier applied to their normalized compute score after the stake has been locked for 14 days. If they unstake during the first 14 days, they forfeit multiplier access and may trigger the early-unstake penalty if such policy is enabled. # VIP GPU Limits & Hardware Tiering ### **Overview** To preserve decentralization and maintain hardware fairness, HashCloud enforces structured GPU and VRAM limits across its VIP tiers. This policy ensures that no miner can dominate the network using industrial-scale rigs or ultra-high-end GPUs, while still rewarding legitimate contributors who stake tokens and participate actively in the ecosystem. The **Hardware Tiering Model** establishes a clear set of boundaries defining how many GPUs a miner may operate and the maximum VRAM capacity per GPU, aligned with their VIP staking level. This approach promotes equitable access, competitive mining conditions, and broad participation among consumer-grade hardware owners. ### VIP Hardware Rules Each VIP tier defines both the **GPU count allowance** and **maximum VRAM capacity per GPU**. These parameters are validated on registration and continuously enforced by backend verification to prevent tier violations. | VIP Level | GPUs Allowed | Max VRAM per GPU | Example Hardware | | --------- | ------------ | ---------------- | -------------------- | | Free | 1 | 6 GB | GTX 1060-RX 580 | | VIP1 | 2 | 8 GB | RTX 3050-1660 Super | | VIP2 | 4 | 12 GB | RTX 3060–4070 | | VIP3 | 8 | 24 GB | RTX 4090-A100, MI300 | ### **Design Philosophy** The VIP hardware tiering structure is guided by three core design principles: 1. **Hardware Neutrality** – HashCloud promotes accessibility for consumer and mid-range GPUs while still allowing scalability through higher staking tiers. 2. **Anti-Centralization** – Restricting VRAM-heavy hardware mitigates the risk of data center monopolization, preserving decentralized ownership. 3. **Competitive Parity** – The system’s tier scaling ensures that smaller miners remain competitive within their category, reinforcing network diversity. ### **Purpose and Network Impact** #### **Key Objectives** * **Limit GPU Dominance:** Prevent high-VRAM data-center GPUs from overpowering retail miners. * **Preserve Decentralization:** Avoid concentration of mining power in large corporate or industrial setups. * **Enhance Fairness:** Create a balanced environment where consumer-grade GPUs remain viable participants. #### **Positive Outcomes** * Maintains consistent **reward equilibrium** across diverse hardware sets. * Protects the network from **hardware-based manipulation** or **tier spoofing**. * Encourages sustainable decentralization by keeping participation open to a broad range of miners globally. ### **Enforcement and Validation System** The HashCloud backend enforces tier compliance through an automated, tamper-resistant hardware validation framework. #### **Validation Process Flow** ``` GPU Registration → UUID Verification → VRAM Check → Tier Match → Authorization Granted ``` #### **Mechanics** * **GPU UUID Validation:** Each GPU is uniquely identified and bound to the miner’s node ID. * **VRAM Limit Enforcement:** The system automatically compares VRAM specs against the tier allowance. * **Backend Rejection:** Configurations exceeding limits are rejected with logged reports and penalties for repeated violations. This ensures hardware transparency and eliminates unfair advantages, allowing equitable access to compute rewards. ### **Future Considerations** As GPU technology continues to evolve, HCLD’s governance may update tier thresholds to reflect market trends and hardware availability. Future proposals may include: * Support for multi-tenant or cloud-based GPU leasing under regulated staking conditions. * Expansion of upper-tier VRAM limits for AI-specialized GPUs. * Dynamic tier calibration based on network compute distribution. Through periodic review and community consensus, HashCloud ensures that the **Hardware Tiering Policy** remains fair, relevant, and adaptive to technological progression. # VIP GPU Limit Diagrams ### **Overview** The **VIP GPU Limit Diagrams** visually and logically represent how *staking commitment* directly influences *hardware authorization* and *reward eligibility* within the HashCloud network.\ These diagrams serve as a transparent guide to the hierarchical relationship between staking tiers, GPU count, VRAM capacity, and mining reward eligibility. In essence, the system defines a deterministic link: {% code overflow="wrap" fullWidth="false" expandable="true" %} ```markup VIP Level⇒GPU Count⇒VRAM Tier⇒Eligible Rewards ``` {% endcode %} This ensures that the network remains fair, predictable, and resistant to hardware centralization. {% stepper %} {% step %} ### Flow representation The process of hardware validation and reward eligibility follows a structured sequence. This logical flow ensures clarity from initial staking to the final verification of mining capacity. {% endstep %} {% step %} ### Step: Stake Amount The miner begins by staking HCLD tokens. The staked quantity determines the potential mining tier and associated privileges. {% endstep %} {% step %} ### Step: VIP Tier Determined Once tokens are staked, the backend assigns a corresponding **VIP level**. Each tier defines strict boundaries on GPU count and maximum VRAM capacity to maintain fairness. {% endstep %} {% step %} ### Step: Hardware Validation The system verifies the miner’s GPU setup, confirming that both the **number of GPUs** and **VRAM per unit** fall within tier constraints. Hardware exceeding limits is automatically flagged and disqualified from mining eligibility. {% endstep %} {% step %} ### Step: Reward Eligibility If the miner’s configuration passes validation, the account becomes *eligible* for compute task assignments and reward computation within the authorized tier. {% endstep %} {% endstepper %} ### **Mapping Overview** The diagrams and flow mappings used in this policy can be conceptually represented as follows: | **Mapping Parameter** | **Description** | | -------------------------------- | ------------------------------------------------------------------------------- | | **VIP Level → GPU Limit** | Defines the maximum number of GPUs permitted for a given VIP level. | | **GPU Count → VRAM Tier** | Associates each GPU with a specific VRAM threshold per tier. | | **VRAM Tier → Eligible Rewards** | Determines the miner’s reward category based on validated hardware performance. | This mapping ensures a consistent and auditable relationship between **staking effort** and **computational authorization**. ### **System Logic Flow** #### **Logical Sequence** ``` Input: Stake Amount ↓ Derive: VIP Level ↓ Check: GPU Count & VRAM Capacity ↓ Validate: Hardware Compliance ↓ Authorize: Reward Eligibility ``` #### **Key Insight** * Each input (staked tokens) correlates linearly to *permissioned compute capacity*. * Violations (such as over-VRAM GPUs) result in reward disqualification but do not penalize the staked tokens. * The model maintains equilibrium between capital commitment and technical fairness. ## Purpose ### **Purpose and Design Intent** The **VIP GPU Limit Diagram** framework fulfills several important design objectives: * **Transparency:** Makes it clear how staking tiers translate into permissible GPU configurations. * **Fair Competition:** Prevents disproportionate rewards for miners using excessive hardware resources. * **Network Efficiency:** Standardizes performance across diverse mining setups, minimizing backend computation skew. * **Educational Clarity:** Provides visual and logical representation for both newcomers and advanced miners to understand network scaling. By making the staking-to-hardware relationship explicit, HashCloud reinforces its philosophy of *fair scaling through verifiable compute*. {% hint style="info" %} These diagrams make it explicit how staking commitment (VIP level) translates into permitted mining capacity and which rewards a miner can unlock. {% endhint %} # Daily Reward Distribution ### **Overview** The **Daily Reward Distribution** mechanism defines how HashCloud allocates HCLD tokens to participants based on *verified computational performance*.\ Unlike traditional mining systems that rely on block discovery luck or arbitrary hashing power, HCLD’s reward system is fully deterministic, transparent, and performance-driven. Each miner’s reward is calculated relative to the total verified compute output of the network within a 24-hour emission cycle. This ensures that all contributors regardless of scale receive a fair portion of the daily token emission proportional to their actual computational work. ## Reward Formula The reward distribution mechanism is built on a two-tier formula: 1. **Performance Share Calculation** 2. **Final Reward Computation** Step 1: Compute Reward Share $$ \text{rewardShare} = \frac{\text{minerPerformance}}{\text{totalNetworkPerformance}} $$ This equation determines the relative weight of each miner’s contribution within the total compute output for the day. Step 2: Calculate Final Reward $$ \text{finalReward} = \text{rewardShare} \times \text{vipMultiplier} \times \text{dailyEmission} $$ Where: * **minerPerformance** = The miner’s verified compute score (derived from normalized matrix operations). * **totalNetworkPerformance** = Aggregate of all verified miner scores. * **vipMultiplier** = Staking-based performance amplifier (refer to VIP Amplify Policy). * **dailyEmission** = Total HCLD tokens released per 24-hour cycle. This dual-layer calculation ensures both *fair performance weighting* and *staking incentive alignment* without inflating token supply. ## Distribution Flow The entire reward cycle operates through a transparent, automated process composed of four core stages. {% stepper %} {% step %} ### Collect performance scores All miners’ verified computation results are aggregated by the **Performance Database**.\ Each record includes matrix size, elapsed time, and hardware data, forming a complete performance profile. {% endstep %} {% step %} ### Normalize performance The system normalizes raw compute scores into proportional shares relative to the total network output.\ This ensures that rewards are based purely on contribution ratio, eliminating hardware and time biases. {% endstep %} {% step %} ### Apply VIP multipliers Once normalized, each miner’s performance share is adjusted according to their **VIP multiplier**.\ Higher-tier stakers receive a larger proportional weight, rewarding long-term network commitment and resource dedication. {% endstep %} {% step %} ### Distribute tokens The **Reward Engine** finalizes calculations and transfers HCLD tokens on-chain, ensuring auditable, tamper-proof distributions.\ Every transaction is recorded, providing a verifiable trail of reward allocation for transparency and accountability.. {% endstep %} {% endstepper %} This ensures a transparent and performance-based mining reward mechanism. ### **Example Scenario** Assume a total network performance of **10,000 units** and a miner contributing **1,000 units** with a **VIP2 multiplier (×1.5)**.\ If the daily emission is **100,000** HCLD, the miner’s reward would be: $$\text{Reward Share} = \frac{10,000}{100,000} = 0.10\text{Final Reward} = 0.10 \times 1.5 \times 100,000 = 15,000 \text{ HCLD}$$ | **Variable** | **Value** | **Description** | **Implied from Calculation** | | ------------------------------- | ---------------------- | ------------------------------------------------------------------------------------------- | -------------------------------------- | | Miner's Performance Score | 10,000 (Implied) | The miner's individual performance score (normalized hashrate). | Numerator in Reward Share | | Total Network Performance Score | 100,000 (Implied) | The sum of all active miners' performance scores. | Denominator in Reward Share | | Proportional Reward Share | 0.10 (10%) | The miner's share of the total network compute power. | $$ $\frac{10,000}{100,000}$ $$ | | VIP Multiplier | 1.5 | The staking-based multiplier for the miner (e.g., VIP Tier 2/Silver). | The $$ $\times 1.5$ $$ factor | | Daily Base Reward (Total Pool) | 100,000 HCLD (Implied) | The total number of HCLD tokens available to be distributed to the entire network that day. | The last $$ $\times 100,000$ $$ factor | | Final Reward | 15,000 HCLD | The total tokens the miner earns for that period. | The final result | #### Conclusion This calculation confirms the successful application of the complete reward formula from the HCLD documentation: $$\text{Final Reward} = \left( \frac{\text{Performance Score of Miner}}{\text{Total Network Performance Score}} \right) \times \text{VIP Multiplier} \times \text{Daily Base Reward}$$ ### **System Advantages** * **Transparent Reward Distribution:** Every payout is traceable and mathematically verifiable. * **Performance-Based Fairness:** Rewards are tied to measurable compute work, not random chance. * **Non-Inflationary Model:** Emissions are capped per cycle staking affects distribution, not total supply. * **Daily Sync Cadence:** The 24-hour reward window ensures consistent engagement and predictable returns. This approach transforms mining into a *compute economy* where performance, not luck or centralization, dictates rewards. # Tokenomics ### **Overview** The HCLD **Token** lies at the core of the HashCloud ecosystem, functioning as the primary economic driver for compute-based participation.\ Its design emphasizes *sustainability*, *fair distribution*, and *utility alignment* ensuring that token value is directly linked to the verifiable compute output of the network rather than speculative behavior or centralized control. HCLD’s emission and allocation frameworks are structured to support long-term network growth, stable liquidity, and consistent miner rewards while maintaining a capped supply and deflation-resistant economic model. ### **Token Allocation** To balance growth incentives and operational resilience, HCLD’s total supply is distributed across five key categories. Each category supports a distinct function within the ecosystem, ensuring fair access, liquidity, and governance sustainability. | **Category** | **Amount (**HCLD**)** | **Percentage** | **Purpose** | | ----------------------------------------------- | ------------------------------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | **Public Sale (Initial Liquidity)** | 10,000,000 | 10% | Provides initial liquidity for decentralized and centralized exchange listings, supporting token accessibility and early ecosystem adoption. | | **Treasury (Ecosystem, CEX Pool, Maintenance)** | 15,000,000 | 15% | Reserved for ecosystem maintenance, exchange partnerships, operational reserves, and strategic infrastructure expansion. | | | | | | | | | | | | **Team/Developer Funds** | 10,000,000 | 10% | Reserved for founding developers, advisors, and future contributors. Subject to vesting schedules to ensure long-term alignment with network success. | ### **Total Supply** Total Supply=100,000,000 HCLD The total HCLD supply is permanently capped at **100 million tokens**, ensuring a fixed emission ceiling. No additional tokens will ever be minted beyond this cap, preserving scarcity and protecting tokenholder value. ### **Emission Model** The **Mining Pool** representing 60% of total supply is structured for gradual daily emissions distributed through the Proof-of-Compute reward mechanism. This ensures a sustainable and predictable release schedule that encourages active network participation. #### **Emission Characteristics** * **Daily Reward Rate:** Derived from verified compute output normalized by network difficulty. * **Dynamic Scaling:** Adjusts emission pacing in proportion to active miner participation and VIP multiplier averages. * **Longevity-Oriented Distribution:** Designed to sustain emissions across multiple years, promoting stable network growth and consistent participation rewards. This model effectively transforms the mining pool into a *self-regulating economic engine* that incentivizes both compute contribution and staking commitment. ### **Economic Objectives** HCLD’s tokenomics model was built to achieve five foundational economic goals: 1. **Sustainable Growth:** Maintain balance between reward attractiveness and emission longevity. 2. **Fair Distribution:** Ensure that early adopters, long-term miners, and ecosystem participants receive proportional value. 3. **Liquidity Accessibility:** Support healthy trading volumes and network expansion through public sale and treasury reserves. 4. **Deflation Control:** Avoid inflationary drift by strictly capping supply and preventing mint-based staking yield. 5. **Network Utility Integration:** Ensure the HCLD token remains a critical utility within compute verification, staking, and governance processes. ### **Token Flow Summary** #### **Simplified Flow Representation** ``` Total Supply (100M HCLD) ↓ Distribution Pools ↓ Mining Pool → Daily Emission → Verified Miners Treasury → Operations, Ecosystem Growth Public Sale → Liquidity and Accessibility Early Reward → Community Incentives Team/Dev → Long-Term Development ``` {% hint style="info" %} Mining pool emissions are released daily to ensure long-term network participation and reward fairness. {% endhint %} # Emission Schedule & Deflation Control ### **Overview** The **Emission Schedule** defines how HCLD tokens from the Mining Pool are released into circulation, while the **Deflation Control Framework** governs how issuance gradually declines to preserve long-term value.\ This dual-layer design ensures HashCloud maintains predictable, sustainable token circulation aligned with real computational output instead of speculative growth. ### **Emission Principles** * **Performance-Linked Distribution:** Tokens enter circulation only when verifiable GPU compute work is submitted and validated. * **Fixed Total Cap:** No new HCLD can ever be minted beyond 100 million. * **Progressive Emission Reduction:** Daily emissions taper over time to reward early participants while extending mining longevity. * **Adaptive Scaling:** Network difficulty and active-miner count influence minor short-term emission adjustments, keeping reward fairness stable. ### **Emission Schedule Model** HCLD’s 60 million token Mining Pool follows a multi-phase emission curve: | **Phase** | **Duration** | **Emission Rate** | **Total Released** | **Description** | | ---------------------------- | ------------ | ----------------------- | --------------------- | ------------------------------------------------------------------------------ | | **Phase 1 – Genesis Launch** | Year 1 | 30% of pool (18 M HCLD) | 18,000,000 | High initial incentives to attract GPU miners and bootstrap network hashpower. | | **Phase 2 – Stabilization** | Years 2–3 | 20% (12 M HCLD) | 30,000,000 cumulative | Gradual tapering to balance miner ROI and token velocity. | | **Phase 3 – Maturity** | Years 4–6 | 15% (9 M HCLD) | 39,000,000 cumulative | Steady emissions supporting stable compute supply. | | **Phase 4 – Sustain Mode** | Years 7–10 | 25% (15 M HCLD) | 54,000,000 cumulative | Extended low-inflation emission to encourage long-term engagement. | | **Phase 5 – Final Decay** | Year 10 + | 10% (6 M HCLD) | 60,000,000 final | Emissions fully taper; network relies on transaction & compute fees. | After Year 10, emissions approach zero and the system enters a self-sustaining mode powered by compute service fees and governance funding. ### **Deflation Mechanisms** 1. **Burn Events:** A portion of transaction and service fees may be periodically burned via governance-approved proposals to offset circulating supply growth. 2. **Inactive Miner Reclaims:** Unclaimed rewards from inactive miners after a set period (≈ 90 days) return to the Mining Pool for redistribution preventing token waste and supply dilution. 3. **VIP Staking Locks:** HCLD staked for VIP tiers remains temporarily locked, reducing liquid supply and stabilizing market circulation. 4. **Treasury Governance Caps:** Treasury expenditures are rate-limited and fully auditable to avoid inadvertent inflation. ### Mathematical Formulation: Exponential Decay Emission The formula you've presented is an Exponential Decay Function. In the context of tokenomics, it serves as the most accurate way to model a smooth, continuous reduction in token supply, similar to a halving event but without the sudden, drastic cuts. This model is designed to create a smooth, predictable decline in the daily token emission rate over the project's lifespan, preserving scarcity and long-term token value. #### Formula Breakdown $$\text{E}(t) = E\_0 \times e^{-k t}$$ | **Term** | **What it Represents** | **Purpose / Meaning for** HCLD | | -------- | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | $$E(t)$$ | Emission Rate at Time $$t$$ | This is the daily amount of HCLD tokens distributed to miners *today*. As $$t$$ increases (time passes), this number decreases. | | $$E\_0$$ | Initial Daily Emission Rate | This is the starting amount of HCLD tokens distributed to miners on Day 1. This value is determined by the total Mining Pool (60,000,000 HCLD) and the target emission period. | | $$e$$ | Euler’s Number | This is a mathematical constant (approx. 2.718). It is the base for all continuous growth/decay functions. | | $$t$$ | Elapsed Time in Days | This tracks the time since the network launched. It is the variable that drives the decay the longer the time, the smaller the resulting emission rate $$E(t)$$. | | $$-k$$ | Negative Decay Constant | This is the crucial tuning parameter. It is mathematically calculated and tuned so that the total Mining Pool is emitted over the target period of $$\approx 10$$ years. A higher $$k$$ means the emission rate declines faster. | ### **Sustainability and Network Impact** * **Predictable Reward Decline:** Miners and investors can model long-term returns with confidence. * **Price Stability:** Controlled emission mitigates supply shocks and supports organic demand growth. * **Value Retention:** Burns and staking locks naturally decrease circulating supply over time. * **Governance Integration:** Future adjustments to the emission curve require community proposal and on-chain approval. ### **Long-Term Outlook** When the Mining Pool is fully distributed, HCLD will enter a post-emission era driven by: * Compute marketplace fees (as network usage grows). * On-chain governance bounties and developer grants. * Token burns from utility transactions creating deflationary pressure. The result is a closed-loop economy where HCLD’s value is sustained by actual compute utility rather than constant issuance. # Governance and Token Utility ### **Decentralized Governance Model** HashCloud (HCLD) believes that decentralization extends beyond hardware participation it must include **decision-making power**.\ Governance is designed as a **layered on-chain framework** that allows verified participants to shape network direction, protocol updates, and economic policy. **Governance Principles** * **Transparency:** All proposals, votes, and resolutions are recorded on-chain for verifiable public access. * **Merit-Weighted Participation:** Both computational contribution and token holdings determine voting strength, preventing plutocracy and rewarding active miners. * **Progressive Autonomy:** Governance begins semi-guided by the founding council and transitions into full DAO control once threshold decentralization metrics are reached. #### **Governance Process Flow** ``` Proposal Submission → Community Discussion → Formal Vote → On-Chain Execution → Audit & Review ``` **Proposal Types** 1. **Technical Upgrades:** Protocol improvements, algorithm updates, or new compute types (e.g., ZK, AI training). 2. **Economic Adjustments:** Emission-rate tweaks, VIP tier changes, or reward redistribution. 3. **Ecosystem Growth:** Grants, partnerships, and hardware-integration initiatives. 4. **Governance Amendments:** Modifications to voting rules, quorum, or delegation mechanisms. ### **Token Utility Overview** HCLD Tokens are not just emission rewards they are the **core fuel of participation** across mining, staking, and governance layers. | **Utility Category** | **Function Description** | | -------------------------- | -------------------------------------------------------------------------------------------------------------- | | **Compute Access** | Token-based staking unlocks GPU slots and compute quotas for miners. | | **Governance Power** | Holders can propose and vote on improvement proposals (AMPIPs). | | **Performance Multiplier** | Staked tokens increase a miner’s computation weight without generating passive yield. | | **Verification Deposit** | Certain nodes must lock HCLD to validate proofs and reduce spam submissions. | | **Ecosystem Payments** | Used for developer bounties, integration fees, and future marketplace transactions. | | **Reputation Anchor** | Token-backed identity ensures that high-performing miners gain verifiable reputation within the HCLD registry. | ### **VIP Tier Integration and Governance Rights** Each **VIP Tier** links staking commitment to both technical capacity and governance reach: | **Tier** | **Stake Requirement (**HCLD**)** | **GPU Slots** | **Governance Vote Weight** | | ---------------- | ------------------------------------------ | ------------------------ | -------------------------- | | **Tier 0** | 0 HCLD | 1 GPU | 1× | | **Tier 1** | 1,000 HCLD | 2 GPUs | 1.25× | | **Tier 2** | 5,000 HCLD | 4 GPUs | 1.5× | | **Tier 3** | 10,000 HCLD | 8 GPUs | 2× | | **Tier 4 (VIP)** | 25,000 HCLD + Verification Status | 12 GPUs + priority tasks | 2.5× | # Installation Guide {% stepper %} {% step %} ### Download Installer Visit the official HashCloud website or GitHub repository and download the installer for your operating system. {% endstep %} {% step %} ### Install Dependencies Run the CLI installer: {% code title="Install CLI" %} ``` ``` {% endcode %} ```bash pip install HCLD-cli ``` Ensure GPU drivers and CUDA/ROCm are installed. {% endstep %} {% step %} ### Initialize Miner Run the initialization command: {% code title="Initialize" %} ``` ``` {% endcode %} ```bash HCLD-cli init ``` This command detects GPUs, creates the identity file, and registers the miner. {% endstep %} {% step %} ### Start Mining Start the miner with: {% code title="Start" %} ``` ``` {% endcode %} ```bash HCLD-cli start ``` The miner will begin fetching challenges and submitting proofs. {% endstep %} {% endstepper %} # Hardware Requirements ### **Overview** HashCloud is engineered to be **GPU-friendly**, **cross-platform**, and **scalable**, allowing participation from a broad spectrum of hardware configurations from standard consumer GPUs to enterprise-grade compute systems.\ This inclusivity ensures that both individual miners and institutional contributors can engage with the network efficiently, fostering decentralized distribution and hardware diversity. By standardizing minimum and recommended requirements, HashCloud guarantees stable performance, verifiable computation, and fairness across all participants. ### **Minimum Requirements** These specifications represent the baseline configuration required to participate in the network and perform deterministic compute tasks effectively. | **Component** | **Specification** | | ------------- | ------------------------------- | | **GPU** | GTX 1050 / RX 560 or equivalent | | **VRAM** | 4 GB | | **RAM** | 8 GB | | **OS** | Windows, Linux, or macOS | | **CPU** | Dual-core processor or higher | **Purpose:**\ Designed for entry-level miners who wish to participate in Proof-of-Compute validation without requiring specialized hardware. This tier aligns with **Free or VIP1** staking levels and allows fair participation using consumer-grade GPUs. ### **Recommended Requirements** For optimal performance and stable participation, the following configuration is recommended. This setup ensures consistent computation rates and minimizes task verification delays. | **Component** | **Specification** | | ------------- | -------------------------------- | | **GPU** | RTX 3060 or higher | | **VRAM** | 12 GB | | **RAM** | 16 GB | | **Storage** | Solid-State Drive (SSD) | | **OS** | Linux or Windows (latest builds) | **Purpose:**\ This configuration represents the performance sweet spot powerful enough for efficient matrix operations while maintaining affordability. It aligns with **VIP2 or VIP3** tiers and balances cost-efficiency with high throughput. ### **High-End Compute Tier** The high-end configuration supports enterprise-level compute capacity for advanced miners or compute pool operators seeking maximum efficiency and sustained workloads. | **Component** | **Specification** | | ------------- | ---------------------------------------------------- | | **GPU** | RTX 4090 / NVIDIA A100 / AMD MI300 | | **VRAM** | 24 GB or greater | | **OS** | Linux or enterprise-grade operating system | | **RAM** | 32 GB or more (recommended for data-intensive tasks) | **Purpose:**\ This tier is intended for institutional-grade nodes or advanced miners operating in **VIP4 and above** tiers. These setups contribute significant compute power and help stabilize overall network performance, particularly during large-scale workload assignments. ### **Hardware Fairness Policy** HashCloud’s hardware framework is designed to prevent centralization and ensure that performance advantages remain bounded by **VIP staking tiers** rather than unlimited hardware scaling. #### **Key Safeguards** * **Tier Alignment:** Each VIP level enforces specific GPU and VRAM limits (see Section 9: Hardware Tiering). * **Verification via UUID & VRAM:** The backend authenticates GPU identifiers to prevent spoofing or multi-instance abuse. * **Normalized Scoring:** Compute performance is normalized, ensuring that rewards scale proportionally rather than exponentially with hardware. These measures guarantee a balanced mining environment where competitiveness is determined by both compute contribution and staking commitment. ### **Compatibility & Cross-Platform Support** HashCloud supports multiple environments to ensure broad accessibility: * **Operating Systems:** Windows, Linux, and macOS (for non-enterprise nodes). * **Compute APIs:** CUDA, ROCm, and OpenCL for cross-vendor GPU compatibility. * **Network Efficiency:** Optimized task distribution protocol minimizes bandwidth usage, enabling participation even from remote or lower-bandwidth regions. By maintaining a hardware-agnostic framework, HashCloud lowers the barrier to entry while supporting high-performance scalability for professional operations. ### **Summary** | **Tier** | **Intended User** | **GPU Range** | **Alignment** | | --------------- | ------------------------------ | ------------------- | ------------- | | **Entry-Level** | Hobby / New Miner | GTX 1050–RX 560 | Free / VIP1 | | **Mid-Tier** | Regular Contributor | RTX 3060–4070 | VIP2 / VIP3 | | **High-End** | Professional / Enterprise Node | RTX 4090–A100–MI300 | VIP4+ | This tiered requirement system reflects HashCloud’s philosophy of **scalable fairness**, ensuring that every GPU regardless of class can contribute productively to the network’s decentralized compute layer. # Software Requirements ### **Overview** To ensure the smooth and secure operation of the HashCloud **Compute Network**, all miners must utilize verified and supported software components.\ The software stack has been carefully designed to maintain deterministic computations, reliable backend communication, and full compatibility across different GPU environments and operating systems. By following these software guidelines, miners guarantee the integrity of computation results and ensure compliance with the Proof-of-Compute verification framework. {% hint style="success" %} ✅ Required Software {% endhint %} * These components are **mandatory** for all miners participating in the HCLD network.\ They ensure proper GPU recognition, backend synchronization, and verified cryptographic proof submission. | **Component** | **Requirement / Description** | | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **GPU Drivers** | Latest stable versions supporting CUDA (for NVIDIA), ROCm (for AMD), or Metal (for macOS). Drivers must match the GPU architecture to guarantee deterministic computation. | | HashCloud**Compute CLI (**HCLD**`-cli`)** | The official HCLD mining client responsible for challenge retrieval, matrix computation, proof generation, and result submission. | | **Python 3.10+** | Required for diagnostic modules, benchmarking tools, and optional compute verification scripts. Ensures compatibility with backend-API testing and miner performance reporting. | | **HTTPS Support** | Encrypted communication protocol required for backend API interaction, miner authentication, and secure proof submission. | * Each of these components is critical to maintaining cross-platform uniformity and the security of all compute transactions. {% hint style="info" %} Optional Tools {% endhint %} * While not mandatory, these optional tools significantly enhance miner performance, monitoring, and security in isolated or multi-system environments. | **Tool** | **Description** | | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Docker Containers** | Enable miners to run isolated environments, ensuring predictable behavior and easy deployment across systems without dependency conflicts. Ideal for large-scale or enterprise setups. | | **Benchmark Scripts** | Provide real-time performance metrics for GPU efficiency, allowing miners to fine-tune settings and compare their output with the global compute average. Useful for verifying optimal configuration. | These tools contribute to consistent performance and secure scalability, especially when operating multiple rigs or managing compute clusters. ### **Software Integrity and Verification** To protect against tampering, malware, or result manipulation, all HCLD software components are verified via digital signatures and checksum validation at runtime. #### **Integrity Framework** * **Official Repository Access:** All CLI and API modules must be downloaded exclusively from the verified HashCloud repositories. * **Automatic Update System:** The mining client automatically checks for new releases, ensuring miners run the latest stable build. * **Checksum Validation:** Each binary includes SHA-256 signatures to confirm file integrity. * **Encrypted Communication:** All backend interactions use HTTPS with TLS 1.3 for proof submission and telemetry exchange. This layered verification ensures the network remains secure and that all miners operate on consistent, trusted software versions. ### **Cross-Platform Compatibility** HashCloud is compatible with major operating systems and compute frameworks to maximize accessibility for global miners. | **Operating System** | **Supported Frameworks** | | -------------------------------- | --------------------------------------------------- | | **Windows 10/11** | NVIDIA CUDA, AMD ROCm (via WSL2), HTTPS-enabled CLI | | **Linux (Ubuntu, Arch, Debian)** | CUDA, ROCm, OpenCL full support | | **macOS (Intel & M-series)** | Metal API support and Python CLI testing tools | This ensures a seamless experience for diverse hardware ecosystems, allowing contributors from all environments to join the decentralized compute network. ### **Purpose and Network Impact** The software requirement policy guarantees: * **Consistency:** Every miner runs the same validated codebase. * **Security:** All computation proofs and telemetry data remain encrypted and verifiable. * **Scalability:** Uniform environments enable easier onboarding for new miners. * **Performance Assurance:** Verified drivers and frameworks maximize GPU output consistency across the network. In combination with the hardware standards defined previously, this framework forms the **technical foundation** of the HashCloud compute layer. # Troubleshooting & FAQ ### **Overview** The **Troubleshooting and FAQ** section provides miners with quick solutions to common technical issues encountered during setup or operation of the HashCloud system.\ By addressing driver conflicts, verification errors, and performance issues, this section helps maintain consistent uptime and optimal compute performance across all hardware tiers.
❓ GPU Not Detected **Symptoms:**\ The HashCloud client (`HCLD-cli`) does not recognize any available GPUs. **Possible Causes:** * Outdated or missing GPU drivers * Incorrect CUDA / ROCm installation * Hardware detection issues after system updates **Solution:** * Update to the latest GPU drivers. * Reboot your system. * Verify that **CUDA (NVIDIA)** or **ROCm (AMD)** is correctly installed. * Confirm that your OS has proper GPU permissions for the mining process.
❓ “VRAM Exceeds VIP Tier” **Symptoms:**\ The backend rejects mining authorization with a VRAM mismatch warning. **Possible Causes:** * The GPU has more VRAM than allowed by the current VIP level. * Configuration file references more GPUs than permitted under your tier. **Solution:** * Upgrade your **VIP tier** to unlock additional GPU or VRAM capacity. * Alternatively, reduce the GPU count or select compliant hardware per tier (see Section 9: Hardware Tiering).
❓ Backend Rejecting Proofs **Symptoms:**\ The backend server consistently rejects proof submissions. **Possible Causes:** * Local clock desynchronization * Network latency or expired challenge windows * Invalid computation or altered proof packets **Solution:** * Sync your system clock with a reliable **NTP server**. * Ensure your internet connection is stable. * Confirm that challenges are executed and submitted before expiration. * Restart the miner if the issue persists, as it may refresh expired sessions.
❓ Performance is Low **Symptoms:**\ Mining output or performance scores appear below expected levels. **Possible Causes:** * GPU underclocking or thermal throttling * Oversized matrix computation relative to GPU capability * Background applications consuming GPU resources **Solution:** * Lower matrix size manually using **local configuration mode**. * Monitor GPU temperatures and fan speed to avoid thermal throttling. * Close unnecessary background applications. * Run a benchmark test (`HCLD-cli benchmark`) to recalibrate difficulty.
❓ Miner Crashes **Symptoms:**\ The mining client stops responding or closes unexpectedly. **Possible Causes:** * Memory leaks or unstable GPU overclocks * Driver conflicts or failed updates * Incomplete installation of required dependencies **Solution:** * Run the built-in diagnostic mode: ``` HCLD-cli diagnose ``` * Review the generated report for driver or dependency errors. * Reinstall the HashCloud **CLI** or update GPU drivers. * Use default GPU clock settings for stable operation.
### **Additional Support Resources** If issues persist, miners can access official support channels: * **Community Discord:** Real-time help and configuration advice from moderators and veteran miners. * **Documentation Portal:** Technical setup guides, driver troubleshooting, and performance optimization tutorials. * **Email Support:** Direct contact with the HashCloud technical team for advanced diagnostics. ### **Best Practices for Stability** To maintain continuous uptime and efficiency: * Regularly update the mining client and dependencies. * Avoid overclocking beyond stable GPU thresholds. * Periodically benchmark and calibrate difficulty levels. * Monitor system logs for unusual compute activity. Following these guidelines ensures reliable performance and contributes to the network’s overall compute integrity. # Developer API Endpoints ### **Overview** The HashCloud **Developer API** provides a secure and verifiable interface for miners to communicate with the network backend.\ Through this API, mining clients can fetch computational challenges, submit proofs, query historical performance, and retrieve pending rewards.\ Each interaction is cryptographically validated to ensure data authenticity, miner identity verification, and network-wide synchronization. The API serves as the foundation for decentralized compute interaction, enabling miners, pool operators, and analytic dashboards to integrate directly with the **Proof-of-Compute** protocol in real time. ### **Core Endpoints** | **Method** | **Path** | **Description** | | ---------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **GET** | `/challenge` | Fetches a new deterministic matrix computation challenge for the miner. Each challenge includes matrix parameters, seed data, and time constraints. | | **POST** | `/submit-proof` | Submits a miner’s computed proof result for backend verification. The proof packet must include hashes, timestamps, and cryptographic signatures. | | **GET** | `/performance` | Retrieves a miner’s historical performance data, including verified computation scores and task efficiency metrics. Useful for benchmarking and diagnostics. | | **GET** | `/rewards` | Queries pending daily rewards for the authenticated miner. Returns token distribution data for the most recent emission cycle. | {% hint style="info" %} * All endpoints require wallet authentication. * Responses are cryptographically hashed for integrity. {% endhint %} ### **Authentication and Security** To maintain trustless integrity, all API requests require cryptographic authentication tied to the miner’s registered wallet.\ This ensures that only authorized participants can submit proofs or claim rewards. #### **Authentication Model** * **Wallet-Based Authorization:** Each API call must include a valid wallet signature for identity verification. * **Nonce Validation:** Every request includes a unique nonce to prevent replay attacks. * **Encrypted Transport:** All communication between clients and the backend uses **HTTPS (TLS 1.3)** to safeguard sensitive data. * **Signature Integrity:** Proofs and payloads are hashed and signed before transmission to ensure immutability. By integrating cryptographic standards directly into the protocol layer, the HashCloud API guarantees that all interactions remain verifiable, secure, and tamper-resistant. ### **Response Format** All API responses are structured in standardized JSON format, ensuring easy integration with mining software, monitoring tools, and third-party dashboards. #### **Example Response — `/challenge`** ```json { "challenge_id": "0x8a5b...", "matrix_size": 512, "seed": "0x7f91...", "issued_at": "2025-10-30T00:00:00Z", "expires_in": 600 } ``` #### **Example Response — `/submit-proof`** ```json { "status": "verified", "compute_score": 4821, "reward_estimate": 12.45, "timestamp": "2025-10-30T00:10:00Z" } ``` These outputs allow miners to monitor compute cycles, analyze performance, and confirm that their results were successfully verified. ### **Error Handling** | **Error Code** | **Description** | **Recommended Action** | | -------------- | -------------------------------------------------- | ------------------------------------------ | | **401** | Unauthorized request or invalid wallet signature | Reauthenticate wallet and retry submission | | **403** | Proof submission rejected due to expired challenge | Fetch a new challenge and recompute proof | | **429** | Too many requests from miner | Implement rate-limiting or delay retries | | **500** | Internal backend error | Wait a few minutes and resubmit proof | All responses include a descriptive error message to guide miners in resolving API-related issues quickly. ### **Developer Notes** * All endpoints require **wallet authentication** prior to submission or query. * Responses are **cryptographically hashed** for verification and logged by the backend for auditing. * Rate limits may apply per node to ensure network stability. * API documentation will evolve as new endpoints are added for governance, staking, and compute leasing. Developers integrating with HashCloud should regularly monitor the official documentation repository for version updates, schema changes, and security advisories. ### **Purpose and Design Intent** The HashCloud API was designed with three guiding principles: 1. **Transparency:** Every response is verifiable and traceable through blockchain-integrated proofs. 2. **Security:** End-to-end encryption and signature verification ensure only legitimate miners interact with the network. 3. **Interoperability:** The use of open standards and JSON-based schemas enables easy adoption by third-party developers, monitoring dashboards, and mining pools. Through these standards, the API becomes a **trust anchor** for the entire HashCloud compute economy bridging the gap between decentralized hardware and verifiable digital reward systems. # Economics Model ### **Overview** The HashCloud **(**HCLD**)** token follows a predictable and mathematically transparent emissions schedule designed to balance long-term sustainability, miner incentives, and network stability.\ By utilizing a **deterministic emission curve**, HCLD ensures that token issuance remains controlled and finite, reducing the risks of uncontrolled inflation while maintaining sufficient liquidity for network operations. This model allows miners, stakers, and developers to forecast reward outputs accurately creating a transparent foundation for economic participation in the Proof-of-Compute ecosystem. ## ✅ **Total Supply:** `100,000,000 HCLD` The total token supply is permanently capped at **100 million** HCLD, ensuring fixed scarcity and preventing future inflationary adjustments.\ This cap reflects HashCloud’s commitment to long-term deflationary value and predictable tokenomics. ## Linear Daily Emissions (Base Model) The **base emission model** releases tokens at a constant linear rate throughout the emission period: $$\frac{60,000,000 HCLD}{1,460 \text{ days}} \approx 41,095 HCLD/\text{day}$$ This model ensures predictable miner rewards and avoids sudden emission shocks that could destabilize token value or mining participation.\ Under this linear schedule, all 60 million HCLD allocated to mining will be distributed evenly across the 4-year period. ### **Optional Halving Model** HCLD may adopt a **Bitcoin-inspired halving model**, in which emission rates are reduced by half every year.\ This approach introduces controlled scarcity, strengthens early adoption incentives, and enhances the long-term deflationary mechanics of the protocol. | **Year** | **Daily Emission (**HCLD**)** | **Annual Output (**HCLD**)** | | -------- | --------------------------------------- | -------------------------------------- | | **1** | 41,095 | 15,000,000 | | **2** | 20,547 | 7,500,000 | | **3** | 10,273 | 3,750,000 | | **4** | 5,136 | 1,875,000 | At the end of the four-year emission cycle, the total mined allocation equals the same **60,000,000** HCLD, but distributed on a diminishing curve that benefits early participants. {% hint style="info" %} ### **Benefits of the Emission Model** ⚙️ **Predictable Rewards:**\ The fixed schedule allows miners to forecast long-term profitability and plan hardware ROI cycles effectively. 💰 **Sustained Mining Incentives:**\ By distributing a majority of tokens through Proof-of-Compute, the system encourages continuous participation and ensures computational stability across the network. 🚀 **Early Adoption Advantage:**\ The optional halving mechanism motivates early engagement, rewarding miners who contribute during the network’s foundational phase. 🔥 **Deflationary Pressure:**\ As block rewards diminish over time, the circulating supply growth rate decreases potentially increasing token scarcity and value over the long term. 🌐 **Governance Adaptability:**\ Future protocol upgrades may enable dynamic emission adjustments via decentralized governance, allowing the community to modify inflation schedules, halving frequency, or redistribution models. {% endhint %} ### **Long-Term Sustainability** The combination of a capped supply, predictable distribution, and flexible emission models positions HCLD as a **sustainable utility asset** rather than an inflationary token.\ This ensures that both miners and token holders can rely on a **transparent, fair, and economically balanced ecosystem**. In future versions, HashCloud governance may propose: * Adaptive emission throttling based on compute network demand * Allocation extensions for infrastructure or development funds * Burn mechanisms to counteract token oversupply These mechanisms allow the HCLD token economy to evolve with technological and market conditions without compromising decentralization or fairness. # Problem Statement ### **Context** The current cryptocurrency mining landscape is increasingly constrained by centralization, inefficiency, and inequity. Traditional Proof-of-Work (PoW) systems consume vast amounts of energy on tasks with no external utility, while the rise of ASIC hardware has locked ordinary GPU owners out of fair participation.\ ashCloud addresses these core structural flaws through a redesigned compute protocol that redefines mining around **verifiable, useful computation**. {% hint style="danger" %} #### ⚠ Current Issues * ⚠️ **ASIC Centralization:**\ Most Proof-of-Work chains are dominated by specialized ASIC devices, creating high entry barriers and consolidating power among industrial-scale operations. This centralization undermines the decentralized ethos of blockchain technology. ⚠️ **Unfair Token Launches:**\ Many modern projects rely on pre-mines or VC allocations, giving disproportionate token control to early investors rather than active network contributors. ⚠️ **Wasted Computation:**\ Traditional mining relies on solving arbitrary cryptographic puzzles that have no intrinsic value beyond consensus security, wasting massive amounts of computational power and energy. ⚠️ **Hardware Inequality:**\ The profitability gap between consumer GPUs and industrial mining hardware widens continuously, discouraging community-level participation. {% endhint %} {% hint style="success" %} #### 🎯 HCLD Solution ✅ HashCloud **(**HCLD**)** introduces the **Proof-of-Compute (PoC)** protocol a paradigm shift from energy-wasting hash puzzles to deterministic, verifiable matrix computation.\ Every GPU cycle contributes measurable, real-world computational value while maintaining decentralization and transparency. #### **Core Design Principles** * **Deterministic Computation:** All assigned tasks produce verifiable mathematical results. * **Performance-Based Rewards:** Token rewards scale according to measured computational throughput, ensuring meritocratic distribution. * **Fair Staking (Non-Rewarded):** Staking determines access to mining slots and performance multipliers, but avoids passive income mechanisms. * **Hardware Integrity Verification:** The system validates GPU hardware signatures to prevent spoofing and ensure fair participation. {% endhint %} ### **Directly Addressed Challenges** 1. **Centralized Token Distribution**\ HCLD redistributes issuance power to miners rather than investors, establishing a **community-first reward structure**. 2. **ASIC Dominance**\ HCLD is **GPU-friendly and ASIC-resistant**, preserving accessibility for everyday users and promoting broad decentralization. 3. **Wasted Compute**\ HCLD transforms raw GPU cycles into **deterministic, verifiable matrix computations**, converting mining into a **useful and measurable task** rather than random hashing. ### **Comparative Overview** | **Issue** | **Traditional PoW / VC-Backed Projects** | HashCloud **(**HCLD**)** | | ---------------------- | ------------------------------------------- | --------------------------------------------- | | **Token Distribution** | Centralized pre-mines & venture allocations | Community-first, miner-owned issuance | | **Computation Type** | Arbitrary hashing (non-useful) | Deterministic linear algebra (useful compute) | | **Hardware Dominance** | ASIC-dominated, exclusionary | GPU-first, consumer-friendly and inclusive | ### **Summary** HashCloud resolves the fundamental inefficiencies of modern mining by merging **Proof-of-Work decentralization** with **Proof-of-Compute utility**.\ Through deterministic workloads, verifiable computation proofs, and a fair reward architecture, HCLD establishes a new equilibrium between energy use, network security, and real computational productivity. It restores the original vision of mining open participation, fairness, and tangible contribution to the digital economy. # Merkle Proof of Compute HashCloud ## 1. Introduction **HashCloud** uses **deterministic GPU computation** and **Merkle-rooted digest commitments** to validate miner proofs efficiently, securely, and with minimal bandwidth. Instead of verifying every GPU-computed loop, the network performs **probabilistic Merkle subset auditing**, drastically reducing server CPU load while maintaining strong cheating detection.\ This method forms the foundation of **Merkle-Proof-of-Compute (M-PoC)** a cryptographic system ensuring that miners genuinely perform the work they claim, at a tiny verification cost. ## 2. Purpose The **M-PoC protocol** verifies that miners truly execute GPU computations without forcing the verifier to recompute the entire workload. It is designed to achieve: * ✅ **High fraud detection probability** * 📶 **Low bandwidth usage** * ⚙️ **Low server CPU load** * ⚡ **Compatibility with high-speed GPUs** * 📈 **Scalable deterministic verification** via matrix multiplications (matmul) ## 3. Key Terminology | Term | Description | | --------------------- | ---------------------------------------------------------------- | | **Loop** | One deterministic GPU compute iteration (e.g., matrix multiply). | | **Leaf** | SHA-256 digest derived from a loop’s seed and output. | | **Merkle Root** | The top hash committing all loop leaves. | | **Sample Leaf** | A subset of leaves (and their proofs) sent to the verifier. | | **Audit Set (m)** | Number of sample leaves verified by the server. | | **Digest Commitment** | The miner’s proof of computation (Merkle root). | ## 4. Core Concept – Merkle Commitment + Random Auditing Each miner commits all loop results into a **Merkle tree** of digests but only transmits **s sampled leaves** with their Merkle proofs. Why It Works * The **Merkle root** cryptographically binds all loop digests the miner cannot alter missing parts. * The **server only recomputes** a random subset (**m**) of the submitted sample leaves. * If **any audited leaf fails**, the miner is caught instantly. * To cheat safely, the attacker must compute nearly all genuine leaves rendering cheating pointless. ## 5. High-Level Protocol Flow ### Miner Steps {% stepper %} {% step %} ### Receive challenge payload Payload structure: ``` { seed, challenge_id, expiry, token } ``` {% endstep %} {% step %} ### Compute deterministic GPU loops for duration T Pseudo: ``` for each loop i: loop_seed_i = seed || ":" || i output_i = deterministic_matmul(loop_seed_i) leaf_i = SHA256(loop_seed_i || output_i) ``` {% endstep %} {% step %} ### Build Merkle tree Obtain `merkle_root` committing all leaves. {% endstep %} {% step %} ### Select samples Select **s** sample indices distributed across all loops. {% endstep %} {% step %} ### Submit proof payload Example JSON: ```json { "challenge_id": "...", "token": "...", "seed": "...", "loops": 12345, "compute_time": 14.21, "merkle_root": "0x...", "samples": [ { "index": 123, "leaf": "0x...", "proof": ["0x...", "..."] } ], "device_signature": "0x..." } ``` {% endstep %} {% endstepper %} ### Server Steps {% stepper %} {% step %} ### Validate credentials and sanity checks * Validate `token` and `device_signature`. * Sanity-check loop count, compute time, and rate limits. {% endstep %} {% step %} ### Randomly choose audit set Randomly choose **m** sample indices for audit. {% endstep %} {% step %} ### For each audited index * Recompute deterministic matmul output. * Recompute leaf hash. * Verify Merkle proof against submitted `merkle_root`. {% endstep %} {% step %} ### Decision * ✅ If all **m** pass → Accept submission * ❌ If any fail → Reject & apply penalty {% endstep %} {% endstepper %} ## 6. Default Parameters | Parameter | Symbol | Typical Value | Description | | ------------- | ------ | ------------- | -------------------------------- | | Sample count | s | 10 | Leaves submitted per proof | | Audit count | m | 3 | Random leaves verified by server | | Loop duration | T | Dynamic | Mining challenge duration | | Hash function | — | SHA-256 | Used for leaves and Merkle nodes | ## 7. Detection Probability If a miner forges **X** leaves out of **s** samples, and the server audits **m** random samples, the probability of catching the cheat is: $$ P\_{detect} = 1 - \frac{\binom{s - X}{m}}{\binom{s}{m}} $$ Example:\ `s = 10`, `m = 3`\ Even if only a few samples are forged, detection probability approaches 99%. Therefore, miners gain no real advantage by cheating. ## 8. Server Audit Logic The server **dynamically adjusts audit probability** based on: * Claimed compute speed vs. device profile * Loop-to-time ratio consistency * Historical miner accuracy This adaptivity ensures stronger audits for suspicious or near-limit behavior while minimizing overhead for honest miners. ## 9. Developer Implementation ### Miner Pseudocode ```python for i in range(loops): output = matmul(i) leaf[i] = SHA256(seed + ":" + str(i) + output) merkle_root = build_merkle_tree(leaf) s_indices = choose_samples(loops, s) samples = [(i, leaf[i], merkle_proof(i))] submit({ "seed": seed, "loops": loops, "merkle_root": merkle_root, "samples": samples }) ``` ### Server Pseudocode ```python verify_token() verify_signature() check_limits() if should_audit(): selected = random_subset(samples, m) for idx, leaf, proof in selected: recomputed = SHA256(seed + ":" + str(idx) + matmul(idx)) assert verify_merkle_proof(leaf, proof, merkle_root) ``` ## 10. Fairness * **Fast GPUs** are not penalized results are normalized by compute time. * **Merkle audits verify correctness**, not raw speed. * **Low bandwidth** submissions make participation accessible even on constrained networks. ## 11. Best Practices & Recommendations * Use **s = 10**, **m = 3** for baseline deployments. * Increase `s` or `m` if miner behavior seems abnormal. * General rule: $$ s \approx \max(10, loops \times 0.01) $$ * Distribute sample indices evenly across the full loop range. * Always use deterministic matmul functions to ensure verifiable consistency. ## 12. Conclusion The **Merkle-Proof-of-Compute (M-PoC)** protocol is a **scalable, secure, and efficient** system for verifying deterministic GPU computations in decentralized mining environments. By combining **Merkle commitments** with **probabilistic subset audits**, M-PoC guarantees that every miner’s work is: * Cryptographically verifiable * Fraud-resistant * Lightweight to audit * Fair across heterogeneous hardware This architecture establishes a foundation for **trustless, high-throughput GPU compute validation** the core of **HashCloud’s decentralized mining framework**. # Proof of Compute Security Documentation ## Overview The **Merkle-Proof-of-Compute (M-PoC)** system is a verifiable GPU-based computation framework designed for proof-of-work style mining.\ Each computation round produces deterministic, tamper-evident proofs that can be efficiently validated by a verifier or server. This approach guarantees that all GPU workloads are: * **Deterministic** — reproducible using the same seed. * **Verifiable** — validated through Merkle root sampling. * **Bound to origin** — tied to an authenticated compiled miner client. {% stepper %} {% step %} ### Core Compute Flow — Challenge Issuance The server generates a challenge containing: * A unique random `seed` * Work parameters (`size`, `batch`, `loops`, `duration`) The random seed ensures miners cannot precompute or reuse results. {% endstep %} {% step %} ### Core Compute Flow — Deterministic GPU Compute For each loop `i`: ```python loop_seed = f"{seed}:{i}" robust_digest = sha256(C_np.astype(np.float32).tobytes()) ``` The miner performs deterministic matrix multiplications on GPU and produces a robust digest per loop. {% endstep %} {% step %} ### Core Compute Flow — Merkle Commitment Each digest is committed as a Merkle leaf: ``` leaf = H("LEAFv1" || seed || loop_index || robust_digest) ``` All leaves form a Merkle tree, yielding the final `merkle_root`. {% endstep %} {% step %} ### Core Compute Flow — Proof Submission The miner submits: ```json { "seed": "...", "merkle_root": "...", "loops": N, "compute_time": T, "merkle_levels": [...] } ``` {% endstep %} {% step %} ### Core Compute Flow — Server Verification The server randomly samples `k` loop indices, recomputes those digests using the original seed, reconstructs their Merkle proofs, and checks for consistency with the reported `merkle_root`.\ Any mismatch invalidates the proof. {% endstep %} {% endstepper %} *** ## Security Architecture | Layer | Purpose | Status | | ---------------------------------- | ------------------------------------------- | ------ | | **Server-issued seed** | Prevents precomputation and replay | ✅ | | **Per-loop seed binding** | Enforces unique digest per loop (`seed:i`) | ✅ | | **Merkle tree commitment** | Detects any tampering or partial work | ✅ | | **Random audit sampling** | Enables low-cost probabilistic verification | ✅ | | **Nuitka-compiled miner (`.pyd`)** | Obfuscates logic and embedded secrets | ✅ | | **App signing key** | Authenticates official miner builds | ✅ | | **GPU hardware binding** | Associates proofs with a specific GPU UUID | ✅ | *** ## Security Achievements | Threat | Mitigation | | -------------------------- | ------------------------------------------- | | **Fake GPU work** | Merkle commitment + seed audit verification | | **Replay / reuse attacks** | Unique server-issued seed per challenge | | **Digest manipulation** | Merkle root verification | | **Binary modification** | `.pyd` self-hash and signing key check | | **Binary cloning** | GPU UUID + app key pairing | | **Offline forgery** | Unpredictable seed generation by server | *** ## Miner Identity & Authenticity * **Binary Hash**\ Each miner self-hashes its `.pyd` binary using SHA-256 and sends the result to the server.\ The server maintains a whitelist of valid build hashes. * **Application Private Key**\ A private signing key is embedded within the compiled binary (protected and obfuscated).\ The miner signs `(seed + merkle_root + gpu_uuid)` before submission. * **Server Verification**\ The server verifies the signature using the corresponding public key, confirming that the proof originated from an official build and a registered GPU. *** ## Final Notes * The miner’s deterministic path (`seed → matmul → digest → Merkle`) ensures all verifications are reproducible. * TF32 enforcement is removed as it’s not security-critical. * The compiled `.pyd` binaries act as authenticated, tamper-resistant clients. * Cloning the binary is ineffective since each proof is tied to both the GPU identity and the server-issued challenge. {% hint style="success" %} Final Verdict:\ The current system — *Merkle-Proof-of-Compute + Server-Seeded Challenges + Compiled & Signed Nuitka Miner* — forms a robust, multi-layer proof-of-work verification model that is both tamper-evident and cryptographically secure. This achieves lightweight, auditable, and cheat-resistant GPU compute verification. 🚀 {% endhint %}