The standard star topology — all devices connect to one central cloud — has fundamental weaknesses for serious IoT deployments: a single point of failure, data sovereignty issues, cloud vendor lock-in, high latency for local decisions, and escalating costs at scale.
A Mesh IoT Network (MIoTN) distributes the intelligence across multiple FidesInnova Nodes that communicate peer-to-peer. Each site or zone has its own local node that processes data independently — the cloud is optional, not required.
Leaf nodes — IoT sensors and actuators with the FidesInnova ZKP SDK in firmware. Each generates proofs locally and communicates via MQTTS to its local gateway. Devices never communicate directly with other sites.
One or more FidesInnova Nodes per physical site — a building, factory floor, field installation, or vehicle. Each gateway runs a local MQTT broker, executes site-level Service Contracts, and federates selected topic namespaces with peer nodes.
Proofs from all sites are anchored to the FidesInnova blockchain. A coordination node (which may also be a site gateway) aggregates cross-site data. The blockchain layer is the only shared infrastructure — no central application server exists.
MQTT federation (also called MQTT bridging) connects two brokers so that messages published on one are forwarded to the other. In FidesInnova MIoTN, each site node forwards only the specific topic namespaces relevant to cross-site Service Contracts — not all traffic.
Only forward_topics traverse the federation link. All other device data stays local. This is the data sovereignty control point — you decide exactly what crosses site boundaries.
A Service Contract running on a coordination node can receive verified data from multiple site nodes via federation and compute cross-site aggregates:
A critical feature of MIoTN is continued operation during internet outages. FidesInnova Nodes cache all device readings and generated proofs locally. When connectivity is restored:
For installations with intermittent connectivity (remote sensors, mobile deployments), configure the Node's offline_buffer_hours setting to determine how long to cache before rolling over. Proofs are never discarded — they are always submitted eventually.
When Node B receives data forwarded from Node A via federation, how does it know the data is authentic? The answer is that every message in a FidesInnova MIoTN carries a ZKP proof generated by the originating device. Node B verifies the proof against the public verification key — no trust in Node A required.
Node B will only forward or process data whose proof is valid. A compromised Node A that injects false readings cannot generate valid proofs for them — the ZKP system makes this computationally infeasible. The mesh is trustless by cryptographic design.
Each production line has a local node. Site-level contracts handle anomaly detection. A plant-level coordination node aggregates OEE metrics. No raw production data leaves the factory.
Field edge nodes collect soil, weather, and irrigation data. A farm management node coordinates irrigation decisions based on verified zone averages. Operates fully offline during rural connectivity outages.
Vessels carry FidesInnova Nodes that operate fully offline at sea. When in port, proofs batch-sync to the blockchain. Supply chain provenance is proven end-to-end despite weeks of offline operation.
Each neighbourhood block has an edge node for environmental sensors. District nodes aggregate verified air quality and noise for city planning. Residents can verify their own neighbourhood data independently.
Next Course
Monetizing IoT Data →