We call the mechanism MAD escrow — short for mutually assured destruction, & that's the whole design philosophy in three words. Before a package moves, both sides put something real on the line: the sender locks the item's declared value plus a bounty, the traveler carrying it locks collateral equal to that same value. Neither side gets their stake back until delivery actually happens.

What happens when something goes wrong is the interesting part. If a package goes missing, the sender gets their principal back — but the traveler's forfeited collateral doesn't go to the sender as a windfall. It's liquidated into a shared treasury reserve instead. Neither side can profit from the other's bad day. That one design choice is what actually keeps the incentives honest between two strangers who've never met.

The real handoff runs on two one-time codes, each generated with real cryptographic hashing — a pickup code & a delivery code. A traveler with spare luggage space on a real flight picks up the package, inspects it, enters the pickup code & records a hashed photo proof. On arrival, the recipient inspects the package & enters the delivery code, which releases the traveler's collateral & bounty automatically — no manual approval step, no human sign-off to wait on.

Settlement itself is being built to run on real on-chain rails — a chain-agnostic layer written against several real EVM networks & stablecoins, with nothing chain-specific hardcoded. It's written & tested, & we're treating it as exactly what unaudited financial code deserves: inert by default, testnet-only, waiting on an independent security review before it ever touches real money. Until then, every escrow still runs as real, working bookkeeping underneath it.

Every balance change gets written twice — once to the database, once to a content-addressed audit log — so the one thing that's never ambiguous is who held what, & when.