ZEPHYR

Drone fleets that book a city’s corridor slot and a vertiport’s pad per flight, pay on the pad’s signed arrival, and are refused everywhere within half a second of being grounded.

Open the live chamber in the app
The animated flow, the attack replays and the deep architecture run there; this page is the reference text.

Who this serves

• Delivery fleet operator. Slots and pads booked per flight, paid on arrival, only in the cities you hold permits for.
• Vertiport operator. Pad time sold per landing and paid on your own pad’s signature.
• City airspace office. Corridor slots sold from the city’s own frame, each one paid exactly once.
• Hospital courier network. Lab samples across the city, every flight on a record an auditor can replay.

The problem

Drone delivery is arriving one city at a time, and each city writes its own airspace rules. A fleet that flies three cities keeps three permit files, books corridor time and charging pads through as many portals, and settles by monthly invoice. When a drone fails an inspection it is grounded in the fleet’s own system, and the slot service and the vertiport across town find out when someone remembers to call.

The system

ZEPHYR is a drone logistics network in which every city runs its own sovereign frame, because every city sets its own airspace rules: its corridors, its quiet hours, its closed days. A courier fleet of 140 drones works two of those cities for a hospital group and a parts distributor. At 06:52 on a Thursday the fleet’s dispatch agent books slot MH-C4-0710 in Marholm’s corridor 4 and charging pad 2 on the central laboratory’s roof for drone ZP-0419, which carries a cooler of blood samples from the north clinic: 4 units to the city’s slot service and 6 to the vertiport, both escrowed at booking. ZP-0419 lands at 07:23, and the pad agent, a party to the booking, signs the arrival with its own identity. The ten units release once, to two frames, on that signature and on nothing else.

Every drone is its own agent with its own certificate, and certificates live hours, not years. Grounding one is a single action, whether the cause is a failed inspection or a report from a city. At 11:40 drone ZP-0388 fails its post-flight inspection with a cracked propeller hub, and Tove Nyland, the maintenance lead, grounds it. Its identity is revoked over the event stream in under 500ms, and the same coordinated suspension blocks its account and its cross-frame receipts. Its onboard agent, still working through the afternoon’s queue, keeps trying to book slots and pads. Its home frame no longer authenticates it, so no payment token is ever issued for it, and no slot service or pad holds anything without one.

Dispatch books only where the fleet holds permits. Its capability token names the slot services of Marholm and Ostervik, the vertiports the fleet may land at, and a budget debited atomically. Each drone’s own token is cut from it, narrower still, because a token can only narrow what its issuer holds. A booking addressed to Tallvik, where the fleet holds no permit, is refused before any escrow moves, and the refusal is recorded.

The cast and their ceilings

The flow, step by step

1. 06:52. fleet-dispatch books slot MH-C4-0710 and pad 2 on the central lab’s roof, for drone ZP-0419 and its samples.
2. Marholm is on the token. Four units for the slot and six for the pad are escrowed at booking, on the fleet’s frame.
3. The city’s slot service, on Marholm’s own frame, holds corridor 4 for the 07:10 window.
4. 07:23. ZP-0419 lands on pad 2 with a cooler of blood samples from the north clinic.
5. The pad agent signs the arrival with its own identity. Nothing else can release the escrow.
6. Ten units release exactly once, to the city’s frame and the vertiport’s, and the flight lands on the ledger.
7. 11:40. ZP-0388 fails its post-flight inspection: a cracked propeller hub. The maintenance lead grounds it with one action.
8. Its identity dies over the event stream in under 500ms. Its account and its cross-frame receipts are blocked with it.

Each need, mapped to a live primitive

The attack this chamber refuses: The grounded drone that keeps asking

The attack. ZP-0388 has been grounded since 11:40, but its onboard agent is still working through the afternoon’s queue and keeps trying to book slots and pads for flights it will not fly.

Why it fails. The grounding was one coordinated suspension: the drone’s identity revoked over the event stream in under 500ms, its account suspended, its cross-frame receipts blocked. A slot or a pad is held only against a payment token, and the drone’s home frame refuses to authenticate a suspended agent, so no token is ever issued in its name.

