License validation
SDK validates at startup with periodic license beacons at short intervals. Grace period supports brief beacon outages.
ZeRDA is the product. ZEN-D is the proof. Both are owned and shipped by BHTN Technologies Inc.
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.
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.
The SDK exposes send and receive primitives that hide the four-plane machinery. Your application stays small; the pipeline does the hard work.
Full SDK documentation is available to pilot customers under NDA. Contact us for API reference, integration guides, and sample deployments.
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")
} The runtime runs in your account. The portal — license validation, metrics ingest, alerts — runs on ours. Telemetry never contains customer data content, only metadata.
SDK validates at startup with periodic license beacons at short intervals. Grace period supports brief beacon outages.
Cluster-wide health aggregation, mesh node counts, key-service availability, fragment delivery success rate.
Configurable alerts for licensing, health, and throughput anomalies — delivered to your existing incident channels.
Offline mode with signed-JWT license for air-gapped deployments. No beacon calls required.
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.
Encrypted shards with no keys. Nothing usable.
Keys with no data. Nothing to decrypt.
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.
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.
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.
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.
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.
No residual data on captured devices or compromised servers. After TTL, communications are cryptographically irrecoverable.
Four-plane split denies any single observer full metadata. TTL-bound intent prevents long-term pattern-of-life analysis.
Erasure coding with configurable redundancy tolerates multi-path loss. Fail-closed TTL defeats replay of intercepted fragments.
On-premise, GovCloud, Azure Government, or allied sovereign cloud. No dependency on external servers, app stores, or SaaS providers.
No message history on device beyond active session. No contact graph — identity is token-based. Nothing to compel or coerce.
Built for Disconnected, Intermittent, Limited links — satellite, HF radio, tactical mesh. Prioritized dual-lane split ensures control payloads land even on degraded links.
| Dimension | ZEN-D | Signal | |
|---|---|---|---|
| Architecture | Four-plane distributed (bulk + critical-redundancy + metadata + key-custody) | Centralized servers (Signal Foundation) | Centralized servers (Meta) |
| E2E encryption | Dual-layer: standards-based per-user AEAD (app) · mTLS AEAD (transport) | Signal Protocol (Double Ratchet) | Signal Protocol (Double Ratchet) |
| Metadata exposure | Minimal · split across four planes · TTL-bound | Moderate · timing, participants · minimized by Sealed Sender | High · Meta harvests contact graph, timing, location, device IDs |
| Server data residency | No residency at any point · RAM-only · byte-wiped | Ciphertext transient · metadata persists | Ciphertext + metadata persist · cloud backups default |
| Cloud backups | None · architecturally impossible | Local only | iCloud / Google Drive · optional E2E |
| TTL enforcement | Cryptographic · fail-closed · infrastructure-level | Client-side · optional | Client-side · optional |
| Subpoena yield | Nothing after TTL (measured in seconds, configurable) | Registration timestamp · last-seen | Contact graph · timestamps · IPs · backups |
| Single-point compromise | Requires 3+ independent plane compromises | Signal servers → metadata leak | Meta servers → full metadata leak |
| Transport resilience | Erasure-coded multi-path transport with configurable redundancy | Single-path TLS 1.3 | Single-path TLS |
| Identity | Token-based · no phone required · verified public-key fingerprint | Required · tied to phone | Required · tied to phone |
| Ownership / control | Self-hostable · sovereign deployment | Non-profit foundation | Meta (advertising-driven) |
| Military suitability | Yes · sovereign · non-residency · TTL-enforced | Limited · metadata leak · no sovereign deploy | 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.
Request a technical briefing, evaluation benchmarks, or a pilot deployment. We respond within 72 hours.