InfraVeritas Energy
Halo Grant Application — Project Grants / DePIN Incubator Tier
Hardware-rooted verification oracle for renewable energy generation
Submitted to IoTeX Foundation | Draft v2 — May 2026
Grant Category
DePIN Incubator (Project Grants)
Requested Amount
$120,000 USD (equivalent in IOTX tokens) in tranches over 18 months
Requested Phases
Phase 6 (industrial production) → Phase 7 (W3bstream SDK) → Phase 8 (commercial dashboard)
Current Status
Sepolia testnet since May 14, 2026 — full end-to-end pipeline operational; pre-audit security review complete
Programme Duration
18 months (July 2026 → December 2027)
SECTION 1. EXECUTIVE SUMMARY
1.1 What We Are Building
InfraVeritas Energy is a hardware-rooted verification layer for renewable electricity generation. Sensor devices with Microchip ATECC608B secure elements sign meter readings directly at the point of physical generation. Off-chain computation on W3bstream aggregates these signatures into zero-knowledge proofs, which are recorded on the IoTeX blockchain as an immutable source of truth.
This is not yet another sensor. It is a chain of trust between the physical energy generation event and its on-chain attestation — one that cannot be falsified through software manipulation of the meter, because the signing key has never existed outside the secure hardware element.
1.2 The Problem — Accounting Matters More Than Production
In green electricity, accounting and auditing often matter more than production itself. At every level of circulation — from meter to certificate, from supplier to end consumer — there are opportunities for fraud:
• Phantom generation. Money is paid for electricity that never existed. Inflated meter readings directly convert into subsidies and certificate value.
• Double accounting. The same megawatt-hour is sold twice — once as primary electricity, once as a certificate of origin, and sometimes again across a border in another jurisdiction.
• Inflated volumes. Generation reports exceed the physical capacity of the installation. Operators receive premium tariffs based on figures nobody verifies at source.
The renewable energy certificate market (Guarantees of Origin in the EU, Renewable Energy Certificates in the US) exceeds $10 billion annually and is forecast to grow by an order of magnitude driven by EU RED III (mandatory hourly Guarantees of Origin from 2026), EU CBAM (full enforcement in 2026), and corporate 24/7 carbon-free energy commitments from Google, Microsoft, AWS and Meta. Existing infrastructure is built on paper attestations and manual audits — precisely the problem domain the IoTeX DePIN stack was created to solve.
1.3 Why IoTeX
IoTeX provides a combination of infrastructure primitives unavailable on any other L1:
• ioID for machine identity — each edge device receives a sovereign DID identity on the blockchain, cryptographically bound to a non-exportable private key in the HSM.
• W3bstream for off-chain computation — signature aggregation and ZK-proof generation are performed off the main blockchain, reducing gas costs and protecting data privacy.
• DePIN-native developer community for which hardware-rooted attestation is not exotic, but the norm.
InfraVeritas is architecturally aligned with the IoTeX 2.0 modular infrastructure. We are not trying to build in a vacuum — we are building as an infrastructure layer that other IoTeX DePIN marketplaces, financial instruments, and accounting platforms can consume as a public verification primitive.
1.4 Public Good Commitments
• Verification SDK (TypeScript + Rust implementations) — Apache 2.0 / MIT dual licence, published on npm and crates.io upon completion of Phase 7.
• Poseidon hash parameters and ZK circuit definitions — open publication in the IoTeX community for independent verification.
• Public analytics dashboard — real-time visibility of verified generation volumes across all connected devices, with a URL accessible to all.
SECTION 2. TECHNICAL ARCHITECTURE
2.1 Current State (confirmed on Sepolia testnet, 14 May 2026)
The pipeline is operational end-to-end with measurable characteristics:
• Verifier V3 contract at address 0xf21d900e43214b0abf489f8d6862352aabb09da3
• DeviceRegistry at address 0x6249935e8f293cac2a7c4ce3717a14a8b1e83e03
• HonkVerifier at address 0xAaEaEDA7e14966a2B69c276e20190316990c08Fc
• Edge → Aggregator → Chain — complete cycle ~11 seconds from meter reading to on-chain proof
• 3 independent weather APIs cross-validated for anti-simulation protection
• Public dashboard: InfraVeritas Energy Protocol
• Public repository: GitHub - sidliarchukpetro/infraveritas-energy: InfraVeritas Energy — solar PV verification protocol (MVP) · GitHub
2.2 Integration 1 — ioID as Machine Identity
Each InfraVeritas edge device receives a sovereign machine identity through the IoTeX ioID protocol. The ATECC608B chip stores a non-exportable P-256 private key in the secure element during production provisioning — this is a hardware constraint, not a software one.
The device public key is anchored in the ioID DID document on the IoTeX blockchain. Each data packet, signed using ECDSA at 200 ms intervals, carries a cryptographic claim: “This generation event is attested by device [ioID:did:io:0x…], whose private key has never existed outside a FIPS 140-2 Level 2 secure element.”
ioID integration resolves the Sybil problem at the hardware level: it is impossible to spoof a device identity without physical possession of the chip, and it is impossible to clone the chip without triggering the tamper-response mechanism that zeroes out the key material.
2.3 Integration 2 — W3bstream as Computation Layer
The raw meter reading stream (200 ms interval) must not be written directly to L1 — gas costs would be prohibitive and the privacy of streaming telemetry would be violated. W3bstream solves precisely this problem.
Architecturally, W3bstream functions as the ZK-proof generation and aggregation layer:
• The WASM module accepts signed packets from the edge device (DID resolution via ioID) and performs ECDSA signature verification.
• It runs the cross-weather validation scheme based on Poseidon hashes: three independent meteorological sources for the device geolocation; generation data is checked against values expected for current irradiation/wind conditions.
• It generates a ZK-proof (the choice of system — Plonky2 or Halo2 — will be finalised in Phase 7 based on gas cost benchmarks on IoTeX L1).
• Only the ZK-proof, epoch commitment, and device ioID are transmitted on-chain. Raw telemetry remains off-chain, satisfying GDPR data minimisation requirements by design.
SECTION 3. DETAILED PLAN AND BUDGET
3.1 Overall Budget
Phase
Period
Amount (USD)
Key Deliverable
Phase 6
Months 1–6 (July–December 2026)
$65,000 (54%)
Production of 50 IP67 + tamper-detection hardware units; pilot at 3 energy sites in Ukraine
Phase 7
Months 7–12 (January–June 2027)
$40,000 (33%)
W3bstream integration on IoTeX mainnet; public SDK on npm and crates.io; recursive ZK-proof aggregation
Phase 8
Months 13–18 (July–December 2027)
$15,000 (13%)
Public analytics dashboard on IoTeX Subgraph; preparation of commercial pilots with 3+ CSRD-affected EU companies
Total
18 months
$120,000 (100%)
Payment in IOTX tokens via milestone-based vesting schedule
3.2 Phase 6 (Months 1–6): Industrial Production and Ukrainian Pilot
Phase 6 Budget — $65,000
• Component procurement (ATECC608B HSM, ESP32 MCU, IP67 enclosures, tamper-detection sensors) for 50 units — $20,000
• PCB production, assembly, IP67 certification testing — $15,000
• Electromagnetic compatibility testing (CE/FCC Class B) — $8,000
• Deployment logistics at 3 sites in Ukraine — $7,000
• Engineering team salary (Petro, Oleksandr, Taras) for 6 months — $15,000
Phase 6 Acceptance Criteria
• 50 IP67-certified devices manufactured and tested in accordance with tamper-detection specifications.
• Pilot operating with continuous data stream for at least 90 days at three sites of different generation types (solar, small wind, small hydro).
• Total installed capacity of pilot ≥ 500 kW.
• Successful ECDSA signature verification ≥ 99.97% over the pilot period.
• Public pilot report published on the IoTeX community forum.
3.3 Phase 7 (Months 7–12): W3bstream Integration and Public SDK
Phase 7 Budget — $40,000
• Engineering hours — W3bstream node configuration for InfraVeritas streams, WASM module development, ZK circuit finalisation — $25,000
• W3bstream node infrastructure (hosting, monitoring) for 12 months — $5,000
• SDK development (TypeScript + Rust implementations) — $7,000
• Documentation, publication on npm/crates.io, technical support for third-party integrations — $3,000
Phase 7 Acceptance Criteria
• W3bstream integration operational on IoTeX mainnet with at least 3 devices transmitting verified data.
• ZK-proof generation latency ≤ 30 seconds per epoch on the W3bstream node.
• Gas optimisation: ≥ 60% reduction in per-device verification cost compared with the baseline without recursive aggregation.
• SDK published on npm and crates.io with complete documentation.
• At least 2 third-party dApps in the IoTeX ecosystem have integrated the Verification SDK.
3.4 Phase 8 (Months 13–18): Dashboard and Commercial Preparation
Phase 8 Budget — $15,000
• Development of Subgraph indexer for IoTeX data — $5,000
• Development and hosting of public analytics dashboard — $5,000
• Legal support for commercial discussions with CSRD-affected companies (Ukrainian/EU exporters) — $3,000
• Preparation for engagement with RE100 technical secretariat — $2,000
Phase 8 Acceptance Criteria
• Public analytics dashboard launched at a publicly accessible URL, indexing at least 6 months of mainnet data.
• Subgraph deployed and available for queries on the IoTeX Graph Node.
• At least 5 corporate Letters of Intent from CSRD-affected entities.
• Documentation of engagement with RE100 secretariat (meeting minutes or correspondence).
SECTION 4. SECURITY VALIDATION
The InfraVeritas smart contract suite underwent a pre-audit security review prior to submission of this application. Results are documented below and available for independent verification in the public repository.
4.1 Static Analysis — Slither
Slither (Trail of Bits) — industry-standard static analyser for Solidity/EVM smart contracts.
Result: 0 critical-level findings. 0 medium-level findings. 3 additional informational notes addressed.
4.2 Symbolic Execution — Mythril
Mythril (ConsenSys Diligence) — symbolic execution engine for EVM bytecode.
Result: 0 legitimate vulnerabilities detected. 2 false positives from OpenZeppelin libraries.
4.3 Unit Test Coverage — Foundry
Foundry (Paradigm) — native Solidity testing framework.
Result: 91.88% code coverage across the full test suite (100/100 tests passed). Security-critical paths — proof verification logic, device registry, epoch finalisation — are covered near-completely.
4.4 Fuzzing — Echidna
Echidna (Trail of Bits) — property-based fuzzing framework.
Result: 0 invariant violations across more than 100,000,000 transactions (total duration 17 hours 16 minutes). Seven business invariants verified:
• INV-01: No device can submit a proof for a finalised epoch.
• INV-02: No proof is accepted for a device with an inactive ioID binding.
• INV-03: Finalised generation volume cannot be modified after finalisation.
• INV-04: The Poseidon commitment hash cannot be changed after epoch commitment.
• INV-05: Only a registered device key can sign valid data.
• INV-06: A tamper-detection event nullifies all subsequent submissions from that device.
• INV-07: Total verified volume is monotonically non-decreasing.
4.5 Compliance Architecture
• GDPR Article 25 (Privacy-by-Design) — raw meter telemetry does not leave the W3bstream device runtime. Only ZK-proofs and epoch commitments are recorded on-chain.
• MiCA Article 36 (Disclosure for Asset-Referenced Tokens) — our verification architecture is designed to support issuers of tokenised assets subject to MiCA by providing verified proofs of physical generation.
• EU RED III alignment — our hourly generation guarantee system is structurally compatible with the Granular Guarantees of Origin requirements (mandatory from 2026).
• NIST 800-61 (Incident Response) — formal response procedures for tamper events, key compromise, and data integrity violations are documented in accordance with NIST 800-61r2.
SECTION 5. MARKET CONTEXT AND GO-TO-MARKET
5.1 Why Now — The Regulatory Window
Three converging regulatory and market forces create a window of opportunity in 2026–2027:
• EU RED III: mandatory hourly Granular Guarantees of Origin from 2026. Green electricity producers must prove not only what was generated, but when, with hourly resolution.
• EU CBAM: full enforcement in 2026. EU importers must verify embedded carbon. Ukrainian exporters (steel, cement, aluminium, fertilisers) are directly affected — this is our home market.
• 24/7 carbon-free energy: Google, Microsoft, AWS, and Meta have committed to round-the-clock carbon-free energy with end dates of 2025–2030. Current monthly matching is insufficient. Data centres require hourly verification — this is a multi-billion procurement budget annually.
5.2 First Commercial Layer — Ukraine as the Home Market
Ukraine is not an arbitrary geographical choice for the pilot. It is the convergence of several factors making it the optimal test environment:
• CBAM-affected exporters (metallurgy, mining and metals sector, cement industry) face urgent regulatory pain — without verified embedded carbon they lose access to the EU market.
• Distributed generation following grid destruction (rooftop solar, small biogas, distributed wind) creates natural demand for decentralised verification — centralised solutions do not scale to thousands of small sources.
• Multilateral institutions (EBRD, USAID, World Bank) require generation traceability and audit as conditions for energy infrastructure reconstruction financing. InfraVeritas provides precisely this.
5.3 Path to Revenue
• Q3 2026: completion of hardware production, commencement of Ukrainian pilot.
• Q4 2026: first paid pilot with a Ukrainian renewable energy operator under CBAM.
• Q1 2027: partnership integrations with 1–2 GC issuers (Granular Energy, FlexiDAO, AIB members) as a complementary — not competing — layer.
• Q2–Q4 2027: expansion to hyperscalers (Google, Microsoft) for 24/7 CFE verification of PPAs.
SECTION 6. TEAM
Petro Sydliarchuk — Founder, Engineering Lead
25+ years of structural engineering practice. Licensed engineer with Eurocode CC3 certification — the highest consequence class for infrastructure in the Ukrainian regulatory system. Work on 157+ infrastructure projects with responsibility for physical verification. Owner of the meter integration specification, physical security architecture, and regulatory mapping.
Oleksandr Sydliarchuk — Security & Architecture Review
Bachelor’s degree in Cybersecurity, National University Lviv Polytechnic. Solidity audit and Web3 security focus. Responsible for architecture review and security sign-off across the stack. The pre-audit security results in Section 4 are the product of his work.
Taras Sydliarchuk — Hardware & Firmware
Systems analysis student. Firmware development for ESP32 / ATECC608B. Edge device security architecture. Sepolia deployment infrastructure. The Sepolia mainnet pipeline at the addresses listed in Section 2 is his deployment.
Vladislav Larianovsky — COO & Investor Relations
Former state registrar of legal entities in the Ukrainian state administration. Regulatory and corporate-structure expertise directly relevant to RED III compliance and CBAM verification deployment. Leads business development, investor relations, and ongoing conversations with the IoTeX Foundation.
SECTION 7. RISKS AND MITIGATIONS
7.1 Technical Risks
• Hardware supply chain disruption. Mitigation: alternative suppliers for ATECC608B and ESP32 identified; component pre-ordering executed at the start of Phase 6.
• ZK circuit gas costs on IoTeX L1. Mitigation: recursive proof aggregation in Phase 7; benchmark and selection between Plonky2 and Halo2 based on real-world IoTeX gas costs.
• W3bstream interface changes. Mitigation: close coordination with IoTeX core team, regular sync calls (proposed within the grant).
7.2 Regulatory Risks
• RED III implementing acts delay. Mitigation: our architecture is structurally compatible with any implementation of Granular GoO — implementing details do not change the hardware-rooted trust layer.
• CBAM transitional period extension. Mitigation: the market is moving towards verification regardless; our value proposition is resilient even to 2–3 years of delay.
7.3 Market Risks
• Competition from existing software-only platforms (Granular Energy, FlexiDAO). Mitigation: we do not compete — we provide a lower trust layer beneath them. Our hardware verification complements, rather than replaces, their accounting.
• Weak first-pilot sales. Mitigation: 5+ potential Ukrainian clients already identified through Petro’s engineering expertise network; LOIs expected prior to completion of Phase 6.
SECTION 8. WHY THIS GRANT SHOULD BE AWARDED
InfraVeritas Energy submits this application as a project that has crossed the threshold from concept to validated implementation. The pre-audit security evidence (Section 4) is not a forward-looking commitment but a documented, reproducible empirical record.
We are not asking the IoTeX Foundation to fund a proof of concept. We are asking it to fund the industrial transition from a working testnet MVP to a production hardware deployment at real renewable energy generation sites in Ukraine.
We choose IoTeX because its stack (ioID + W3bstream + DePIN-native L1) provides the primitives our architecture requires. This is not the only possible choice — Ethereum L2s work for our Sepolia testnet — but it is the best-aligned choice for the DePIN-native market we are targeting.
A grant of $120,000 over 18 months covers the critical gap between the current MVP and a fully production-grade infrastructure layer that the IoTeX ecosystem can consume. This is a modest ask relative to the scope — the lean budget reflects realistic Ukrainian engineering labour costs and a focus on capital efficiency.
All deliverables (SDK, dashboard, documentation) remain public goods. The green electricity verification market — worth $10 billion annually — deserves a trust foundation built openly, with cryptographic guarantees rather than paper attestations. IoTeX has the stack that makes this possible. InfraVeritas is ready to build it.
Application prepared by the InfraVeritas Energy team
infraveritas.pro |