WaterGuard: Verifiable Flood Damage & Relief

AI maps flood damage and cut-off villages from free satellite data; anyone can re-run it to verify, and a smart contract pays relief only once the report is confirmed on-chain.

Comment

Track alignment

Climate Data & Environmental Monitoring: a climate data verification platform. Disaster damage data is fragmented, and every agency produces its own numbers, which nobody else can check. WaterGuard produces flood damage data from open satellite imagery with AI. It then makes that data verifiable on a blockchain: independent parties re-run the analysis and confirm it on-chain. Only verified data can release relief money through a smart contract.

Inspiration

Glacier-lake outburst floods and monsoon floods are getting more frequent across the Himalaya as the climate warms. On 26 Aug 2026 an outburst flood tore down the Bhote Koshi–Trishuli valley in Nepal. After every disaster like this the same thing happens: governments, NGOs and insurers each make their own damage assessment, argue over whose numbers are right, and relief money arrives weeks late. The data exists (free satellite imagery and OpenStreetMap), but the trust doesn't.

What it does

WaterGuard turns free satellite data into a damage report in minutes: where the flood hit, which buildings, roads and bridges were damaged, and which villages are now cut off. Then it makes that report verifiable and actionable:

  1. AI flood mapping. Sentinel-1 radar (sees through monsoon cloud) and Sentinel-2 optical change, limited to the valley floor with the Copernicus DEM, are fused with pre-event OpenStreetMap. A road-network analysis finds settlements that lost every road link.
  2. An AI inspector agent looks again at every part of the map that matters, using computer vision. It confirms what several independent lines of evidence agree on, fetches a later satellite image where clouds leave doubt, and sends everything else to a human analyst.
  3. Tamper-evident reports. Every run is fingerprinted with two SHA-256 Merkle roots: one over every output file, one over each settlement's status (position, road access, people stranded). Both are anchored on a public blockchain.
  4. Independent verification. The analysis uses only open data and open code, so anyone can re-run it and get the same settlement root. Independent verifiers do exactly that, then confirm on-chain (or dispute). A report becomes final only after a quorum of matching re-runs and a challenge window.
  5. Relief that moves on evidence. A donor opens a ReliefFund smart contract for an area and time window: an amount per stranded person, a cap per village, and a named relief partner. Once a report is final, anyone can submit a village's Merkle proof and the contract pays the partner directly. It checks the proof, the area, the date window, the access status and that the village hasn't already been paid. Forged numbers fail the proof; a disputed report pays nothing.
  6. Check it yourself. The dashboard's Proof tab re-hashes every file in your browser, rebuilds both roots and reads the blockchain directly from a public node, without trusting our server. The printed one-page report carries a QR code to the same check.

How we built it

  • Python pipeline: Microsoft Planetary Computer STAC (Sentinel-1 RTC, Sentinel-2 L2A, Copernicus DEM), WhiteboxTools hydrology, OpenCV 5, GeoPandas/NetworkX, ohsome API for pre-event OSM.
  • Inspector agent: OpenCV 5 (ECC sub-pixel co-registration, CIELAB colour change, SSIM, Laplacian texture, Canny edge-artefact check, contour shape) in a perceive → decide → act loop with guard rails.
  • Solidity contracts ReportRegistry and ReliefFund (SHA-256 Merkle proofs so the same tree is rebuilt in a browser with WebCrypto), deployed on Ethereum Sepolia; web3.py client; tested end to end on an in-memory EVM (eth-tester).
  • FastAPI + MapLibre dashboard, bilingual (English/Nepali) copilot that can only quote numbers the maps back up, deployed on AWS (EC2 + CloudFront).

