QuakeGrid

Offline-first earthquake command network for Canakkale, built for a Monad hackathon demo.

QuakeGrid turns ordinary city infrastructure into a disaster response mesh. Traffic light cabinets, street lamps, building sensors, sealed aid packages, gateway devices, and responder units become active nodes in the same operational system.

The core idea is simple: when the internet works, QuakeGrid behaves like a live command dashboard. When the internet collapses, ESP32-style field devices keep collecting, queuing, and relaying critical signals locally. When one gateway reconnects, survival signals, quake readings, donations, and delivery proofs can be committed to Monad as shared operational truth.

Screenshots

Dashboard	Disaster Mode

Timeline	Donations

Devices	Assembly Areas

Citizen Flow

What We Built

QuakeGrid is a simulation-first disaster command center with a hardware and blockchain path behind it.

The demo currently includes:

• 30 simulated field devices across Canakkale
• LifeMesh nodes for citizen SOS, safe, ambulance, fire, police, water, food, and aid messages
• QuakeNode building sensors with vibration, risk score, damage state, and threshold alarms
• emergency institutions including AFAD, hospital, fire brigade, police, municipality, pharmacy, and field teams
• assembly areas with capacity, supply, and district context
• a live incident timeline with signal detail inspection
• donation campaigns and aid request flows
• Monad wallet connection, donation transfer, and critical event proof actions
• ESP32-style firmware sketches for the physical device families

The project is intentionally more than a map with markers. It demonstrates how disaster data can move from citizen or sensor, through a local mesh, into a command interface, and finally into an auditable chain record when connectivity returns.

Why It Matters

Earthquakes do not only damage buildings. They damage coordination.

In the first minutes after a major quake, cities can lose mobile data, cloud access, synchronized communication, and trusted situational awareness. QuakeGrid starts from the opposite assumption: disaster infrastructure must still work when normal internet does not.

Instead of expecting a citizen to find a healthy network, QuakeGrid lets the city itself become the network.

How The System Works

QuakeGrid has three main layers.

1. Physical Layer

ESP32-class devices are attached to real-world city objects.

• LifeMesh nodes sit on traffic lights, street lamps, public squares, intersections, and campus infrastructure.
• QuakeNode devices sit on apartment columns, schools, hospitals, municipal buildings, and historic structures.
• GatewayMesh devices bridge queued local traffic back to the dashboard when an uplink is available.
• ClearAid tags attach identity and delivery proof to relief packages.
• RescueOps units represent responder vehicles and field teams.

2. Offline Communications Layer

The disaster network is designed around store-and-forward behavior.

• Citizen phones discover nearby LifeMesh nodes through BLE-style local access.
• Nodes relay low-bandwidth packets through LoRa-style mesh logic.
• If no uplink exists, the device queues the packet instead of dropping it.
• When a gateway returns, queued high-priority events can be synchronized.

3. Blockchain Trust Layer

Monad is used where a shared record actually helps:

• survival signal proofs
• quake reading proofs
• transparent donations
• physical aid package registration
• delivery confirmation
• future emergency payout or milestone logic

The mesh keeps the disaster network alive. Monad makes the important records durable, shared, and auditable once connectivity exists.

Demo Walkthrough

1. Start the app and open the dashboard.
2. Press the earthquake simulation button.
3. Watch field devices change from normal telemetry into warning and alarm states.
4. Inspect the map to see building risk, citizen signals, institutions, and assembly areas.
5. Select timeline events to view device source, coordinates, target agency, confidence, hop count, and proof status.
6. Open the donation page to review campaigns and wallet-supported MON donation flow.
7. Open the device inventory to inspect all 30 physical nodes.
8. Open institutions and assembly areas to see how response routing and safe-zone planning fit the same system.
9. Open the citizen flow page to understand the one-tap emergency interaction model.

Product Surfaces

Dashboard

The dashboard is the operational center. It combines a Canakkale map, field devices, institution markers, assembly area overlays, citizen signal filters, selected device details, and the live incident timeline.

This page shows how a single event becomes visible in multiple operational layers: device state, map position, timeline entry, routing target, and optional chain proof.

Timeline And Event Detail

The timeline is the incident narrative. It contains sensor alerts, SOS entries, safe messages, aid requests, delivery proofs, and chain-related proof logs.

Selecting a row opens the detail panel with the event type, message, device source, target agency, coordinates, mesh hop count, confidence level, and transaction hash or queued proof state.

Donations

The donation page connects disaster conditions to aid campaigns.

