On-chain connectivity monitoring for Giga schools
Giga is the UNICEF and ITU initiative to connect every school in the world to the internet. Delivering on that goal in a country means paying internet service providers to reach schools and then confirming that the service arrives at the quality contracted. Giga contracted Protofire to build a monitoring system for its work in Brazil and Botswana that makes that verification independent.
Protofire built a system that records connectivity measurements (speed, latency, uptime) on-chain, so governments, donors, and providers read the same record, and that normalizes the inconsistent readings the previous data source returned. The build ran on TypeScript with ethers.js, Blocknative, and Safe over a Microsoft Azure backend, delivered under contract for Giga.
“A monitoring system that stakeholders are meant to trust cannot be built on a feed that reports the same field two different ways.”
Why verifying school connectivity is the hard part
Connecting a school is not a one-time event. A government or donor pays a provider to deliver a working internet link, and someone has to confirm, on an ongoing basis, that the link exists and performs. Across Brazil and Botswana that means monitoring connectivity for a program covering roughly 110,000 schools, about 100,000 in Brazil and 10,000 in Botswana, spread over remote and underserved regions, where the gap between a contract marked "delivered" and a classroom that can actually get online is easy to miss.
Giga treats this measurement layer as central to the program, because progress toward universal connectivity is only real if it can be independently checked.
Why centralized reporting did not hold up
Protofire and Giga reviewed the existing monitoring and found three problems. First, reporting and fund allocation were opaque: stakeholders from local governments to global donors could not easily trace where resources went or whether connectivity targets were met. Second, the data sat in a central database that no outside party could independently verify, so any gap or error was hard to catch and eroded trust between the parties. Third, the legacy setup did not scale to thousands of schools across multiple regions without heavy operational overhead.
There was also a concrete data problem. The API used to gather metrics in earlier country programs returned inconsistent readings: a download speed could come back as a number or as a word, and uptime could not be captured at all. A monitoring system that stakeholders are meant to trust cannot be built on a feed that reports the same field two different ways.
How Protofire built the monitoring system
Two pieces of engineering carried most of the weight. The first was data normalization: Protofire built ingestion that turns the inconsistent upstream readings into a single consistent schema and captures uptime, which the previous source could not provide, so a measurement means the same thing every time it is recorded.
The second was the on-chain layer, which keeps the connectivity record out of any single party's database and open to independent audit. Protofire used ethers.js to write records, Blocknative to monitor transaction state, and Safe for multisig control over the accounts involved.
The backend ran on Microsoft Azure (Static Web Apps and Blob Storage) with PostgreSQL, and GitHub Actions handled delivery. The results surface in dashboards built for policymakers, funders, and local agencies, so connectivity status is readable by every stakeholder against the same record.