Bastion Protocol · Version 1.0 · June 2026

0x00 · version 0x08 · flags sender_pk · ML-DSA-87 kem_ct · per-epoch

A post-quantum secure channel for adversaries who are already listening.

Messaging is the reference implementation. The channel is the product: a cryptographic primitive any system can rely on: quantum-resistant, forward-secret, post-compromise-recovering, on-chain-auditable. Bastion assumes breach at every layer and designs accordingly.

340tests passing
42/42gate checks
10/10gates shipped
0critical findings

01 · The problem

Two unsolved problems. One construction.

Secure communication has two unsolved problems. Existing protocols treat them as separate concerns. They are not. Bastion treats them as one design problem with one construction.

The quantum threat

ECDH and RSA are broken by Shor's algorithm. Nation-state adversaries are already executing harvest-now-decrypt-later operations: collecting classical ciphertext today, to decrypt when quantum capability matures.

In June 2026 this became official US policy: Executive Order 14409 directs federal agencies to migrate to NIST post-quantum encryption by the end of 2030 and post-quantum authentication by 2031 (contractors included) and states that adversaries “may already be collecting” encrypted government data.

No widely deployed protocol provides quantum resistance: not Signal, WhatsApp, Telegram, or iMessage. Their ciphertext is being collected now.

The sovereignty problem

Every major platform routes messages through infrastructure controlled by a third party, under jurisdictions that can compel disclosure, on infrastructure that can be seized, under terms that can change. Every mainstream identity model requires an external anchor (a phone number, an email) that can be revoked, surveilled, or coerced independently of the user.

Sovereignty means identity is a keypair generated locally. Nothing else. No server holds plaintext. No intermediary can be compelled to produce communications it does not have.

Why existing protocols fall short
ProtocolWhat it lacks
SignalNo quantum resistance. Phone-number identity. US-jurisdiction central servers. Traffic metadata visible to Signal Inc.
NostrSovereign keypair identity, but no quantum resistance, no economic spam resistance, no ordered delivery guarantee.
SessionDecentralised relay nodes, but no quantum resistance, 14-day message retention, no economic layer.
MatrixFederated infrastructure, but no quantum resistance, cross-server metadata exposure, homeserver dependency.
BastionQuantum-resistant hybrid encryption. Sovereign keypair identity. Post-compromise security. Economic spam resistance. Tamper-evident on-chain audit. No central dependency.

02 · Channel properties

What the protocol delivers.

Each property is implemented in the current reference implementation, covered by a test suite that verifies the construction, and derivable from the cryptographic design. Not aspirational. Delivered, or in progress on a named timeline.

Channel properties · v1.0
PropertyConstructionStatus
Quantum-resistant confidentialityML-KEM-1024 + ECDH → HKDF-SHA256DELIVERED
TOFU key pinningML-DSA-87 first-contact pin · hard reject on mismatchDELIVERED
Out-of-band key verification user practice, not a protocol guaranteeQR code, voice fingerprint, or trust-path certificateREC. PRACTICE
Per-message forward secrecySymmetric double ratchet · HKDF chainDELIVERED
Post-compromise securityKEM ratchet injection per reply epochDELIVERED
Replay & ordering protectionWire-level message index · hard drop on mismatchDELIVERED
Tamper-evident state integrityHMAC-SHA256 keyed to device ML-DSA identity · RFC 8785DELIVERED
Authenticated on-chain audit trailML-DSA-signed actions · BSV OP_RETURN anchoringDELIVERED
Ephemeral key storage isolationTEE/HSM · Intel SGX, AMD SEV-SNP, ARM TrustZonePHASE 2
Threshold key operationsFROST (RFC 9591) · 2-of-3 GuardianPHASE 2
Network-level metadata protectionOnion routing · BSV-incentivised relay networkPHASE 3

Named constraint: one-directional streams do not benefit from KEM ratchet post-compromise security, because the KEM step requires a reply to inject fresh entropy. Applications requiring PCS on one-directional channels must use a separate out-of-band re-keying mechanism.

