Skip to content
BHTN
Products

The pipeline, and what we build on top of it.

ZeRDA is the product. ZEN-D is the proof. Both are owned and shipped by BHTN Technologies Inc.

01 Primary product

ZeRDA Pipeline.

A motion-first data runtime licensed as IP. Customers deploy the stack in their own cloud account via infrastructure-as-code. BHTN operates the portal SaaS for monitoring, licensing, and alerts.

Architecture summary

A modular runtime organized into four independent transport planes (Bulk / Critical-Redundancy / Metadata / Key-Custody) with separate mTLS identities. All services run on ephemeral compute — no persistent volumes, no at-rest data.

4 planes Infrastructure-as-code Customer-hosted Air-gap supported
Runtime services All ephemeral · cloud-native
  • SDK
    Client library
    Integrate ZeRDA into your application — send, receive, and orchestrate transfers through the pipeline.
  • Bulk Relay
    Bulk plane
    High-throughput encrypted streaming for the bulk ciphertext subset. Separate identity and network path.
  • Critical Mesh Node
    Critical-redundancy plane
    mTLS-authenticated mesh carrying erasure-coded shards. Multi-hop routing, ephemeral nodes, no persistent state.
  • Metadata Queue
    Metadata plane
    Holds the encrypted reassembly layout and receiver intents under a bounded TTL. Reassembly does not happen without a matching intent.
  • Key Custody Service
    Key-custody plane
    In-memory custody of the wrapped per-transfer key envelope. Released only on a single-use redemption token, then destroyed.
  • Certificate Service
    Identity
    Ephemeral certificate authority. Issues and rotates short-lived mTLS identities for every service in the stack.
  • Enrollment Gateway
    Onboarding
    Dedicated gateway for new-node enrollment and attestation.
  • Discovery + Coordinator
    Self-healing
    Stateless discovery publishes the current trust anchor; the relay coordinator scores relay health and load for adaptive path selection — without a network load balancer.
  • Sender / Receiver
    SDK endpoints
    Reference implementations of the send and receive roles, usable directly or as a starting template.
  • Portal
    Management SaaS
    Hosted by BHTN. License validation, metrics ingest, alerts, and billing.
Validated on the live pipeline
Large file
End-to-end transfer verification — zero-residency preserved throughout.
Enterprise
Enterprise-level throughput sustained across the live pipeline.
100%
Success rate across sustained high-concurrency testing.
02 Integration

How it looks in code.

The SDK exposes send and receive primitives that hide the four-plane machinery. Your application stays small; the pipeline does the hard work.

What the SDK handles for you

  • Per-transfer ephemeral key with standards-based AEAD
  • Erasure coding and shard distribution
  • mTLS-authenticated multi-path routing through the mesh
  • Signed grant-token issuance and redemption
  • Telemetry push, license validation, health heartbeats
  • Byte-wiping and TTL-driven destruction

Full SDK documentation is available to pilot customers under NDA. Contact us for API reference, integration guides, and sample deployments.

Go · illustrative
package main

import (
  "context"
  "os"

  "github.com/bhtn-technologies/zerda/sdk"
)

func main() {
  // Licensed runtime — validates against the BHTN portal at startup
  // with periodic license beacons. Offline JWT mode supported.
  client, err := sdk.FromEnv(context.Background())
  if err != nil {
    panic(err)
  }
  defer client.Close()

  // Open a payload, send it through the pipeline.
  // Under the hood: per-transfer ephemeral key, erasure-coded shards,
  // four-plane fan-out (bulk + critical-redundancy + metadata + key-custody),
  // and byte-wiped destruction on reassembly.
  file, _ := os.Open("settlement-2026-04-19.csv")
  defer file.Close()

  handle, err := client.Send(context.Background(), sdk.Transfer{
    Recipient: "acct:receiver-bank.pinned-fingerprint",
    Payload:   file,
    TTL:       sdk.TTLShort, // fail-closed, no override
    Policy:    sdk.PolicyAuditableDelivery,
  })
  if err != nil {
    panic(err)
  }

  // handle.ID is the audit event identifier.
  // The payload never landed at rest anywhere between you and the recipient.
  os.Stdout.WriteString("transfer " + handle.ID + " delivered\n")
}
03 Portal SaaS

Monitoring and licensing, hosted by BHTN.

The runtime runs in your account. The portal — license validation, metrics ingest, alerts — runs on ours. Telemetry never contains customer data content, only metadata.

License validation

SDK validates at startup with periodic license beacons at short intervals. Grace period supports brief beacon outages.

Metrics & health

Cluster-wide health aggregation, mesh node counts, key-service availability, fragment delivery success rate.

Alerts

Configurable alerts for licensing, health, and throughput anomalies — delivered to your existing incident channels.

Air-gap supported

Offline mode with signed-JWT license for air-gapped deployments. No beacon calls required.

04 First-party client

ZEN-D · ZeRDA Encrypted Network Dialogue.

A secure messaging application built on the ZeRDA stack. Replaces the traditional end-to-end encrypted messaging model with structural data non-residency — messages cannot be recovered from any single service, persistent storage, or post-expiry state.

Where Signal and WhatsApp protect message content under the assumption of trustworthy infrastructure, ZEN-D assumes infrastructure is compromised and architects the system so compromise yields nothing.

Each message is split across four architecturally independent planes — bulk payload, critical-redundancy shards, encrypted metadata, and key custody. None of them hold enough context to recover a message on their own. After TTL expiry, metadata is invalidated, shards are wiped, and the message is mathematically irrecoverable.

