Industries · Aerospace & aviation

Evidence that outlives the airframe.

Aircraft fly for thirty years or more, and spacecraft fly for fifteen without a patch. The records about them have to last longer still. R-Series gives commands, firmware, maintenance work and autonomous decisions a hybrid post-quantum receipt that a third party can check years later, with DCS switched off.

Receipt signatureEd25519 + ML-DSA-65
StatusIn development
Firmware signingPlanned
CertificationsNone claimed
00 Why aerospace is different

The record has to outlive the airframe, the vendor and the algorithm.

Space and aviation make every evidence problem harder at once: slow links, small frames, long service lives and inquiries that arrive decades later.

An airliner delivered now may still be flying, and still being maintained, more than thirty years from now. A satellite launched now may operate for fifteen years or more without a software patch. Over those lifetimes the people, the suppliers and the IT systems around the asset all change. The evidence about the asset (who commanded it, which firmware it ran, which parts were swapped and who signed for them) has to survive all of that.

Existing systems already authenticate. Command links protect each frame; maintenance systems keep logs; firmware is checked before it loads. What they rarely leave is an independent, portable artefact that a third party (an investigator, an insurer, a certifying authority, an allied partner) can verify later without access to the operator's systems and without trusting the operator's word.

That is the one thing R-Series makes: a receipt for a high-consequence machine event. It records what was intended, under which policy and key, what happened, and which receipt came before it. It carries two signatures, Ed25519 and ML-DSA-65, so it stays checkable as classical signatures weaken. It is designed to verify offline with the public verifier.

Our position: we do not replace mission security; we add mission evidence. Link cryptography, airworthiness processes and flight software stay exactly as they are. Receipts sit beside them.

Thirty years of service needs thirty years of evidence.

01 Five places trust breaks

Where a receipt adds what the aircraft cannot.

Each of these is a design target with its real state today. None of them is a fielded deployment.

01 · SPACE LINK

Satellite command and telemetry

Who authorised a telecommand, under which key and epoch, exactly which bytes were sent, and what the spacecraft acknowledged. Minted on the ground and bound to the link's sequence count.

In development

02 · FIRMWARE

Avionics and LRU firmware

Firmware signed with stateful hash-based signatures, with signer state kept on the ground in a hardware module and every signing event receipted. Units verify only.

Planned

03 · MAINTENANCE

Maintenance and airworthiness records

Each removal, installation, inspection and sign-off becomes a chained, signed record, so a missing or edited entry shows. A design pattern on the universal receipt today.

Planned

04 · AUTONOMY

Decisions under link loss

UAVs and spacecraft keep deciding when nobody can reach them. The record is sealed where the decision is made and receipted on the ground when the link returns.

In development

05 · KEYS

Key provenance

A record of how each session key was formed, so the answer can be proved later. Post-quantum key exchange is the baseline.

Planned

06 · ARCHIVE

Records for the life of the asset

Archive manifests sealed with hash-based SLH-DSA, renewed under newer suites without re-signing history, and cosigned by outside witnesses.

In development

02 One LRU swap, on the record

Flagged, swapped, checked, signed, sealed.

An illustration of how receipts would follow a line-replaceable unit through a hangar visit. The tail number, serials and unit names in the scene are invented.

Hangar visit01 / 05
01 · THE FAULT

One unit is flagged.

A built-in test reports a fault on one unit in the avionics bay. The first receipt names the aircraft, the unit, the fault code and the time, and points at the receipt before it in the aircraft's chain.

  • The receipt carries hashes of the fault data, not the raw logs
  • Chained, so an entry removed later leaves a visible gap
02 · THE SWAP

Removed and installed, each a record.

The removal and the installation are separate signed records: part and serial out, part and serial in, who did the work and under which task. Swapping a unit without a record breaks the chain and shows.

  • Same receipt shape as every other R-Series event
  • Signed through the engine: Ed25519 + ML-DSA-65
03 · THE FIRMWARE

The image is checked, not trusted.

The replacement unit's firmware digest is compared against a signed manifest. In the R-Series design the signer and its state stay on the ground in a hardware module; units and loaders only verify, and an older image is refused even if its signature is valid.

  • Hash-based firmware signing: planned as one shared capability
  • Anti-rollback: version, signature and registry epoch must all pass
04 · THE SIGN-OFF

Two people release the aircraft.

The engineer who did the work and the inspector who checked it each sign. Their approvals sit in the receipt's approver chain, so the record shows exactly who released the aircraft, and under which authority, for as long as the record exists.

  • Governance receipts are in production in our own product (Website Maker)
  • A maintenance-record profile would need a named operator pilot
05 · THE ARCHIVE

Sealed for the life of the airframe.

The tech-log chain is covered by an archive manifest signed with SLH-DSA, a hash-based signature. When a suite ages, a renewal record under a newer suite covers the older ones; the originals are never re-signed.

  • Long-horizon evidence: in development
  • Renewal is custodial: a named custodian runs it
03 Satellite command and telemetry

Ground-minted. Checked later.

