A Post-Quantum
Secure Channel
Protocol
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.
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. NIST finalised post-quantum standards in 2024. Nation-state adversaries are already executing harvest-now-decrypt-later operations — collecting classical ciphertext today, to decrypt when quantum capability matures. Any communication that must remain confidential for ten or more years must be quantum-resistant today. No widely deployed protocol — Signal, WhatsApp, Telegram, iMessage — provides quantum resistance. 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 address — 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.
| Protocol | What it lacks |
|---|---|
| Signal | No quantum resistance. Phone-number identity. US-jurisdiction central servers. Traffic metadata visible to Signal Inc. |
| Nostr | Sovereign keypair identity. No quantum resistance. No economic spam resistance. No ordered delivery guarantee. |
| Session | Decentralised relay nodes. No quantum resistance. 14-day message retention. No economic layer. |
| Matrix | Federated infrastructure. No quantum resistance. Cross-server metadata exposure. Homeserver dependency. |
| Bastion | Quantum-resistant hybrid encryption. Sovereign keypair identity. Post-compromise security. Economic spam resistance. Tamper-evident on-chain audit. No central dependency. |
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.
| Property | Construction | Status |
|---|---|---|
Quantum-resistant confidentiality |
ML-KEM-1024 + ECDH → HKDF-SHA256 | Delivered |
|
TOFU key pinning
Protocol property
|
ML-DSA-87 first-contact pin · hard reject on mismatch | Delivered |
|
Out-of-band key verification
User practice, not a protocol guarantee
|
QR code, voice fingerprint, or trust-path certificate | Rec. Practice |
Per-message forward secrecy |
Symmetric double ratchet · HKDF chain | Delivered |
Post-compromise security |
KEM ratchet injection per reply epoch | Delivered |
Replay & ordering protection |
Wire-level message index · hard drop on mismatch | Delivered |
Tamper-evident state integrity |
HMAC-SHA256 keyed to device ML-DSA identity · RFC 8785 | Delivered |
Authenticated on-chain audit trail |
ML-DSA-signed actions · BSV OP_RETURN anchoring | Delivered |
Ephemeral key storage isolation |
TEE/HSM · Intel SGX, AMD SEV-SNP, ARM TrustZone | Phase 2 |
Threshold key operations |
FROST (RFC 9591) · 2-of-3 Guardian | Phase 2 |
Network-level metadata protection |
Onion routing · BSV-incentivised relay network | Phase 3 |
Five security layers.
Each gate-verified.
| Primitive | Role in the construction |
|---|---|
|
ML-KEM-1024
NIST FIPS 203
|
Post-quantum key encapsulation for session initialisation and KEM ratchet. The lattice-based hardness assumption protects the session independently of the classical layer. |
|
ML-DSA-87
NIST FIPS 204
|
Post-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. |
|
ECDH
secp256k1
|
Classical key agreement combined with ML-KEM for hybrid security. An attacker must break both the lattice-based and discrete logarithm assumption simultaneously. Neither advance alone compromises the session. |
|
HKDF-SHA256
|
Key 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-GCM
|
Authenticated encryption of message content. Message keys derived from ratchet chain — the session key is used only for KEM, never directly for message content encryption. |
|
HMAC-SHA256
|
Per-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. |
Self-describing.
Parser-safe.
The Bastion v5 wire format is self-describing. 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. Minimum wire size: 6,346 bytes before content.
| Field | Size | Notes |
|---|---|---|
| Magic bytes | 7 bytes | ASCII 'BASTION' |
| Version | 1 byte | 0x05 |
| Flags | 1 byte | Bit 0 = kem_ct_present; bits 1–7 reserved ● signed region |
| Message index | 4 bytes | uint32 big-endian ● signed region |
| Sender / Recipient keys | 33 + 33 bytes | ● signed region |
| Timestamp | 8 bytes | Unix milliseconds ● signed region |
| KEM ciphertext | 1,568 bytes | Conditional — present when flags bit 0 = 1 ● signed region |
| Next ephemeral public key | 1,568 bytes | Always present ● signed region |
| IV + AES-GCM auth tag | 28 bytes | ● signed region |
| Ciphertext | n bytes | ● signed region |
| ML-DSA-87 signature | 4,627 bytes | Signs all ● fields above |
| HMAC-SHA256 tag | 32 bytes | HMAC(message_key, plaintext) — second authentication layer |
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 the full whitepaper Section 8 before deployment.
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 — 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.
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.
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.
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.
TeraNode deployment and 51% risk
TeraNode's current deployment runs on AWS across six regions, creating an availability and potential compulsion dependency. BSV's current hashrate makes a 51% attack a realistic rather than purely theoretical risk — this would not compromise message confidentiality or authentication, but could affect the ordering and finality of on-chain anchored records.
EAR/ECCN applicability
ML-KEM-1024 and ML-DSA-87 may be subject to EAR/ECCN export classification under US export control regulations. A deployment and distribution concern — not a protocol weakness — but a compliance obligation for implementers operating under US jurisdiction.
A Bastion identity is a BSV keypair generated locally. No registration, no phone number,
no external anchor. The keypair is the identity. 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, did:bsv method). 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 from this state. |
| Known | At least one valid ML-DSA-authenticated message received. TOFU pin established. Cannot self-promote to Trusted. |
| Trusted | Explicit operator designation or Guardian certificate from an existing trusted peer. |
The channel requires three infrastructure properties.
No proprietary ledger can provide all three.
Tamper-Proof Audit Records
The audit trail requires a ledger that no operator — including 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. This is not a preference — it is what makes the on-chain record trustworthy to external parties: regulators, counterparties, auditors. 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. The infrastructure must support this at scale: TeraNode demonstrates one million transactions per second across six global regions (AWS case study, March 2026). The economic layer is a protocol requirement, not a feature.
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 requirement by design. A public, permissionless PoW blockchain can. This is the property that makes external trust possible — and it cannot be bolted on after the fact.
Bitcoin SV is a public proof-of-work blockchain with a fixed protocol specification, legal-identity miners, demonstrated throughput of one million transactions per second, and an accountable non-profit steward — the BSV Association — actively participating in ISO/TC 307, the international standards committee for blockchain and distributed ledger technology. The Chronicle upgrade completed the BSV protocol specification in 2024; a fixed, stable, fully auditable protocol is a feature for regulated deployment, not a liability.
The current hashrate concentration and infrastructure deployment are named constraints with a Phase 3 mitigation path — see Security Considerations.
The rails were built in 2009. Bastion is the protocol.
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. These requirements share a common structure: authenticated sender, immutable timestamped record, demonstrable confidentiality, and the ability to prove compliance without disclosing content.
The specific gap: Bloomberg Terminal, Symphony, and Slack satisfy the record-keeping requirement but the records are under operator control — a single point of regulatory and competitive risk. A regulator or counterparty cannot independently verify the records have not been altered. Bastion's on-chain anchoring removes that dependency. The regulated entity's existing KYC infrastructure provides the legal identity binding. Together they close the compliance gap that current enterprise messaging cannot close.
Authenticated Agent Infrastructure
Every Ruflo 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 AI agent deployment accelerates, the absence of a trustworthy attribution and audit layer becomes a structural infrastructure gap. This primitive — cryptographically authenticated, economically accountable, 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.
Where we are.
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.
Phase 2 — Production Core
Rust crypto core rewrite (constant-time, aws-lc-rs) · 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. Co-founder search active.
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.
Phase 4 — Ecosystem
Open application ecosystem on the channel primitive · Ruflo as a general-purpose authenticated agent layer · Cross-protocol compatibility · Versioned protocol negotiation · Community governance.
The design is done.
The construction is verified.
The channel works.
Building the production core — Rust crypto core, TEE/HSM key isolation, FROST threshold signatures, ProVerif formal verification — is the work of Phase 2. If you are a systems engineer with cryptography depth and this construction makes sense to you, reach out.