The easiest way to understand ZeRDA is to follow a single file through it. Not as a diagram, not as a list of primitives, but as a sequence of things that happen to an object in motion — from the moment a sender hands it off to the moment the recipient decrypts it and everything intermediate is wiped.
This post is that walkthrough. We’ll stay at the architectural layer — roles, planes, guarantees — and defer the wire-level mechanics to later technical briefings.
The setting
A file is sitting on a sender’s machine. It needs to reach a specific recipient, on a specific device, in the next thirty seconds. After that, no one — not the sender, not the recipient, not a regulator, not a court, not the operators of any infrastructure in between — should be able to reconstruct it from anything left behind.
That’s the operational goal. The architectural goal is stronger: we don’t want reconstruction to depend on anyone’s promise to delete data. We want it to be mathematically impossible after the window closes.
Phase one: encrypt and fragment
The sender’s client generates a fresh encryption key. It is not derived from a shared secret or pulled from a long-lived keystore. It exists only for this one transfer, and it is AES-256-GCM, chosen for authenticated confidentiality — meaning any tampering with the ciphertext is detectable, not merely probabilistic.
The plaintext is compressed, encrypted with that one-time key, and split. The bulk of the ciphertext — the volume — goes down one path. A smaller, critical portion is encoded with Reed-Solomon erasure coding, producing a set of shards that go down a different path. Each shard alone is useless; a specific subset is required to reconstruct the critical portion, and nothing less suffices.
The encryption key itself never travels in the clear. It is sealed into a wrapped envelope — under a hybrid post-quantum construction, so a captured envelope stays unrecoverable even against a future break of classical cryptography — and the envelope goes down its own path, to a key-custody service that never sees the payload at all.
This is the first structural commitment: the artifacts that make up a single transfer are split across four independent planes — bulk payload, erasure-coded shards, encrypted reassembly layout, and wrapped key envelope — each serving a different role, each running under a different mTLS identity. Compromise of any single plane yields fragments without keys, or keys without fragments, or a layout without either.
Phase two: distribute
The bulk payload travels the bulk plane — a high-throughput transport path straight to a relay that holds it in volatile memory on its way to the recipient. The relay is stateless: it doesn’t index what it’s holding, it doesn’t log bodies, it doesn’t write anything to disk. When the recipient pulls, the bytes stream out and leave nothing behind.
The erasure-coded shards travel the critical-redundancy plane: a mesh of nodes that hold shards in memory and enforce a short time-to-live. The mesh has no query surface. It does not answer questions like “do you have a shard for user X?” It only accepts shards inbound and delivers them outbound to a recipient that presents the correct token.
Distribution of the encrypted metadata — the reassembly instructions — rides the metadata plane, through an intent queue that maps recipient tokens to the right metadata record. This is the only component in the pipeline that knows which fragments belong together, and even then it holds only encrypted metadata whose contents it cannot read.
Each of these dispatches happens in parallel, and each terminates in volatile memory on service instances that have no persistent storage attached.
Phase three: authorize
While the fragments are in flight, the key-custody plane — an in-memory custody service — receives the wrapped key envelope. This is the only place the key ever lives outside the sender’s process, and even here it lives for seconds, not minutes, and only in its wrapped form.
The custody service does not hand the envelope to the network at large. It does not hand it to the relays. It releases the envelope only on presentation of a single-use redemption token bound to the recipient’s operational-certificate fingerprint — and once released, it destroys its own copy. The recipient unwraps the envelope locally, using key material that never left their device, to recover the one-time key.
This is the separation of duty that makes single-plane compromise non-fatal. The bulk and critical-redundancy planes have fragments and no key. The key-custody plane has a wrapped envelope and no fragments. The metadata plane has the layout and neither. Reassembly requires all four, at the right moment, under the right identity.
Phase four: deliver and destroy
The recipient’s client presents its tokens to four endpoints in parallel. The bulk relay streams the bulk ciphertext into a memory buffer. The mesh delivers the required shards. The intent queue releases the encrypted metadata. The key-custody service releases the wrapped key envelope. None of this happens unless the tokens are valid and unexpired — and because the redemption token is single-use, it cannot be replayed to retrieve the same transfer twice.
With the metadata, the recipient knows how the pieces fit. The shards are decoded back into the critical ciphertext portion. The bulk and critical portions are joined at the split boundary. The one-time key, unwrapped locally from the envelope released by the key-custody service, authenticates and decrypts the ciphertext in memory. The plaintext is decompressed, handed to the application, and every intermediate buffer is byte-wiped: the shards, the bulk ciphertext, the metadata, the key.
The transfer is over. Depending on how the infrastructure is sized, the total wall-clock window from encrypt-to-destroy is measured in the low hundreds of milliseconds for typical payloads, and in the single digits of seconds for the largest.
What this structure guarantees
The guarantees fall out of the architecture, not out of policy.
Single-plane compromise yields nothing usable. An attacker who owns the bulk relay sees ciphertext bodies without keys. An attacker who owns the mesh sees a subset of erasure-coded shards without the bulk, without the key, and without the metadata that would tell them which shards belong together. An attacker who owns the intent queue sees encrypted metadata they cannot decrypt. An attacker who owns the key-custody service sees a wrapped envelope they cannot unwrap and would have nothing to apply the key to.
Stolen tokens outside their window are inert. Redemption tokens are time-bound at the signature level and single-use at the key-custody service. A token captured on the wire and presented forty seconds later is rejected without further ceremony.
Per-fragment integrity is enforced independently. Tampering with a single shard does not corrupt the transfer silently; it causes that shard to fail authentication and to be rejected on its own. Reed-Solomon decoding either succeeds with sufficient clean shards or fails closed.
Expiration is not reversible. After the TTL, the key envelope is gone from the key-custody service, the fragments have evicted from relay and mesh memory, and the metadata has evicted from the intent queue. The data has not been deleted in the filesystem sense; it has ceased to exist in the cryptographic sense.
What we didn’t talk about
There are features of ZeRDA this post has deliberately not covered. The details of how the four planes discover each other and route around failure — a stateless discovery service and a relay coordinator keep the mesh self-healing without a network load balancer. The identity and enrollment story — how a recipient proves they are who they say they are. The offline-delivery extension we’re building on top of this same primitive, for the case where a recipient isn’t online when the sender wants to send. The STRIDE threat model enumeration against the full pipeline.
Each of those deserves its own treatment. The point of this post is narrower: to make concrete what “zero residency” actually looks like at the architectural layer — a specific sequence of structurally-independent operations, each of which leaves nothing reconstructible behind when it finishes.
Data moves forward or it is destroyed. It does not pause at rest.