Trust infrastructure · framework v1

A mirrored nexus, joined by mTLS over satellite.

A Provider–Consumer trust framework where both sides run the same Nexus stack, the channel is mutually authenticated and pinned, capital is anchored to Cardano, and trust is bootstrapped out-of-band onto a secure offline device.

Channel mTLS · x509-pinned
Transit Satellite (LEO)
Identity KERI · ACDC
Anchor Cardano
The framework in four beats

Symmetric stack. Pinned channel. Anchored proof. Out-of-band trust.

Mirrored nexus
Provider and Consumer run the same stack. Every claim made on one side is independently verifiable on the other.
Pinned mTLS
Both endpoints present x509 client certificates. No public CA bypass, no DNS spoofing, no permissive intermediates.
Cardano anchor
Capital is published on-chain. Any party can verify the provider's standing without asking permission.
Out-of-band
Trust is bootstrapped through a single-use code delivered on a separate channel — then burned, never trusted again.
The architecture · walkthrough

Click any step. Watch the layer light up.

Six working parts and one transit layer. Walk through them in order — provider organisation, the provider's nexus, the pinned x509 mutual auth, satellite as the carrier, the consumer's mirrored nexus, and the out-of-band bootstrap that makes it all start.

Provider Nexus and Consumer Nexus connected by mTLS over satellite Provider organisation anchors a Provider Nexus that runs https with Cardano-anchored capital. It connects over mTLS, with pinned x509 client certificates on both sides, through a satellite transit layer, to a mirrored Provider Nexus running on a Secure Offline Device on the consumer side, bootstrapped by an out-of-band secure code. Satellite LEO transit mTLS Provider 192.0.0.1 · https Network Consumer nexus Nexus x509 cert Provider organisation Capital · anchored on-chain Consumer 192.0.0.2 · https Network Provider nexus Nexus x509 cert Secure offline device Out-of-band secure code
Framework

A mirrored nexus, joined by mTLS

Click any step above to walk through how a Provider stands up a verifiable channel to a Consumer running on a secure offline device.

8 areas of focus · mapped

Every area owns a specific piece of this architecture.

Protocols and Accountability carry the trust spine. The other six areas exist to make that spine operable — to keep capital sustaining it, to keep the codes flowing, to keep the runbooks current.

01
Direction
Why this exists

Sets the threat model: hostile network, sovereign offline consumer, provider liable for capital. Fixes the non-negotiables every other area inherits.

02
Engagement
Out-of-band channel

Owns the human-to-human handover that delivers the bootstrap code. The only step the wire cannot do.

03
Enablement
Nexus runtime & SDKs

Ships the mirrored Nexus, the Provider Nexus client, certificate-provisioning tooling, and the first-boot installer.

04
Protocols
mTLS · x509 · KERI · ACDC

The core stack. mTLS for the channel, x509 pinning for endpoint identity, KERI AIDs behind the certs, ACDC inside the envelope.

05
Sustainability
Provider capital

The capital behind the provider organisation — the thing the on-chain anchor ultimately attests to. Funds the witnesses, the satellite link, the CA.

06
Processes
Enrol · rotate · revoke

The operational runbooks: how a device is enrolled, how certs are rotated, how a lost device is revoked from the pinning table.

07
Accountability
Cardano capital anchor

Publishes the provider's capital attestations on-chain. Any consumer, regulator, or third party can verify without permission.

08
Organisational
Mirrored topology

Symmetric, not hub-and-spoke. Every conductor role on the provider side has a verification counterpart on the consumer side.

Protocol stack

What lives at each layer.

From transit at the bottom to credential at the top — each layer earns its place by collapsing a specific trust surface that the layer below cannot.

Layer Protocol Role What it collapses
Transit Satellite LEO Bearer network. Routes independently of national ISPs. Reachability dependence on hostile or unavailable terrestrial paths.
Transport TCP · IP · TLS 1.3 Encrypted, ordered byte stream between fixed peer addresses. Passive interception and tampering.
Mutual auth mTLS · x509 pinned Both ends present a certificate. Peer must match pinned SPKI at pinned IP. Public CA compromise, DNS spoofing, permissive intermediates.
Identity KERI AID + KEL Self-certifying identifiers with witnessed, append-only key event logs. Reliance on central identity providers and certificate revocation lists.
Credential ACDC + SAID chain Authentic Chained Data Containers naming AIDs, SPKIs, scope, expiry. Bearer-token forgery and unverifiable claims of enrolment.
Anchor Cardano on-chain Public, censorship-resistant ledger for capital attestations. Provider self-reporting. Anyone can verify without asking.
Bootstrap OOB single-use code Hash committed in KEL; burned on first redemption. Remote enrolment of rogue devices via the online channel alone.
KERI · ACDC event flow

