SAFEHOP

one hop at a time, when nothing else can reach you

A disaster mesh is not a bandwidth problem. It is an energy-allocation problem.
SafeHop routes battery, not packets.

Offline mesh SOS relay · Hacks 11.0 · Problem Statement #15

Download APK release build · 8.1 MB · Android 8.0+ View source

02

The problem

During severe floods, cyclones, or earthquakes, mobile cell towers frequently collapse, leaving stranded victims unable to send emergency SOS requests even when rescue teams are nearby. Build a device-to-device mesh emergency relay system.

Challenge question

How does the relay chain keep working when every device in it is running on a nearly-dead battery?

When the tower dies, every app on the phone dies with it. But the phone still has two radios that never needed a tower. In a flooded apartment block there are dozens of phones within a hundred metres of each other, and at least one is usually near something with a working uplink. The hardware is already there. Nothing is using it.

03

A complete, routable SOS in 24 bytes.

  31 bytes   BLE legacy advertisement payload
 −  3 bytes  Flags AD structure
 −  4 bytes  Service Data header (length + type + 16-bit UUID)
 ─────────
 = 24 bytes  ← the entire SafeHop beacon

Relaying is re-advertising. No connection, no pairing, no handshake — which is why it still works at 4% battery.

—

In action

See the mesh work.

SOS Broadcast

A beacon is created and starts advertising over BLE.

Gateway Relay

A relay node picks up the beacon and re-advertises it toward a gateway.

Battery Budget

The energy ledger tracks every radio operation in real time.

04

Layer stack

APPLICATION SOS screen · Responder map · Mesh Lab

ENGINE MeshNode — origination, relay, snapshot

ROUTING SeenSet · ForwardingPolicy · Outbox

POWER PowerTier · RendezvousScheduler · ScannerElection

LINK ← the seam: opaque bytes, nothing above knows why

RADIO AndroidLink (real BLE) | SimLink (200 virtual nodes)

The same MeshNode runs on a phone driving real Bluetooth radios and in a 200-node simulator. Not a mock that happens to agree — the same class. That is what makes the scale claims honest.

Power ladder

BRIDGE >60% or charging continuous scan · carries the neighbourhood

RELAY 30–60% scan ~30% duty · connects on demand

GOSSIP 15–30% 1 Hz beacons · listens in sync windows only

FLARE 5–15% advertise only · ears open 1s per minute

EMBER <5% beacon every 10s · never scans

Scanning costs roughly 100× what advertising costs, so the ladder cuts listening long before it cuts shouting. An EMBER node is deliberately deaf — still broadcasting, still findable.