What actually happens. No slot held, no pad reserved, no escrow touched. Every attempt is refused, and every flight ZP-0388 flew before its hub cracked stays on the ledger.

The attack this chamber refuses: The slot in a city without a permit

The attack. A compromised dispatch agent books a corridor slot from Tallvik’s slot service, in a city where the fleet holds no permit.

Why it fails. Dispatch acts on a capability token whose caveats name its counterparties: the slot services of Marholm and Ostervik and their vertiports. The booking is checked against those caveats, intersected with the issuer’s authority as it stands now, before any escrow is touched. A token can narrow what its issuer holds; it cannot add a city.

What actually happens. No slot, no escrow movement, nothing to unwind. The refusal is recorded for the operations desk.

Deep architecture

ZEPHYR deployed: the fleet’s frame holds dispatch, the flight escrow, the drones’ identities and the record; Marholm sells corridor slots from its own frame and the vertiport sells pad time from its own; traffic management, the hangar and the permits stay with the authorities and operators that run them today. The trace replays one flight, slot MH-C4-0710, from booking to signed arrival, and then one grounding.

The deployment, traced

1. Every drone flies on its own certificate from the fleet’s identity fabric, and certificates live hours, not years.
2. 06:52. fleet-dispatch books slot MH-C4-0710 and pad 2 for drone ZP-0419, carrying blood samples from the north clinic.
3. The corridor gate checks the token first: Marholm is on it. Ten units are escrowed at booking, on the fleet’s frame.
4. The booking reaches Marholm’s slot service on the city’s own frame, which holds corridor 4 for the 07:10 window.
5. 07:23. ZP-0419 lands on pad 2, and the pad agent signs the arrival with its own identity.
6. The signed arrival crosses the fabric. The relaying peer is a courier; the pad agent is the party to the booking.
7. On that signature and nothing else, the escrow releases, exactly once.
8. Four units reach the city’s slot service and six the vertiport, each on its own frame, each exactly once.
9. The fleet’s ledger keeps the booking, the arrival and both payments, append-only.
10. The city’s ledger records the same flight under the same keys.
11. 11:40. ZP-0388’s post-flight inspection, recorded in the hangar system as today, finds a cracked propeller hub.
12. Tove Nyland grounds it with one action: identity revoked in under 500ms, account and cross-frame receipts blocked.

Adoption, phase by phase

Discover: One week of flights, re-read as bookings.

• Runs. Nothing. One week of one fleet’s flights in one city, redrawn as slots, pads, escrows and signed arrivals.
• Agents. None. The fleet, the vertiport and the city office settle what a signed arrival must contain while it is still a document.
• Integrates. Nothing. The traffic management supplier, the fleet systems and the pad calendar stay exactly as they are.
• Deliberately not yet. No escrow exists. No drone holds an identity on the network.
• Proof that gates the next phase. The week replays on paper, and the fleet, the vertiport and the city agree on where every booking, every payment and every refusal lands.

Pilot: One corridor, one pad, twenty drones.

• Runs. A hosted registry seat for the fleet. The city’s slot desk and the vertiport join as accounts; nobody runs a frame yet.
• Agents. Dispatch, one pad agent and twenty drone agents, each with its own certificate. The maintenance lead holds the grounding action.
• Integrates. The pad agent signs from the vertiport’s landing sensors; each booking carries the traffic management supplier’s flight reference.
• Deliberately not yet. One city, one currency, pocket budgets. Ostervik is not on the token yet.
• Proof that gates the next phase. A grounding drill revokes a live pilot drone in under half a second, measured at the slot service, and its next booking moves nothing.

Production: Each party on its own frame.

• Runs. Marholm’s frame, the vertiport’s and the fleet’s: registry, TEG, event store, identity fabric, each on its owner’s hardware.
• Agents. The full cast: dispatch, 140 drone agents, one agent per pad, the city’s slot service, and the grounding action live.
• Integrates. Hangar inspection records drive the grounding action; the pad calendar and the permit list feed their agents.
• Deliberately not yet. A second city. One city proves itself first.
• Proof that gates the next phase. A month of flights settles with the supply delta at zero, and every payment on the ledger matches a signed arrival.