Out-of-band bootstrap, end to end.

Ten steps that trade a single-use, human-delivered secret for a cryptographically-anchored, delegated consumer identity. After step ten, the code is dead and every interaction stands on KERI events alone.

01
Issue OOB code
Provider generates a high-entropy single-use code. Writes an ixn on its own KEL committing only hash(code), expiry, and consumer reference. The code itself never touches the ledger.
Provider · ixn
02
Hand-deliver the code
Sealed, signed, time-limited, single-use. Physical courier or separate authenticated channel — no shared infrastructure with the mTLS path. The provider's expected x509 SPKI hash travels alongside.
Human channel
03
Generate keypairs
On first power-on, the device generates both the current signing keypair and the next (pre-rotated) keypair inside its secure element. Pre-rotation here is what makes everything that follows survivable.
Consumer · local
04
dip — delegated inception
Consumer constructs a dip naming the provider AID as delegator. The a (anchors) field carries hash(code) — binding cryptographic identity to the human-channel handshake.
Consumer · dip
05
Verify and anchor
Provider checks the dip signature, matches hash(code) against the unspent commitment, confirms the expiry window, validates the bootstrap x509 chain, then seals the dip with an ixn on its own KEL.
Provider · ixn
06
Witness receipts
Witness network (2-of-3 default) signs both the dip and the sealing ixn. Until threshold is met, the consumer AID has no third-party verifiability — a claim, not a fact.
Witnesses · 2-of-3
07
Issue ACDC: enrolled-consumer-v1
Provider issues a SAID-chained ACDC naming the consumer AID, the SPKI hash of the long-lived x509, pinned IP, scope, and expiry. The credential chains to the provider's vLEI — verifying enrolment transitively verifies the right to enrol.
Provider · ACDC
08
Anchor the credential
Consumer writes an ixn to its own KEL anchoring the ACDC's SAID. This is the consumer's permanent record — independent of the provider, verifiable against the witness network.
Consumer · ixn
09
Burn the code
Provider writes a final ixn marking hash(code) as spent. Any future replay fails at step 05. The OOB secret is dead.
Provider · ixn
10
First real mTLS handshake
Consumer presents the long-lived x509 plus the ACDC. Provider verifies the cert SPKI matches the ACDC, the SAID is anchored in both KELs, witness threshold still holds, no revocation exists. The mirrored-nexus framework is live.
Both · mTLS
Protocol notes

Four points worth keeping visible.

Properties of the design that are easy to miss in the diagram but hard to recover if optimised away.

The OOB code is bound, not trusted

The code authenticates nothing on its own — only hash(code) is checked, and only as a seal inside a delegated inception. The code's job is to prove the human-channel handover happened, then die.

Pre-rotation matters at step 03

Not later — at step 03. Skip pre-rotation here and you cannot rotate the consumer key after enrolment without re-running the whole bootstrap from scratch.

Two certs, not one

The bootstrap x509 and the long-lived x509 are deliberately separate. The bootstrap cert can be widely provisioned at manufacture; the long-lived one is consumer-specific and only earns its pinning at step 07.

Three KEL events per bootstrap

The provider's KEL carries issue (01), seal (05), burn (09) for every bootstrap. That triple is the auditable trace of the whole flow — reconstructable by anyone with read access to the KEL, without ever seeing the code.

In summary

Symmetry, pinning, anchoring, and a single-use secret.

01
Symmetry, not hub-and-spoke
Provider and Consumer run the same Nexus stack. The consumer holds an independently verifiable copy of every provider claim.
02
Belt and braces on the wire
mTLS, x509 pinning, and IP pinning stack — any single compromise of public CA infrastructure does not break the channel.
03
Trust ends with the human
The framework is machine-to-machine in every step but one. The out-of-band code is the operational discipline the whole architecture rests on.

The framework's strongest property is its symmetry. Its weakest is its dependence on capital sustaining the witnesses, the CA, and the satellite link. Protocols and Accountability hold the spine; Sustainability decides how long the spine stands.