The strongest networks grow beneath the surface, unseen, self-healing, routing around damage. Bastion is built the same way.

03 · The construction

Five security layers. Each gate-verified.

Cryptographic primitives
PrimitiveRole in the construction
ML-KEM-1024NIST FIPS 203Post-quantum key encapsulation for session initialisation and KEM ratchet. The lattice-based hardness assumption protects the session independently of the classical layer.
ML-DSA-87NIST FIPS 204Post-quantum digital signatures for sender authentication. Signs the complete signed wire region, every security-relevant field. TOFU pinning and hard rejection on key mismatch. No downgrade path.
ECDHsecp256k1Classical key agreement combined with ML-KEM for hybrid security. An attacker must break both the lattice-based and discrete-logarithm assumptions simultaneously. Neither advance alone compromises the session.
HKDF-SHA256Key derivation throughout: session init, ratchet chain advancement, KEM injection into root key, and state MAC. Versioned domain-separation strings provide an explicit upgrade path for future wire versions.
AES-256-GCMAuthenticated encryption of message content. Message keys derived from the ratchet chain. The session key is used only for KEM, never directly for content encryption.
HMAC-SHA256Per-message chain authentication and ratchet state file integrity. State MAC keyed to the device ML-DSA secret key via HKDF. Any field modification invalidates the MAC.
Security gates — all delivered
GateDeliverableStatus
01Sender authentication. ML-DSA-87 sign/verify over the complete signed wire region. TOFU pinning. Hard reject on key mismatch. No downgrade path.DELIVERED
02Symmetric ratchet. HKDF chain KDF. HMAC-SHA256 per message. Independent send/receive chains. Compromise of key T exposes only message T.DELIVERED
03Confidentiality. Message keys from ratchet chain. AES-256-GCM encryption. Session key used only for KEM, never directly for message content.DELIVERED
04Replay protection. Split send/receive indices. Wire-level message index in the signed region. Hard drop on mismatch. Chain does not advance on rejection.DELIVERED
05KEM ratchet. Per-epoch post-compromise security. Ephemeral ML-KEM key in every outbound message. Fresh KEM secret injected into the root key on reply.DELIVERED

Wire format v5 — self-describing, parser-safe

Parser behaviour is determined entirely by the wire, not by receiver state inference. Every security-relevant field is in the ML-DSA signed region. A tampered flags byte breaks the signature before the parser acts on it.

04 · Security considerations

Named constraints. No hidden risks.

A protocol that does not name its limitations is a protocol that cannot be trusted. These are Bastion's known constraints, the attack surface they represent, and the current or planned mitigations. Read whitepaper Section 8 in full before deployment.

01 · First contact

TOFU window at first contact

A network-position adversary capable of intercepting and modifying traffic could substitute a public key at the moment of TOFU pinning, but only if they also register the substituted key in a DID Document on BSV before contact. After pinning, all subsequent messages hard-reject any key mismatch.

Mitigation: out-of-band fingerprint verification before relying on the TOFU pin: QR exchange, voice confirmation, or a trust path through a mutually trusted peer. Phase 2 makes DID resolution a mandatory step in session establishment.

02 · Metadata

Communication graph is observable

Every session establishment, prekey rotation, and anchored agent action is a public on-chain event. The communication graph is observable by any chain watcher. Identities are pseudonymous but not unlinkable. Content is never exposed; the graph can be.

Mitigation: Phase 3 onion routing. Until it ships, treat the communication graph as observable. Financial-services firms should evaluate whether their counterparty graph is sensitive before adopting Bastion for external communications.

03 · Keys at rest

Disk-resident ephemeral keys

Ephemeral ML-KEM secret keys are stored on disk alongside ratchet chain state, protected by a state MAC keyed to the device's ML-DSA secret key (stored separately at 0600). An adversary with read access to both files has full session access.