Command links already authenticate each frame. That is the right tool for the link, but it leaves nothing an investigator can check years later about who authorised the command, under which policy and key.

Our design mints a receipt on the ground, where the command is formed, including two-person authorisation, and closes it with the spacecraft's acknowledgement. Nothing is added to the frame, and nothing flies. In development, as part of our space and autonomous systems work.

04 Firmware for avionics and LRUs

Signed in an air gap. Checked on the unit.

A unit fitted today may trust its firmware-signing key for decades. Stateful hash-based signatures rest only on hash functions, which is why national guidance names them for software and firmware signing. Verification is a few hundred hash calls, which suits embedded hardware.

Their one hard rule is that a one-time key is never used twice. So signer state never lives on a unit, a loader or a build pipeline: it stays sealed, single-writer, in a hardware module on the ground. Every signing event becomes a receipt, so years later anyone can check which key signed which image, under which epoch.

This is planned as one shared capability with our code-signing and OT / IoT firmware work. Avionics would consume the same capability. Planned.

05 Autonomous and uncrewed operations

The link drops. The record doesn't.

A UAV in a comms-denied sortie or a spacecraft behind the Earth keeps acting. An inquiry later needs to know which model, on which inputs, under which rules and whose authority made each decision. Our design records rather than replays.

CONNECTED

Live delivery

Recorded segments reach the ground and are receipted as decisions are made.

DEGRADED

Partial delivery

Recorder segments queue locally, already sealed and sequenced.

LOST

Local only

The chain grows on board; the gap itself is recorded as evidence.

RECONNECT

Reconcile burst

Buffered segments flow down, are checked for gaps, receipted on the ground, reconciled and cosigned.

Status. In development. We build no targeting or autonomy logic and do no weapons work: the record shows what a system decided. For classified assets the design is a sealed record with deferred cosigning, never a public chain.

06 Long-horizon archives

Crypto for the lifetime of the evidence.

An airframe's records may be needed long after the signature scheme that sealed them has been deprecated. R+15 keeps them verifiable across algorithm generations without re-signing history: archive manifests are signed with SLH-DSA (a stateless hash-based signature), carry two hashes, and are renewed under newer suites by a named custodian, with checkpoints cosigned by outside witnesses.

Individual receipts keep their fast hybrid signatures. SLH-DSA is used only on manifests, checkpoints and registry roots, where size and speed matter least and a single signature protects everything below it.

"Verifies for decades" is not a property of a file. Renewal is a service with an owner, and every archive proposal names its custodian, witnesses and certifier before it names an algorithm.

07 Certification and airworthiness

What we will not claim.

Nothing on this page is a DO-178C, DO-326A, airworthiness or any other certification or compliance claim. Receipts could later serve as supporting evidence inside such programmes. Whether and how is a question for a named programme and its certifying authority, and it is pending.

08 Working with an aerospace programme

From a briefing to an anchor programme, in stages.

STAGE 1

Closed briefing

The receipt format, the verifier, and the honest state of every layer.

STAGE 2

Verify it yourselves

Your team checks sample receipts offline with the demo verifier, on your own machines.

STAGE 3

Ground-side shadow

Receipts emitted beside one ground workflow (mission operations, a maintenance record flow or a firmware release), observe-only.

  • Nothing in the flight path
  • Nothing switched on without a human GO
STAGE 4

Anchor programme

A named programme with funded integration, a defined deployment, a certifying authority, an export classification and an archive custodian.

09 Questions

From aerospace and aviation teams.

Does R-Series replace our link encryption or command authentication?

No. The link keeps its existing protection and nothing is added to the frame. R-Series adds a ground-minted receipt bound to the sequence count and the acknowledgement, which a third party can verify later.

Does anything run on the aircraft or spacecraft?

No. Signers stay on the ground; flight components verify only, and any on-board role is limited to hash commitments and local sealing. No stateful signer ever goes on board.

Are you DO-178C or DO-326A compliant?

No such claim is made. Receipts may become supporting evidence inside a programme that pursues those objectives, but that needs a named programme and its certifying authority, and it is pending.

Why hash-based signatures for firmware?

They rest only on hash functions, a second assumption beside lattices, and they are cheap to verify on embedded hardware. Their state rule is why signing stays in a hardware module on the ground. The capability is planned.

Will maintenance records still verify in thirty years?

That is what R+15 is for: archive manifests under SLH-DSA, renewal under newer suites and witnessed checkpoints. Long-horizon verification is custodial, so a named custodian runs the renewals. It is in development.

Will receipts be published to a public blockchain?

Not for classified or disconnected assets. The design is a self-contained seal with deferred cosigning by an independent party. Public anchoring is for unclassified civil assets only.

What happens to our records if DCS stops trading?

The algorithms are published, the receipt specification is shared under NDA, and the verifier is designed to run offline, without DCS.

The record should still check when the airframe retires.

Ground-minted command receipts, firmware signed with state kept on the ground, maintenance records in a chain, and archives renewed rather than re-signed: built for whoever checks them decades from now.

In development — talk to us about a design partnership.

Want the details for your sector? Book a briefing — we share the full design and a live demo in a private session.