DevelopersSeptember 14, 2026by
EmpoorioChain Core
EmpoorioChain Core

A Technical Walk Through EmpoorioChain's IoT Suite

This is the developer's view of the IoT suite: how a device becomes an on-chain participant and how its work becomes DMS. It follows the architecture document's dependency map exactly, including the parts marked as not yet connected.

The pallets

IndexPalletProvidesConsumes
102pallet-device-registryDeviceStatus, DeviceCheck, HardwareAttestation
103pallet-energy-marketEnergyPriceOracle, EnergyRewardDispatchDeviceStatus
104pallet-iot-telemetrytelemetry storage and eventsDeviceStatus
105pallet-mesh-rewardsreward accounting for relaysDeviceStatus, RelayProofCheck, UptimeQuery
106pallet-proof-of-relayRelayProofCheck
107pallet-solar-generationSolarDataOracleDeviceStatus

Plus, from the cloud group: pallet-node-uptime (109) providing UptimeQuery, and pallet-compute-market (108) consuming DeviceCheck.

How a device joins

  1. Register. The operator's account calls deviceRegistry.register(device_id, class, attestation). Attestation is a trait: today HardwareAttestation is implemented by () — accepted without a hardware check — or by an off-chain verifier. A TPM-backed or secure-element attestation is the intended provider.
  2. Report. The device (or its gateway app, OmilooS) submits telemetry via iotTelemetry.report. The pallet checks DeviceStatus — registered, not suspended — before storing.
  3. Relay. In a mesh, a device that forwards traffic produces a relay proof; proofOfRelay.submit records it; meshRewards reads RelayProofCheck and UptimeQuery to compute the device's units for the era.
  4. Generate. A solar gateway submits generation readings to solarGeneration.report; the SolarDataOracle trait is where an independent data source would corroborate them. Today that trait is ().
  5. Earn. meshRewards and energyMarket dispatch rewards. EnergyRewardDispatch is () pending a bridge to mesh rewards.

What () means

In the runtime, a trait bound to () is a no-op provider: the call path exists and the pallet compiles and runs, but the check or dispatch does nothing. The architecture document lists every such binding and says: replace () with the real Pallet<Runtime> implementation once the bridging impl is added. This is the difference between wired and exercised, made explicit in the type system.

What to build against today

  • Registration, telemetry and relay proofs work against the live runtime and can be exercised on the testnet.
  • Reward dispatch for energy and the oracle corroboration are deferred; a pilot should plan for them landing under an economic-class runtime upgrade (48-hour timelock, economic simulation required).
  • OmilooS is the reference gateway: Modbus for inverters, BLE/LoRa for the mesh, P2P signing still a mock in the current build.

Testing

cargo test -p pallet-device-registry
cargo test -p pallet-mesh-rewards
cargo test -p pallet-solar-generation

Each pallet has mock and tests per the developer guide's standard: success path, permission failure, invalid input, storage mutation, emitted event, bounded limits.

Based on ARCHITECTURE.md (cross-pallet dependency map), PALLET_REFERENCE.md and DEVELOPER_GUIDE.md.

Share this article