Mitigation: full isolation requires TEE/HSM, the first Phase 2 deliverable and on the critical path before high-security deployment. The Rust crypto core is the prerequisite for TEE integration.

04 · Desync

Crash between save and send

Ratchet state is saved before network send. A crash between save and send advances the sender's chain without the peer receiving the message. Recovery requires both peers to re-initialise the session. A documented operational trade-off, not a security vulnerability.

Mitigation: document the recovery procedure in deployment runbooks. The Phase 2 Rust core includes a formal API surface to support graceful session recovery.

05 · Infrastructure

TeraNode deployment and 51% risk

TeraNode's current deployment runs on AWS across six regions, and current BSV hashrate is concentrated. Both are named infrastructure constraints for the on-chain audit layer.

Mitigation: Phase 3 path: progressive decentralisation across multiple independent node operators in separate jurisdictions. Full detail in the whitepaper.

06 · Export control

EAR/ECCN applicability

Bastion uses NIST-standardised post-quantum cryptography (ML-KEM-1024, ML-DSA-87). US export-control classification under EAR/ECCN applies to distribution; self-classification and licence-exception analysis are part of the pre-launch compliance workstream.

Mitigation: classification completed before public distribution; open-source licence exceptions documented in the compliance record.

05 · Identity & trust

Identity is a keypair. Nothing else.

A Bastion identity is a BSV keypair generated locally. No registration, no phone number, no external anchor. It cannot be revoked by a third party, cannot be compelled from an intermediary, and cannot be transferred without the holder's private key. Identity anchoring follows the W3C Decentralised Identifier standard (did:bsv). Resolution is permissionless: any party can retrieve the DID Document from BSV without authentication or prior relationship.

Sovereign identity

A DID Document published on-chain contains the identity's ML-DSA verification key, ML-KEM public key for session establishment, and inbox service endpoint. Session establishment requires only the recipient's on-chain ML-KEM public key. No handshake, no round-trip, no registration server.

No party in the Bastion infrastructure can produce your communications, revoke your identity, or modify your published keys. The record lives on a PoW chain that no operator controls.

In-protocol trust levels

Trust propagates through explicit peer endorsement only. A trusted peer issues an introduction; only trusted peers can issue introductions. Expiry demotes to Known, not Unknown.

UNKNOWN  No prior contact. Maximum scrutiny. No trust extension possible. KNOWN  Valid ML-DSA-authenticated message received. TOFU pin established. Cannot self-promote. TRUSTED  Explicit operator designation or Guardian certificate from an existing trusted peer.

06 · Infrastructure requirements

Three properties the channel requires. No proprietary ledger provides all three.

Tamper-proof audit records

The audit trail requires a ledger that no operator, not even the Bastion operator, can retroactively amend. A permissioned ledger can be silently modified; that is its design. A PoW chain cannot be rewritten without consensus across independent miners. A controlled ledger produces a record; it cannot produce proof the record is unaltered.

Protocol-level economic accountability

Every message or agent action requires a micro-transaction, not an application-layer rate limit but a protocol-level economic constraint. Attack cost scales linearly with attack volume in a way no software control can replicate. TeraNode demonstrates one million transactions per second across six global regions (AWS case study, March 2026).

No single point of control

A trustworthy audit trail requires that no single party can modify it: not the infrastructure operator, not the application developer, not a regulator who compels one. A proprietary ledger operated by any single entity cannot satisfy this by design. A public, permissionless PoW blockchain can.

Bastion requires a public, append-only ledger with fixed protocol semantics, demonstrated throughput at scale, and legally accountable infrastructure operators. BSV satisfies all three: Chronicle completed and locked the protocol specification in 2024; TeraNode demonstrated sustained throughput of over one million transactions per second across a two-week live network trial, with database infrastructure verified at three million TPS in partnership with Aerospike; miners operate under legal identity with the BSV Association actively participating in ISO/TC 307. The current hashrate concentration is a named constraint with a Phase 3 mitigation path (see Security Considerations).

