> For the complete documentation index, see [llms.txt](https://halowave.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://halowave.gitbook.io/docs/tokenomics-and-rewards/mining-mechanics-and-network-incentives.md).

# Mining Mechanics & Network Incentives

The HaLoWave network diverges from traditional decentralized infrastructure models that reward mere device presence. To ensure extreme resilience, commercial viability, and optimal geographic distribution, the economy is governed by the **Tri-Proof Architecture**: **Proof of Coverage (PoC)**, **Proof of Reliability (PoR)**, and **Proof of Data Transfer (PoDT)**.

This section details the exact mathematical models, validation rules, and network incentives that dictate how a HaLoWave Miner generates rewards.

***

### 1. The Master Equation

The network measures performance and distributes rewards in discrete time windows called **Epochs**. Each epoch lasts exactly 10 minutes, resulting in a total of **144 Epochs** per 24-hour cycle. During each epoch, the miner performs a "heartbeat" to cryptographically prove its active status to the network.

During the current Beta and Testnet phase, all daily rewards are calculated in **Points**. The final reward generation is governed by the following master equation:

**Daily Points = (R\_up \* M\_poc \* M\_data) \* V\_gps \* P\_hex**

Each variable represents a specific hardware or network metric, detailed below.

***

### 2. Base Uptime (R\_up)

The foundation of the network is physical reliability. The `R_up` variable measures the continuous online presence of the miner.

* **Metric:** If your miner is connected to the internet and power for all 144 epochs in a day, it receives the full baseline of **100 points**.
* **Penalty:** If the device loses power or internet connectivity, the baseline points drop proportionally for every missed epoch.

***

### 3. Proof of Reliability (PoR) & GPS Validation (V\_gps)

Because HaLoWave builds a physical radio frequency infrastructure, verifying the exact geographic origin of a signal is an absolute priority. The Proof of Reliability (PoR) mechanism utilizes the exact hardware GPS position of the HaLoWave miners to validate the integrity of the network and completely block location spoofing.

**Important Note on RF Quality:** The HaLoWave protocol does not use RSSI (Received Signal Strength Indicator) for scoring. Signal strength fluctuations do not negatively impact your rewards. If two miners successfully communicate, the link is valid regardless of the physical signal strength, provided it passes the PoR geometry check.

* **The PoR Anti-Spoofing Check:** When miners send beacons or witness each other, the PoR algorithm utilizes their exact GPS coordinates to mathematically verify the physical distance between them. If the reported distance exceeds the maximum plausible limits of HaLow RF physics, the interaction is flagged as spoofed and instantly rejected.
* **The Rule:** If your GPS antenna cannot secure a satellite lock (e.g., placed inside a concrete basement without windows), the device cannot validate its coverage area.
* **Placement Requirement:** The GPS antenna must be placed near a window or, ideally, outdoors with a clear view of the sky.
* **Impact (V\_gps):** Your daily points are multiplied by the percentage of the day you held an active GPS fix.

**Examples:**

1. A miner has 100% uptime but only secures a GPS fix for 72 epochs (half a day). The `V_gps` factor is 0.5. The entire daily point calculation is multiplied by 0.5.
2. A miner has 100% uptime but is located deep indoors with 0% GPS fix. The `V_gps` factor is 0.0. The total daily reward is strictly 0.

***

### 4. Proof of Coverage (PoC) & Mutual Witnessing (M\_poc)

The Proof of Coverage (PoC) module rewards operators for successfully sending and receiving radio beacons with surrounding network nodes. To maintain economic balance alongside the Data Transfer multiplier, the PoC multiplier is capped.

* **Multiplier Range:** Scales from **1.0x (Isolated)** up to a hard cap of **3.0x (High density)**.
* **Beaconing Frequency:** Every HaLoWave Miner automatically transmits a cryptographic beacon once every 10 minutes. This consistent interval allows surrounding hardware to witness the signal and reliably map the RF network.
* **Isolated Miners:** If a miner is deployed in an isolated geographic zone with no other miners nearby, it does not receive the PoC multiplier boost (`M_poc = 1.0x`). However, the miner still earns its base uptime points multiplied by its GPS and Hex factors, provided it continuously and successfully transmits its 10-minute PoC beacons.
* **Mutual Coverage Requirement:** For a link to be scored, it must be mutual. If Miner A and Miner B both witness each other’s HaLow beacons within the scoring window, they count each other as a verified peer.
* **Calculation:** For each mutual peer, the contribution is based strictly on how often the link was mutually witnessed over the 24-hour cycle (the overlap rate).
* **Diminishing Returns & Hard Cap:** The "Effective Peers" (`P_eff`) are summed and applied to a square-root curve. A single full-day peer automatically doubles your base rewards (2.0x). However, to prevent abusive clustering, the multiplier is strictly hard-capped at 3.0x (achieved with 4 full-day peers). Extra neighbors beyond this threshold do not keep stacking.

**Formula 1: Effective Peers** `P_eff = Sum of [ (E_poc,i / 144) ] for all mutual peers N` *(Each mutual peer contributes up to a maximum of 1.0 based solely on the overlap rate).*

**Formula 2: PoC Multiplier** `M_poc = min(3.0, 1 + √(P_eff))`

**Example:** Miner A mutually witnesses 3 unique peers for the full 24-hour day. Total `P_eff` = 3.0. Multiplier = 1 + √(3.0) = approximately 2.73x.

***

### 5. Proof of Data Transfer (PoDT) (M\_data)

The core utility of the network is routing data for enterprise clients. The Proof of Data Transfer (PoDT) module acts as the primary utility multiplier. If third-party devices (such as generic HaLow cameras, HaLow drones, or HaLow agricultural sensors) use the HaLoWave Network through your miner, you are rewarded heavily based on real client traffic (not miner beacon noise). This is how isolated miners still earn well, and how the highest daily rewards are reached.

* **Multiplier Range:** Scales from **1.0x (No data)** up to a hard cap of **3.0x (Heavy data usage)**.
* **Fair-Volume Curve:** The protocol analyzes the rolling 24-hour data volume (B). To reward low-bandwidth, high-value sensors (like agricultural soil monitors) just as fairly as heavy devices (like cameras), the protocol uses a piecewise dynamic linear curve.
* **Anti-Abuse Cap:** The maximum data threshold is strictly hard-capped at **50 GB/day**. Processing data beyond this cap does not stack rewards indefinitely, thereby mathematically preventing abusive data farming.

#### The Volume Anchor Points

* If B < 1 MB: M\_data = **1.00x** (Floor)
* Between **1 MB** and **5 MB**: M\_data scales linearly from 1.00x to **1.50x**
* Between **5 MB** and **5 GB**: M\_data scales linearly up to **2.00x**
* Between **5 GB** and **50 GB**: M\_data scales linearly up to **3.00x** (Hard Cap) *(All values falling between these anchor points are calculated using exact piecewise linear interpolation).*

**Volume Multiplier Interpolation Table:**

| Daily Data Pushed (B) | Approx. Volume Multiplier | Realistic Device Example                           |
| --------------------- | ------------------------- | -------------------------------------------------- |
| < 1 MB                | **1.00x**                 | Idle Miner                                         |
| 5 MB                  | **1.50x**                 | Generic HaLow agricultural soil sensors            |
| 1 GB                  | **\~1.60x**               | Basic telemetry from tracking systems              |
| 5 GB                  | **2.00x**                 | Fleet of HaLow drones routing telemetry            |
| 10 GB                 | **\~2.11x**               | Standard HaLow security camera                     |
| 25 GB                 | **\~2.44x**               | Busy logistics yard                                |
| 50 GB+                | **3.00x**                 | Massive enterprise logistics deployment (Hard Cap) |

#### Regional Home Broadband Caps & Data Penalties

To ensure network compliance globally, HaLoWave introduces dynamic bandwidth controls tailored to regional radio regulatory requirements.

* **Duty-Cycle Countries (e.g., Europe):** Due to strict local radio regulations, sub-GHz HaLow throughput in these regions is legally capped at approximately 8 Mbps. Because the miner already runs at the maximum permissible speed automatically, no manual adjustment is needed. Operators in these regions automatically receive 100% of their generated data rewards without penalty.
* **Non-Duty-Cycle Countries (e.g., the US):** In regions without these duty-cycle restrictions, speeds can reach up to 43 Mbps. If operators prefer not to share their full home bandwidth with the network, they can manually lower their broadband cap down to a minimum of 20 Mbps via the dashboard.

**Crucial Note on Custom Caps:** Manually lowering the bandwidth cap directly reduces the Data Transfer rewards. The network calculates a **Bandwidth Reward Factor**. If `C` is the chosen bandwidth cap in Mbps (where 20 <= C <= 43):

`Bandwidth Reward Factor = 0.50 + 0.50 * [ (C - 20) / 23 ]`

**Final M\_data Equation:** `Effective M_data = Base Volume M_data * Bandwidth Reward Factor` *(Note: In Duty-Cycle regions like Europe, this factor is permanently set to 1.0x).*

***

### 6. Hexagon Density (P\_hex)

To prevent the network from becoming oversaturated in single urban neighborhoods while rural or industrial areas remain dead zones, the global map is divided into geometric Hexagons utilizing the H3 resolution 9 standard (side size \~200 meters).

* **Provisional & Senior Status:** The first 3 miners to successfully register in an empty hex immediately receive a provisional 1.0x hex multiplier. These miners must then maintain **95% uptime over 60 days** to officially claim a locked **Senior Status**. This status acts as a strict layer of protection for early network builders: the 1.0x hex multipliers are securely held by the top 3 Active Seniors. Their rewards will never be diluted, even if dozens of new miners crowd into the same hexagon later.
* **Grace Period & Inheritance:** If an active Senior drops below the 95% uptime requirement, they enter a **14-day grace period**. If they fail to recover their hardware within this window, their Senior status is permanently lost. The next active miner in the hex (determined strictly by chronological registration time) immediately inherits the 1.0x protected slot. This mechanic creates a highly competitive "battle for uptime" that ensures continuous network resilience.
* **Provisional Miner Rule:** If a provisional miner (a user currently within the initial 60-day evaluation window) drops below 95% uptime, they immediately lose their provisional status without any grace period. The next miner in the chronological queue immediately takes over the provisional slot and starts their own 60-day timer.
* **Crowding Penalty:** Miners entering an already occupied hexagon face diminishing returns based on their absolute entry rank (`k`), which is determined by their registration timestamp.

**Density Formula:** Miners holding one of the 3 Protected Slots always receive `P_hex = 1.0` regardless of their original entry rank. For all subsequent miners without a protected slot, the reward curve diminishes based on their entry rank (`k`):

* If you hold a Protected Slot (Active or Provisional Senior): `P_hex = 1.0`
* If you do not hold a Protected Slot and your entry rank is `k` (where `k > 3`): `P_hex = 3 / k`

> **Hex Density Example:** A user discovers an excellent location, but there are already 3 active Seniors deployed there. The user installs the 4th miner (k=4). The density factor is 3/4 = 0.75. The user will earn 75% of the potential rewards, holding this position until one of the Seniors goes offline, allowing the user to inherit the protected 1.0x slot. If another user installs the 6th miner (k=6), they earn 3/6 = 50%. This economic pressure heavily incentivizes operators to deploy hardware in fresh, empty hexagons to immediately claim a provisional 1.0x multiplier.

***

### 7. Comprehensive Scenarios: Practical Examples

To illustrate how these variables interact in real-world deployments, here are 9 comprehensive operational scenarios:

* **Scenario 1: The Hero Miner (Alice)** Alice installed her antenna on her roof, securing a perfect GPS fix (144/144 epochs). She is one of the first 3 in her hex (P\_hex = 1.0). She maintains 100% uptime (R\_up = 100). She communicates perfectly with 2 nearby peers (M\_poc = 2.41). Because she is near a factory, she routes **50 GB** of data for nearby HaLow sensors all day (M\_data = 3.0). *Math:* (100 \* 2.41 \* 3.0) \* 1.0 \* 1.0 = **723 Points / Daily**
* **Scenario 2: The Lazy Miner (Bob)** Bob leaves his miner on his living room floor. It has 100% uptime (100) but struggles with GPS due to the concrete ceiling (V\_gps = 0.5). His indoor miner only mutually witnesses 1 neighbor sporadically (M\_poc ≈ 1.31). He routes **0 GB** of data (M\_data = 1.0). He is the 5th person in his hex (P\_hex = 3/5 = 0.6). *Math:* (100 \* 1.31 \* 1.0) \* 0.5 \* 0.6 = **39.3 Points / Daily**
* **Scenario 3: The Industrial Elite (Jennifer)** Jennifer installed her miner on the roof of a logistics center. *Setup:* Perfect GPS, 100% Uptime, 4 mutual neighbors for the full day (M\_poc capped at 3.0x), and routes **100 GB** of data (Hard capped at 50 GB -> 3.0x). *Math:* (100 \* 3.0 \* 3.0) \* 1.0 \* 1.0 = **900 Points / Daily**
* **Scenario 4: The Urban Drone Hub (Sophia)** Sophia is one of the first in her city with her antenna outside. *Setup:* Perfect GPS, 100% Uptime, 2 mutual neighbors (M\_poc = 2.41). She routes **5 MB** of lightweight telemetry data from a passing HaLow drone (M\_data = 1.50). *Math:* (100 \* 2.41 \* 1.50) \* 1.0 \* 1.0 = **361.5 Points / Daily**
* **Scenario 5: The Rural Relay (Marco)** Marco placed his miner near a remote water monitoring station. *Setup:* Perfect GPS, 100% Uptime, 0 neighbors (M\_poc = 1.0). He routes **5 GB** of telemetry data per day (M\_data = 2.0). *Math:* (100 \* 1.0 \* 2.0) \* 1.0 \* 1.0 = **200 Points / Daily**
* **Scenario 6: The "Basement" Farmer (John)** John put 5 miners in his basement to illicitly "farm" rewards. *Setup:* 0% GPS (No signal through concrete), 100% Uptime, 4 neighbors. Because PoR cross-references GPS, the witnessing is flagged as mathematically impossible and marked false (V\_gps = 0.0). *Math:* (100 \* 1.0 \* 1.0) \* 0.0 \* 0.6 = **0 Points / Daily**
* **Scenario 7: The Crowded Newcomer (Kevin)** Kevin joined a very popular, saturated area as the 10th miner. *Setup:* Perfect GPS, 100% Uptime, 5 neighbors (M\_poc is hard-capped at 3.0x), **0 GB** data routing. *Math:* (100 \* 3.0 \* 1.0) \* 1.0 \* 0.3 = **90 Points / Daily**
* **Scenario 8: The Capped Miner (David)** David is located in the US and has a great setup: Perfect GPS, 100% Uptime, 2 mutual neighbors (M\_poc = 2.41). He routes **50 GB** for third-party HaLow devices (potential 3.0x multiplier). However, David caps his Home Broadband at the minimum of 20 Mbps, triggering a 50% bandwidth reward factor (3.0 \* 0.5 = 1.5). *Math:* (100 \* 2.41 \* 1.5) \* 1.0 \* 1.0 = **361.5 Points / Daily**
* **Scenario 9: The Smart Farmer (Elena)** Elena installs a Miner on a mast to cover her farm. She achieves a perfect GPS fix and 100% Uptime. She mutually witnesses 1 neighbor (M\_poc = 2.0). She connects generic HaLow agricultural sensors to monitor soil moisture, generating exactly **5 MB** of daily data routing (M\_data = 1.50). *Math:* (100 \* 2.0 \* 1.50) \* 1.0 \* 1.0 = **300 Points / Daily**

***

### 8. A Second Monetization Layer: Enterprise Bandwidth Routing & Global Health Check

While the primary goal of the HaLoWave Network is to build a robust, global sub-GHz Wi-Fi HaLow infrastructure, the high volume of excess internet bandwidth passing through HaLoWave Miners allows for a highly efficient second monetization layer.

This feature, known as the **Enterprise Bandwidth Routing & Global Health Check**, allows exclusively HaLoWave Miner Owners to earn a passive payout in **$USDC on the Solana blockchain EVERY MONTH** while the main RF network scales.

To activate this feature, operators simply toggle the opt-in setting on the management dashboard at `console.halowave.io`. The entire operational experience is designed to be completely passive.

#### The Scaled Rollout

* **Phase 1 (Aggregation):** During the initial network growth phase, the Master API connects directly to established B2B aggregation pools. This generates an immediate, stable yield for node operators, drastically helping to offset hardware and energy costs from month one.
* **Phase 2 (Direct SLAs):** Upon reaching critical mass across global geographies, the protocol will bypass third-party aggregators and sign direct Service Level Agreements (SLAs) with enterprise B2B buyers, unlocking a significantly larger overall reward pool.

#### Protocol Mechanics

By opting into this feature, the HaLoWave Miner utilizes its idle broadband capacity via two secure channels:

1. **Global Health Protocol (Diagnostics):** Nodes participate in global internet health monitoring by running real-time ping tests (integrating with open telemetry networks like the RIPE NCC). This assists local and global ISPs in optimizing traffic routes and rapidly detecting regional outages.
2. **Enterprise Bandwidth Routing (B2B):** Secure routing of vetted web requests for Fortune 500 clients. Use cases include major travel and e-commerce platforms, AI data aggregators, and SEO analytics firms requiring distributed routing data.

#### Security Architecture & Compliance

Safety and strict local network isolation are foundational to this protocol layer:

* **No Exit-Node Risk:** IP addresses are never utilized as public VPNs for unverified strangers or P2P file sharing. The network strictly handles corporate, verified web requests.
* **Zero Open Ports:** The protocol operates entirely via outbound Reverse-TLS connections, requiring no port forwarding, firewall compromises, or UPnP.
* **Complete Isolation:** The bandwidth applications perform only lightweight operations separated completely from the host's private local network.
* **100% Optional:** Operators retain absolute control to toggle this feature ON or OFF via the management console at any time.
* **NO KYC:** Unlike other traditional bandwidth-sharing platforms that require mandatory identity verification, passport uploads, or KYC procedures for payouts, HaLoWave requires absolutely none. Operations and payments remain decentralized.

#### Network Integrity & Hardware Tracking

To ensure peak enterprise yield and protect the network's overall Trust Score, operators must adhere to strict bandwidth-sharing rules. Because the HaLoWave Master API connects directly to premium enterprise ingestion servers, operators must stop running personal consumer bandwidth-sharing applications (like EarnApp, Pawns, or Honeygain) on the same home network. Running these alongside HaLoWave triggers B2B load balancer anti-fraud systems due to duplicate IP node authentication, driving earnings to zero.

* **Attested On-Hardware Tracking:** Earnings are a pooled monthly $USDC reward on Solana, split by your device's **attested on-hardware bandwidth share**. Data metrics are strictly tracked directly on the physical HaLoWave device itself, not via third-party dashboards or external apps.
* **Strictly 1 Device per Residential IP:** You cannot stack multiple bandwidth-sharing devices on a single external IP address.
* **No Datacenters or VPNs:** Datacenter IPs or VPNs are automatically rejected by the enterprise networks. Routing traffic through these will result in 0 GB tracked and 0 rewards.

#### Yield Distribution & Monthly Payouts

Revenue generated from this secondary B2B path follows a strict economic split to benefit the operators:

* **90% to the Community:** Distributed directly to the participating node operators. Payments are executed directly to the exact Solana wallet address used to register the HaLoWave Miner. (Official distribution wallet address: `48Dn4iq3cFSCfz1hRa9L2gRQXARDMVH9TGRh7FWm9DoK`).
* **10% to the Treasury:** Allocated for continued network development, B2B marketing, security, and protocol maintenance. Crucially, this allocation is also used to cover all Solana transaction fees on behalf of the users, ensuring zero claim fees or gas costs for the community. (Official HaLoWave Treasury wallet address: `AyLd9affiVBeGNRNrFiN4ub2RaW7h3kmLexykHvqfswN`).

> **Payout Schedule:** Payouts are compiled and executed **MONTHLY** in **$USDC** directly to the operator's registered Solana wallet.