Four-plane Dual-layer crypto Fail-closed TTL Sovereign deploy Air-gap compatible Open-source core
If a server is compromised Yield per plane

Mesh compromise

Encrypted shards with no keys. Nothing usable.

HSM compromise

Keys with no data. Nothing to decrypt.

Queue compromise

Metadata pointers with no content. Expire on TTL.

No single breach recovers any message. No combination of any two breaches recovers any message whose TTL has expired.

Encryption · three independent layers
L1 Between users

Application encryption

Per-user shared-key derivation from public identities into a conversation base, with per-message standards-based AEAD. Cryptographically verifiable safety numbers with user-verified pinning.

L2 Between nodes

Transport encryption

mTLS on every inter-component hop. Short-lived ephemeral certificates issued by an internal certificate service. Standards-based AEAD on the wire. Per-fragment integrity with replay protection.

L3 Key-custody plane

Key custody

Per-transfer keys held only as wrapped envelopes in the in-memory key-custody service, never transit alongside data. Single-use, redemption-token-gated release bound to the recipient operational-certificate fingerprint. Expired tokens are refused. Planned hardware-enclave hardening with attested key release.

Military telecommunications

Built for threat models consumer messengers were never designed for.

Nation-state SIGINT adversaries. Captured devices. Contested infrastructure with partial compromise assumed. Sovereignty requirements that exclude commercial clouds. ZEN-D is not a consumer messenger repurposed for defense — it's architected for the threat model modern military communications actually face.

01

OPSEC

No residual data on captured devices or compromised servers. After TTL, communications are cryptographically irrecoverable.

02

SIGINT resistance

Four-plane split denies any single observer full metadata. TTL-bound intent prevents long-term pattern-of-life analysis.

03

C2 resilience

Erasure coding with configurable redundancy tolerates multi-path loss. Fail-closed TTL defeats replay of intercepted fragments.

04

Sovereign deployment

On-premise, GovCloud, Azure Government, or allied sovereign cloud. No dependency on external servers, app stores, or SaaS providers.

05

Post-capture security

No message history on device beyond active session. No contact graph — identity is token-based. Nothing to compel or coerce.

06

DIL-network capable

Built for Disconnected, Intermittent, Limited links — satellite, HF radio, tactical mesh. Prioritized dual-lane split ensures control payloads land even on degraded links.

ZEN-D vs Signal vs WhatsApp
Dimension

Architecture

ZEN-D
Four-plane distributed (bulk + critical-redundancy + metadata + key-custody)
Signal
Centralized servers (Signal Foundation)
WhatsApp
Centralized servers (Meta)
Dimension

E2E encryption

ZEN-D
Dual-layer: standards-based per-user AEAD (app) · mTLS AEAD (transport)
Signal
Signal Protocol (Double Ratchet)
WhatsApp
Signal Protocol (Double Ratchet)
Dimension

Metadata exposure

ZEN-D
Minimal · split across four planes · TTL-bound
Signal
Moderate · timing, participants · minimized by Sealed Sender
WhatsApp
High · Meta harvests contact graph, timing, location, device IDs
Dimension

Server data residency

ZEN-D
No residency at any point · RAM-only · byte-wiped
Signal
Ciphertext transient · metadata persists
WhatsApp
Ciphertext + metadata persist · cloud backups default
Dimension

Cloud backups

ZEN-D
None · architecturally impossible
Signal
Local only
WhatsApp
iCloud / Google Drive · optional E2E
Dimension

TTL enforcement

ZEN-D
Cryptographic · fail-closed · infrastructure-level
Signal
Client-side · optional
WhatsApp
Client-side · optional
Dimension

Subpoena yield

ZEN-D
Nothing after TTL (measured in seconds, configurable)
Signal
Registration timestamp · last-seen
WhatsApp
Contact graph · timestamps · IPs · backups
Dimension

Single-point compromise

ZEN-D
Requires 3+ independent plane compromises
Signal
Signal servers → metadata leak
WhatsApp
Meta servers → full metadata leak
Dimension

Transport resilience

ZEN-D
Erasure-coded multi-path transport with configurable redundancy
Signal
Single-path TLS 1.3
WhatsApp
Single-path TLS
Dimension

Identity

ZEN-D
Token-based · no phone required · verified public-key fingerprint
Signal
Required · tied to phone
WhatsApp
Required · tied to phone
Dimension

Ownership / control

ZEN-D
Self-hostable · sovereign deployment
Signal
Non-profit foundation
WhatsApp
Meta (advertising-driven)
Dimension

Military suitability

ZEN-D
Yes · sovereign · non-residency · TTL-enforced
Signal
Limited · metadata leak · no sovereign deploy
WhatsApp
No · consumer app · Meta-hosted

Based on publicly documented features as of 2026. Signal and WhatsApp use end-to-end encryption but still transit through vendor-operated infrastructure that retains metadata and, in some cases, ciphertext or cloud backups.

Verification
19/19
STRIDE categories defeated
Testing
55
Go unit tests on zero-residency
Performance
Enterprise
throughput sustained under high concurrency
Largest validated transfer
Large file
end-to-end · zero-residency · cryptographic TTL
Start a conversation

Evaluation, pilot, or both.

Request a technical briefing, evaluation benchmarks, or a pilot deployment. We respond within 72 hours.