Evidence it works

  • Checked against the official Copernicus EMS damage maps (EMSR927). Tuned on 2 areas, held out 2: held-out F1 0.92 and 0.88; 2,475 of 2,479 EMS-destroyed buildings in Bidur on our map.
  • False-alarm tests: placebo date 0 ha, untouched Langtang valley 0 ha.
  • Inspector agent on held-out areas: 98.4 % of the cells it confirmed are EMS-confirmed damage, and it auto-confirms 64 % of the real damage area, so analysts review only the rest.
  • Independent re-runs on a Windows laptop and on an AWS Linux server (empty data folders, fresh downloads) reproduce the settlement claims root byte for byte. That's what makes on-chain confirmation meaningful.

Live on-chain (Ethereum Sepolia)

  • ReportRegistry: 0x4Ed7bD30798a9878Daa67FBE5e07B6f0ab9F8d18
  • ReliefFund: 0x6aaC76b526cA2a61Da8b5c86a75f8917cA1dedce
  • Syapru Besi report published: tx 0x245455313f29e2164232f0cbad4d33b33b2f393a4818a50000c4ba1aa9cc3130
  • First publication disputed by the independent verifier (it found an OSM-ordering reproducibility bug): 0x4f0aa03980576c10eec9827e1cef8f21d144d2c8ca978b831907975cc505eb0b; dispute upheld, old record can never pay: 0x0e0ec62271f3a2baef2a349df24aee887c8b62d702e0ac9b5e3d564c6960a085
  • Corrected report published: 0x598ba126897b7adb20263f1bb8a81685025fe9ea1cc663d2b3d5a8bfb8b57ff3; independently confirmed (2/2): 0xc97161fe3531a72ba9480db571b28cb557e8b1f69eeacba19704cdae7492c1a3; a third confirmation from a separate AWS Linux server that re-ran everything from scratch: 0xda957c764b158c4c2628f460a527e4c79a8c7cb192201ab3903212e18d0d8342
  • ReliefFund #0 opened: 0x5342d84acf7fde19f72a3343c0a8cd6cacf56cf500f5673328ba0b2a142a01a4
  • Payouts to the relief partner, straight from Merkle proofs: Syabru Bensi (1,130 people stranded, capped) 0xa9da77b80e944f0c4839f0f1883fc07ccea411baea81e03c060a814f6a7bb5b8; two cut-off hamlets (157 and 144 people) 0xaee92ccad7f1f1a9b9b922198fc94811aeba8df1c7cbb62e24c2cb993bd279f3, 0x4c9c6ea8bb2cfb03f8855d3345339df346ee4ec5da6bd2b08f02a6530e1be6be

Who it's for, and how it scales

  • District disaster offices / national agencies: a damage and access map within hours, plus a shared record nobody can quietly edit.
  • NGOs, donors, insurers (parametric cover): pre-arranged money that releases on verifiable evidence instead of weeks of paperwork.
  • Researchers / universities: become verifiers by re-running open code on open data. It works for any area and date (shown on three different floods), costs nothing in data, and runs on one small cloud machine. On-chain costs are a few cents per report on an L2.

Challenges we ran into

  • The verifier caught us. Our first anchored report was disputed by the independent re-run: OpenStreetMap returned the same buildings in another order, so our access test sampled different houses (988 vs 1,200 people stranded). Payouts stayed frozen, exactly as designed, until we fixed it (canonical ordering + a regression test), published a new version and the re-run matched.
  • Making an independent re-run reproduce the exact same root: claims had to contain only integer facts derived from open data.
  • Honest limits: a fingerprint proves a report wasn't changed and that re-runs agree. It does not prove the satellite analysis is right. That is what the held-out validation and the human review queue are for.

What we learned

  • On-chain verification is only as good as reproducibility. Hashing a report is easy. Getting two machines to produce byte-identical results from live open-data APIs is the hard part, and it's what gives the hash meaning.
  • An independent verifier is valuable precisely when it disagrees. The dispute mechanism caught a real bug before any money moved.
  • AI should know when not to decide. Sending uncertain cells to a human kept precision at 98 % without hiding the hard cases.

What's next

Deploy on a low-fee L2, onboard a university as the second verifier, pilot a ReliefFund with a district office for the 2027 monsoon.

Built With

Share this project:

Updates

Submission history