Bhada

Overview

Three rollouts died on the bus. This one does not need a signal.

Sajha, Bharatpur and Pokhara each tried digital ticketing. Each worked in the demo and failed in service, because it needed the internet at the moment of payment. Bhada completes every fare with no network on any device. Reaching the internet is how money moves afterwards, never how a fare gets taken.

A spare Android phone under the seat is the meter. It turns GPS into an odometer.
The conductor's phone, or a fixed validator, is the door. It opens and closes rides with one tap.
The passenger's own phone signs each ride, measures it independently, and keeps a signed receipt.
A counter at the step counts bodies, so a rider who never tapped shows up as a gap in the record.

What was built

Four devices, one protocol, and the internet only at the end

Everything that decides a fare lives in one folder of platform-free JavaScript. The passenger's phone, the door, the meter, the Raspberry Pi validator and the Supabase Edge Function all import the same file, so a disputed fare is settled by re-running the same arithmetic in three places. On the bus the devices talk over BroadcastChannel or RS-485 and never need a signal. Later, whichever device finds one first uploads signed receipts and taps, and PostgreSQL moves the money once.

React 19 PWA on Vite, installed from a link and cold-starting in airplane mode.
IndexedDB on every device, so a fare and the wallet that paid it are one atomic write.
One Supabase Edge Function verifies every signature before a row is written.
Money rules are plpgsql plus unique indexes, so correctness does not depend on the caller.

Diagram

Schema

A ledger where every row can be re-verified

Thirty-one migrations, and the pattern is the same in each: store the raw signed token beside the parsed columns. A leg keeps its BM1 receipt, a tap keeps its BT1 ride code, a day-key keeps its PK1 link. Anyone can take a row, re-run the signature check and the tariff arithmetic, and get the same answer the database did.

legs.leg_id is the primary key, so a replayed upload is answered replay and moves nothing.
leg_taps is keyed by the same leg_id: exactly one passenger consent per ride.
Tariffs are rows, added and never edited, so old receipts re-price with the tariff they name.
door_events is an append-only tape a regulator can read and an owner cannot edit.

Database schema

supabase/migrations/0001_bhada.sql … 0031_inspection.sql

Bhada, a fare ledger where every row can be re-verified

Each row keeps the raw signed token it was parsed from, so a leg, a tap or a day-key can be checked again by anyone with the public key and the tariff.

Owned by an operator; row-level security starts hereRecorded by one bus, readable only by its ownerWho paid, and under which published tariff

Taken from the 31 live migrations. Money moves only inside settle_leg() and a few other functions, and only after the sync function has checked every signature. Drag to orbit, and select a table to read its columns.

Tables — select one to inspect it

legs

One ride, priced by the kilometre, settled once

The leg id is the primary key, so a second upload of the same receipt is answered replay. The raw BM1 receipt is stored with it, and the amount is re-priced from the named tariff before any money moves.

Columns

leg_idtextpk
vehicle_platetextfk
trip_idtext
passenger_public_keytextfk
board_odo_minteger
alight_odo_minteger
distance_minteger
distance_sourcetextodometer · route · gps · stage · unclosed
amountintegerwhole rupees
tariff_codetextfk
plausibilitytexta score, never a refusal
receipttextraw BM1

Foreign keys

vehicle_plate → vehicles.plate
leg_taps same leg_id, one consent per ride
passenger_public_key → passengers
tariff_code → tariffs.code

Meter

A GPS odometer that does not bill people for sitting in traffic

Parked at a junction, a phone's position wanders several metres a minute. Summed raw, that bills passengers for standing still. The first version filtered too hard and read zero below 29 km/h, which is every speed a Kathmandu bus actually drives. The current meter uses the receiver's Doppler speed to tell moving from standing, holds its anchor until the bus has travelled 12 m, and books the remainder at each stop.

Fixes vaguer than 35 m, or implying more than 120 km/h, are dropped without moving the anchor.
The reading is a ratchet. It never runs backwards.
Without Doppler, every doubt resolves in the passenger's favour. The meter may under-read; it never over-reads.
A trace recorder and a replay script exist so the claim can be checked on a real road, not only in simulation.

Tariff

A tariff that keeps its promise

Rs 15 covers the first 3 km, then Rs 3 per started kilometre, capped at Rs 25. The promise sold with it is that no ride between two stages costs more metered than the stage table charges today. The first tariff broke that on three stage pairs. The proof script now checks all 21 pairs, and 13 of them get cheaper.

Whole rupees and whole kilometres, so two people with no calculator can check it at the door.
Tariffs are added, never edited. A receipt names its tariff and is re-priced with it.
A ride nobody closes is charged the cap, so tapping out never becomes optional.

Security

Two signatures per ride, and no charge without the passenger's tap

Every token is one line of text signed with ed25519, small enough for a QR code. The passenger signs a ride code; the vehicle signs a boarding pass and a receipt. An audit found the backend would settle any vehicle-signed receipt for any passenger key, which meant anyone holding a vehicle key could bill anyone. Now the passenger's tap travels with the ride, and Postgres refuses to settle a leg without it.

A ride code is valid for 300 seconds and spent at the door. A screenshot is useless.
One tap, one ride, enforced by a unique index on the passenger and the tap nonce.
Every repeated upload is answered replay and moves nothing.
Passengers ride under a new key each day, so the operator cannot link two days to one wallet.

Door

The door knows when the bus is full

Overloading is not a billing problem. It is why people die on Nepali roads. The meter already counts every tap, so the same count holds the door at the permit. The exit is never held, because a full bus is exactly when people need to get off. A crew override is always one press away and always written to an audit tape the regulator reads.

The rule lives in the shared protocol, not in a screen component, so a refactor cannot remove it.
A conductor earns a flat Rs 50 for a clean trip, paid out of the fares owed to the operator, not minted.
Pulling the meter's power on a moving bus is recorded, and that trip pays nothing.

Validator

The same door code on a Raspberry Pi

For operators who want a fixed box instead of a phone, the validator is a Pi Zero 2 with a QR scanner, an NFC reader, a real-time clock and a small screen. It is not a second implementation. It runs the phone's door file unchanged under Node, with four browser modules swapped for hardware adapters.

124 checks in the validator proof, including every screen's QR decoded back from its pixels.
It refuses to decide when no trusted clock agrees with the system clock.
No pin drives a door. The box advises; the crew acts.

Proof

Five proof scripts, and the build fails without them

The fare dispute is settled by re-running the same arithmetic in three places: the phone, the door and the server. So the protocol is platform-free JavaScript that the browser, Node and Deno all run. Vercel's build command runs all five proofs first. A push whose proofs fail does not deploy.

Settlement is tested against every real migration on PGlite, not against mocks.
The pitch demo runs the real meter, both doors, twenty signed passengers and the real backend with zero requests to the internet.

Outcome

What is proven, and what is not yet

Everything is live at bhada-one.vercel.app on Supabase, and the full demo has been run end to end on the live site. The honest gap is the road. The meter has not yet run on a moving bus, so ±2% is a design result against a modelled receiver, not a field measurement. Top-up runs on eSewa's sandbox, and the validator has not yet been assembled from its parts.

Next step is riding route R11 with the trace recorder and scoring it with the replay script.
Meter keys are trusted on first use today. Production needs the owner to confirm them.