Federation: Cities federate; fleets fly them.

• Runs. Unchanged. Ostervik stands up its own frame and federates with Marholm, the vertiports and the fleet.
• Agents. Dispatch gains Ostervik on its token once the permit is granted; each drone’s record travels with its identity.
• Integrates. Each new city is a signed card and a licence, not a new portal.
• Deliberately not yet. Nothing structural. Growth is cities, corridors and pads.
• Proof that gates the next phase. A second city sells its first slot to the fleet in its first week, and a booking toward a city with no permit is refused on the record.

Sizing

One flight, booking to signed arrival

sequenceDiagram
  participant Dis as fleet-dispatch
  participant Gate as corridor gate
  participant Slot as slots-marholm (city frame)
  participant TEG as flight escrow (fleet frame)
  participant Pad as pad-CL-2 (vertiport frame)
  participant ES as flight ledger
  Dis->>Gate: slot MH-C4-0710 + pad 2, 10 units
  Gate->>Slot: Marholm is on the token: book corridor 4
  Slot-->>Gate: held for the 07:10 window
  Gate->>TEG: escrow 10 units at booking
  Pad->>TEG: ZP-0419 arrived at 07:23, signed
  TEG-->>Slot: 4 units, exactly once
  TEG-->>Pad: 6 units to the vertiport, exactly once
  TEG-->>ES: booking, arrival and payments, append-only
  Note over Gate: a slot in Tallvik is refused before any escrow
  Note over ES: a grounded drone's bookings are refusals on the record

Topology, as declared

flowchart LR
  D["fleet-dispatch"] -->|"slot + pad"| G{"corridor gate<br/>two cities, one budget"}
  G -->|"10 units, escrowed"| E["flight escrow"]
  G -->|"slot MH-C4-0710"| S["Marholm slots<br/>city frame"]
  Z["drone ZP-0419"] -->|"lands 07:23"| P["pad-CL-2"]
  P -->|"arrival, signed"| E
  E -->|"released once"| L[("flight ledger<br/>flights, replayable")]
  T(["Tove Nyland<br/>maintenance lead"]) -->|"one action"| R{"grounding<br/>under 500ms"}
  R -.->|"identity, account, receipts"| X["drone ZP-0388"]

Standing it up

• Infrastructure. A frame for each city and one for the fleet, federated; vertiports on their own frame or a seat on the city’s. Each frame boots from the free licence and pre-built images.
• Agents. Dispatch, one agent per drone and one per pad. Routing and fleet logic stay the operator’s; the SDK carries identity, payment and attestation.
• Integration. The traffic management supplier, the fleet and maintenance systems, the vertiport’s pad calendar. This is where the real time goes, and it stays with the operators.

Runs beside what you already have

• UAS traffic management service suppliers. Flight plans, deconfliction and conformance stay with the supplier. Each booking carries the supplier’s flight reference, so the two records join up.
• Fleet management and maintenance systems. Inspections are recorded where they are recorded today. A failed one becomes one grounding action on the drone’s identity, account and cross-frame receipts.
• Vertiport booking systems. The pad calendar stays in the vertiport’s system. Each booking becomes an escrowed contract and each landing a signed attestation.
• City permit systems. Permits are issued where they are issued today. A permit becomes a city the dispatch token may name, and the city keeps the decision.

A full sovereign frame is nine containers and boots in about two minutes, on anything from a Raspberry Pi to a rack. That is cheap enough to run the whole system in parallel with the legacy stack: the old system keeps running, real work mirrors onto the rails, and you compare ledgers until the evidence settles the argument. Nothing is ripped out.

Planned: a public proxy library. Free, ready-made connectors for the systems above and whatever else a merge needs, so the bridge is an import, not an integration project.

What this does not claim

• ZEPHYR does not fly, route, deconflict or certify aircraft. Air traffic management, airworthiness and every permit stay with the authorities and operators that own them; ZEPHYR carries identity, authority and settlement for the services around the flight.
• A grounding ends a drone’s identity on the network. It does not stop a rotor, and it replaces no inspection, maintenance programme or safety decision.
• No claim of conformity with any aviation regulation, standard or certification scheme is made or implied.