Operators and donors can see campaign context, progress, location-specific need, package targets, wallet status, donation actions, and aid request actions. The goal is to make aid visible as an operational flow, not just a static fundraising card.

Device Inventory

The inventory page lists all simulated physical nodes. Each row includes device identity, attached object, district, battery, signal level, and live status.

This is important because QuakeGrid is hardware-grounded. Every simulated node has a physical role and a matching firmware concept.

Institutions

The institution layer shows the actors that respond to the disaster: AFAD, hospital, fire brigade, police, municipality, medical distribution, and field coordination teams.

The point is inter-agency routing. A signal is not only displayed; it is directed toward the institution that can act on it.

Assembly Areas

Assembly areas show civilian safe destinations with district, capacity, and supply context. QuakeGrid does not only detect emergency conditions; it helps route people toward survivable public geography.

Citizen Flow

The citizen flow page simulates what a person sees when normal connectivity is unavailable.

A citizen only needs a reachable city node. From there, they can send SOS, safe, medical, fire, police, and aid messages into the local mesh.

Quick Start

npm.cmd install
npm.cmd run dev

Open:

http://127.0.0.1:4173

Useful scripts:

npm.cmd run build
npm.cmd run preview
npm.cmd run compile
npm.cmd run deploy:monad

Monad Setup

Create .env from .env.example:

MONAD_RPC_URL=https://testnet-rpc.monad.xyz
PRIVATE_KEY=your_private_key
VITE_QUAKEGRID_CONTRACT_ADDRESS=deployed_contract_address

Then compile and deploy:

npm.cmd run compile
npm.cmd run deploy:monad

The app can still run as a simulation without a deployed contract. Wallet and proof actions become meaningful when the contract address and wallet environment are configured.

Smart Contract

The Solidity contract lives in contracts/QuakeGrid.sol.

It supports:

• registerDevice: registers a disaster device and its location context
• createSurvivalSignal: emits a chain-visible distress or status signal
• registerBuilding: stores structural threshold data
• submitQuakeReading: submits building intensity values and alarm events
• triggerEmergencyPayout: placeholder for future automated emergency support logic
• createAidCampaign: creates an aid funding campaign
• donate: accepts campaign donations
• registerAidPackage: registers a physical aid package by hash
• confirmDelivery: verifies that aid reached its destination

Firmware Layer

Firmware sketches live in firmware, with hardware mapping in docs/hardware-manifest.md.

Device families:

• firmware/life_mesh_beacon/life_mesh_beacon.ino
• firmware/quake_node_accelerometer/quake_node_accelerometer.ino
• firmware/gateway_mesh_uplink/gateway_mesh_uplink.ino
• firmware/clear_aid_tag/clear_aid_tag.ino
• firmware/rescue_ops_unit/rescue_ops_unit.ino

Each sketch emits newline-delimited JSON over Serial at 115200 baud. That gives the project a clean path from simulation to a physical pilot:

1. ESP32 emits structured JSON.
2. A local bridge reads Serial.
3. The bridge forwards payloads to the dashboard.
4. A gateway batches high-priority events.
5. A relayer submits critical proofs to Monad when connectivity exists.

Example payload:

{
  "deviceId": "LM-001",
  "type": "LifeMesh",
  "status": "SOS",
  "lat": 40.1512,
  "lng": 26.4128,
  "battery": 84,
  "riskScore": 92,
  "message": "TRAPPED + NEED_MEDICAL"
}

Tech Stack

• React 19
• TypeScript
• Vite
• Leaflet
• Solidity
• Hardhat
• Monad Testnet
• ESP32-style firmware sketches

Repository Map

• src: React command center, map, simulation logic, donation flows, wallet UI
• src/data: Canakkale devices, institutions, assembly areas, campaigns, and mock signals
• src/web3: Monad wallet, donation, and proof helpers
• contracts: Solidity disaster proof and aid contract
• firmware: ESP32-style sketches for field-device families
• docs/screenshots: README screenshots
• docs/hardware-manifest.md: physical-device mapping and bridge plan

What Makes It Different

QuakeGrid does not use blockchain as a replacement for field communication. The project separates the responsibilities clearly:

• local hardware keeps receiving and forwarding emergency data
• the command UI turns fragmented field events into operational awareness
• Monad stores the records that benefit from public proof, transparent funding, and shared verification

That combination makes QuakeGrid a mesh-ready, hardware-grounded, blockchain-verifiable emergency operating system for a city that cannot afford to go silent.