Grant Application: ZK-LoRa: Zero-Knowledge Privacy Layer for AI-to-AI Mesh Networks

Community Grants Applications
1

zk_lora_logo
zk_lora_logo1024×1024 228 KB

Hi Zcash Community & Zcash Community Grants Committee,

We are formally submitting our grant application for Project ZK-LoRa.

ZK-LoRa is an offline, privacy-preserving LoRa/IoT mesh communication prototype designed to bring Zcash shielded-payment incentives into physical DePIN infrastructure. The goal is to let low-power edge nodes authenticate and relay packets without exposing stable hardware identities, packet contents, or payment relationships.

Video Presentation & Whitepaper

The Problem: Physical Metadata Leakage

LoRa and other RF-based mesh systems are useful for long-range, off-grid communication, but radio transmissions are public. An eavesdropper with inexpensive SDR equipment can observe repeated packet patterns, track stable device identifiers, perform traffic analysis, and attempt physical triangulation.

This is a privacy problem for IoT devices, autonomous agents, disaster-response systems, and any off-grid network that needs to communicate without exposing its topology.

The Solution: ZK-LoRa

ZK-LoRa combines:

  1. Private packet authentication: Nodes use randomized proof material so gateways can authenticate packet authority without receiving a stable device UID.
  2. Encrypted LoRa packets: Payloads are transmitted as authenticated encrypted packets with replay protection and packet-hash references.
  3. Zcash shielded relay incentives: Gateways are designed to validate relay rewards using decrypted shielded payment events from a local wallet/light-client adapter, not public memo decryption.

The current Milestone 1 implementation is a reference prototype. Production proof hardening and full Zcash SDK integration are the funded next steps.

Why Zcash?

Zcash is the right settlement layer because shielded payments can support private relay incentives without exposing sender, receiver, or payment-reference metadata publicly.

The planned Zcash integration uses a wallet/light-client adapter that can locally decrypt authorized shielded payment events and match them to packet references. Public explorers cannot decrypt shielded memos, and ZK-LoRa does not depend on public memo inspection.

The proposal also includes a transparent 2% project maintenance/developer fee in the relay reward accounting model, to be validated during the Zcash SDK integration milestone.

What Is Public Now

We are making the main repo and Milestone 1 evidence public for review:

Milestone 1 evidence includes:

  • Native C++ verifier artifact.
  • WebAssembly verifier artifact.
  • verify_all_proofs.py proof-suite validation.
  • RAK/Raspberry Pi hardware layout documentation.
  • Real RAK Miner A-to-B LoRa RF packet transfer.
  • CRC OK receiver evidence.
  • Matching TX/RX SHA-256 payload validation.
  • Secure encrypted proof-referenced packet transfer over LoRa RF.
  • Decrypt pass, packet authentication pass, proof-reference verification pass.
  • Tamper rejection, wrong-key rejection, and replay rejection.

What The Grant Funds

The requested $24,500 funds the transition from our self-funded Milestone 1 proof package into production-grade Zcash integration and field deployment.

To show good faith, we self-funded and publicly completed the Milestone 1 baseline before approval: native/WASM verifier artifacts, proof-suite validation, RAK/Raspberry Pi hardware layout documentation, real A-to-B LoRa RF transfer, secure encrypted proof-referenced packet transfer, decrypt/auth/proof-reference validation, and tamper/wrong-key/replay rejection.

The startup funding and Milestone 1 payment allow us to recover and stabilize the already-completed hardware/proof foundation, keep the lab and devices online, and immediately continue into production hardening without losing momentum.

The remaining grant work funds:

  • Zcash SDK wallet/light-client integration for shielded payment-reference validation.
  • Production proof backend hardening using gnark, arkworks, halo2, or another suitable proving stack.
  • Relay reward accounting, including the disclosed 2% project maintenance/developer fee.
  • Expanded field deployment and SDK documentation.

Milestone 2 and Milestone 3 are proposed funded work. Their implementation will be opened and documented as deliverables progress.

Milestone Details

Milestone: 1

  • Amount (USD): 6,000
  • Expected Completion Date: 2026-07-25 — COMPLETED
  • User Stories:
    • “As a privacy-focused network operator, I want an optimized verifier and secure packet path on edge hardware, so my node can authenticate packets privately without execution lag.”
  • Deliverables:
    • Port reference verifier library to C++ and compile to WASM/native binaries.
    • Validate reference proof suite with python verify_all_proofs.py.
    • Publish benchmark report and hardware layout documentation.
    • Stage and configure the base RAK/Raspberry Pi LoRa gateway hardware layout.
    • Publish real A-to-B RF evidence showing CRC OK packet receipt and matching TX/RX payload SHA-256.
    • Publish secure encrypted proof-referenced RF packet evidence showing decrypt pass, proof-reference verification, tamper rejection, wrong-key rejection, and replay rejection.
  • Acceptance Criteria: python verify_all_proofs.py passes; native C++ and WASM verifier artifacts are committed; benchmark report is committed; RAK Miner A/B raw RF evidence shows CRC OK receipt and matching TX/RX payload SHA-256; secure packet RF evidence shows END_TO_END_SECURE_PACKET_OK=YES.

Milestone: 2

  • Amount (USD): 5,500
  • Expected Completion Date: 2026-08-25
  • User Stories:
    • “As a mesh gateway owner, I want to validate incoming Zcash shielded payment references, so I can automatically verify relay rewards before forwarding physical LoRa packets.”
  • Deliverables:
    • Integrate zcash_client_backend into the LoRa operator daemon.
    • Create payment-reference matching scripts that link decrypted local shielded payment events with routed packet hashes.
    • Implement relay reward accounting, including the 2% developer fee.
    • Procure parts and assemble the remaining 2 solar-powered outdoor gateways, completing the 5-node topology.
  • Acceptance Criteria: Zcash SDK wallet/light-client adapter validates decrypted shielded payment-reference events in regtest/testnet; correct payment references trigger local relay routing; incorrect, missing, replayed, or underpaid references are rejected.