The rails were built in 2009. Bastion is the protocol.

07 · Applications

What you can build on the channel.

Compliance infrastructure

DORA Article 11 requires tamper-evident ICT incident communication records not under unilateral operator control. MiFID II Article 25 requires immutable transaction-related communication records. HIPAA requires demonstrable end-to-end confidentiality without reliance on a third-party audit function.

Bloomberg Terminal, Symphony, and Slack satisfy record-keeping, but the records are under operator control, a single point of regulatory and competitive risk. Bastion's on-chain anchoring removes that dependency; your existing KYC infrastructure provides the legal identity binding.

DORA Art. 11MiFID II Art. 25HIPAAPhase 3: zk-STARK receipts

Authenticated agent infrastructure

Every agent action is ML-DSA-signed by the authorising identity and permanently anchored on-chain. A rogue or compromised agent cannot forge actions without the identity's ML-DSA secret key. As autonomous-agent deployment accelerates, the absence of a trustworthy attribution and audit layer becomes a structural infrastructure gap. This primitive, cryptographically authenticated, economically accountable, and on-chain-audited, does not exist elsewhere in this combination.

The reference implementation

Messaging is what was built to prove the channel works. For journalists, lawyers, healthcare providers, financial professionals, and anyone whose communications have consequence, this is the channel that should have existed: quantum-resistant, identity-sovereign, forward-secret, post-compromise-recovering, with no server that can be compelled.

Authenticated origin for systems

Any system requiring authenticated origin verification for messages or actions, without trusting the transport layer, can use a Bastion channel as its communication primitive. ML-DSA authentication makes origin forgery computationally infeasible. The economic layer makes identity spam irrational at scale. Wire overhead: 6,346 bytes minimum per message.

08 · Roadmap

Where we are. Gates, not dates.

● Complete

Phase 1 — Reference implementation

Full post-quantum hybrid ratchet stack: ML-KEM-1024 session init, ML-DSA-87 sender auth, symmetric double ratchet, KEM ratchet, wire-level replay protection, device-bound state integrity MAC (RFC 8785). TypeScript on BSV testnet. 340 tests. 42/42 gate checks. Zero critical or high findings.

◐ Active

Phase 2 — Production core

Rust crypto core (constant-time, aws-lc-rs): Gates 1–5 complete: ML-DSA-87 sender auth, AEAD decrypt, symmetric ratchet, session-root combiner, and verified session establishment, cross-verified byte-for-byte against the Phase 1 reference in both directions. 40 tests across 28 suites.

  • TEE/HSM ephemeral key isolation (SGX, SEV-SNP, TrustZone with remote attestation)
  • FROST threshold signatures (RFC 9591)
  • ProVerif formal verification of ratchet properties across unbounded sessions

○ Planned

Phase 3 — Network infrastructure

BSV-incentivised relay network · Onion routing for metadata protection · Progressive Guardian decentralisation across independent TeraNode operators · zk-STARK delivery receipts for DORA/MiFID II compliance attestation without content disclosure.

○ Planned

Phase 4 — Ecosystem

Open application ecosystem on the channel primitive · General-purpose authenticated agent layer · Cross-protocol compatibility · Versioned protocol negotiation · Community governance.

Unbuilt claims are vulnerabilities too. That's why Phase 2's remaining work is listed on the front page.

09 · Proof

Gate-verified. Running on-chain.

Every security property claimed in the whitepaper has a traceable lineage: a gate document that specifies it, an implementation that delivers it, a test suite that verifies it, and a gate check that confirms no regressions. The first Bastion message was sent on April 20th, 2026. It is on-chain, permanently.

The design is done. The construction is verified. The channel works.

Whitepaper v1.0 covers the threat model, the wire format, and every design decision the gates enforced. For a deeper technical or regulatory conversation. The enterprise briefing is the door.