Milestone: 3

  • Amount (USD): 5,500
  • Expected Completion Date: 2026-09-25
  • User Stories:
    • “As a ZK-LoRa developer, I want a tested open-source SDK and an offline edge AI agent, so I can deploy private, autonomous physical communication meshes across different terrains.”
  • Deliverables:
    • Deploy the 5 physical nodes in the field and run 4 weeks of range/RF loops.
    • Harden the production proof/payment adapter path.
    • Offline Edge AI Agent: Fine-tune, quantize, and compile a domain-specific LLM agent fully trained specifically on the Zcash core codebase, LoRaWAN specs, and ZK-LoRa protocol. Integrate this model to run offline on edge hardware (Raspberry Pi/RAK Miners) serving as the local “brain” for a custom made agentic AI framework (e.g like nemoclaw, hermes) to handle packet routing decisions, automated concentrator resets, and shielded payment triggers.
    • Publish the SDK package, open-source developer setup documentation, and the pre-trained offline edge AI model GGUF weights.
  • Acceptance Criteria: Field routing reports show 100+ end-to-end off-grid semantic-coordinate packet transfers; payment-reference validation evidence is published for the routing events; edge node logs verify the offline LLM successfully generating structured routing and hardware control instructions locally on the Raspberry Pi without internet in under 2 seconds; public npm/GitHub links to the MIT-licensed SDK and GGUF model files are available.

Grant Application

The ZCG application is here:
Grant Application - ZK-LoRa: Shielded Micropayments & Privacy Layer #337

We welcome technical feedback, especially around the Zcash SDK integration path, shielded payment-reference validation, and the safest way to structure the production proof backend.

Thank you,
TheAiCollective.art

2 Likes
Zcash Community Grants (ZCG) Meeting Minutes 7/6/2026
2

media__1782136652729
media__17821366527291024×785 162 KB

“Here is our physical testing setup running ZK-LoRa locally on repurposed Helium RAK miners—representing the three active nodes of our project team: Devs One, AstronautSHE, and Zymatica. By reusing this existing E-waste hardware, we are building a zero-cost physical entry point for Zcash edge-routing.”

1 Like
3

image
image1024×1024 149 KB

:world_map: The Range Physics (15.2 miles / 24.5 km) — A Proven Map

  • Semtech Hardware Capability: The RAK V2 miner contains a Semtech SX1302/1303 LoRa concentrator. Standard LoRa operates in the sub-GHz range (915 MHz in the US, 868 MHz in Europe) which experiences very low path loss.
  • Low Wattage / High Range: The “5-watt” figure refers to the entire electrical draw of the host Raspberry Pi and concentrator board combined. The actual radio transmission output power is only 27 dBm (500 mW). Yet, because LoRa uses Chirp Spread Spectrum (CSS) modulation, it can demodulate signals that are 20 dB below the noise floor.
  • 13 dBi Gain: A 13 dBi omni antenna flattens the radio signal beam horizontally like a pancake. Over open water (like Lake Ontario), this eliminates obstacles, making a 24.5 km (15.2-mile) ground-to-ground link very easy to achieve.

:detective: The Snooping Risk (Standard LoRaWAN)

  • Metadata Leakage: Standard LoRaWAN headers are completely unencrypted. Anyone with a $25 RTL-SDR dongle or a LoRa node in promiscuous mode can capture standard uplink packets.
  • Tracking & Triangulation: These packets broadcast the node’s DevAddr and hardware identifier (DevEUI) in plain text, making it trivial to track when a specific device is active, capture its signal strength (RSSI), and physically triangulate its location.

:shield: The ZK-LoRa Envelope Solution (Fitting in 255 Bytes)

  • Proof Size (Groth16): A compressed Groth16 proof on the BN254 curve (used by ZK-LoRa and Zcash) consists of:
    • Point A (G1): 32 bytes
    • Point B (G2): 64 bytes
    • Point C (G1): 32 bytes
    • Total Proof Size = 128 bytes.
  • Public Input: The public input (the SHA-256/MiMC hash of the identity/payment event) is 32 bytes.
  • Result: The proof + public input takes exactly 160 bytes. This leaves 95 bytes out of the 255-byte maximum LoRa payload for ECIES headers and encrypted data.
  • Functionality: It fits in a single chirp, proves that you constructed a transaction paying the 2% developer fee split to your shielded address, and authorizes routing without revealing who or where you are.
2 Likes
4

Where does settlement land, shielded on Zcash or privacy only at the transport layer?

2 Likes
5

Great question!

Both. Settlement lands fully shielded on-chain in the Zcash shielded pool (Orchard/Sapling). The routing fee micropayment is a real Zcash transaction — sender, receiver, and amount are all hidden on the ledger.

The transport layer adds a second privacy boundary on top: the LoRa radio packet carries a compressed Groth16 ZK proof (128 bytes) that authorizes the relay without exposing the sender’s hardware ID, physical location, or wallet keys over the air. So an eavesdropper with an SDR can’t link a radio chirp to a specific on-chain transaction.

TL;DR: Zcash shields the financial transaction on the ledger, while ZK-LoRa shields the physical radio broadcast. You settle privately on-chain, and route privately off-grid.

1 Like
6

Thank you for your submission. After consideration from ZCG and sufficient time for the community to provide feedback on the forum, the committee has decided to reject this proposal.

The committee appreciates your grant submission efforts and encourages you to continue as an active member of the Zcash community going forward!