Trust isn't a tagline. It's an architecture.

End-to-end encrypted by default

Your content is encrypted on your device with libsodium — the battle-tested cryptographic library descended from NaCl, the reference implementation of Daniel J. Bernstein's modern crypto primitives — before it ever touches our network. Each Safe gets its own symmetric key — XChaCha20-Poly1305, a modern authenticated cipher with a 256-bit key. That key is then wrapped — once per recipient — using their public key (an X25519 sealed-box construction).

Our servers store the encrypted content blob and the wrapped keys. They don't store anything that lets us decrypt your content. If our infrastructure is breached, the attacker gets ciphertext — never plaintext content. If a court order, subpoena, or government request lands on our doorstep, we can hand over ciphertext and metadata — and that's all we have to give. We can't decrypt what we don't have keys for, and no internal process or override can change that. For the precise boundary between content protection and metadata exposure, see What we protect, and what we don't below.

Tamper detection is built in

Every encrypted file carries a cryptographic seal — a Poly1305 authentication tag — that's verified before any byte is decrypted. If a single bit of the ciphertext is altered, by a curious admin, a corrupted disk, a malicious intermediary, anyone, decryption fails immediately and visibly. Your recipient never sees corrupted or substituted content presented as if it were yours.

This is what cryptographers call authenticated encryption (AEAD) — a stronger guarantee than "encrypted" alone, and the property that makes a cipher safe to send across an untrusted network. We chose the modern AEAD stack (XChaCha20-Poly1305) because it's faster in software, has a wider safety margin around nonce handling, and is the construction adopted by WireGuard, TLS 1.3, age, and most post-2015 protocol designs. It's considered equivalent in strength to AES-256-GCM while avoiding several of GCM's well-known footguns.

Court orders, subpoenas, and government requests

The most common question we get from privacy-aware users is: "If the government demanded your data, what could you actually hand over?" The honest answer is ciphertext and account metadata — and nothing else. Your content is encrypted on your device before it ever touches our network. The decryption keys live on your device and on your recipient's device. They do not live on our servers, in our databases, in our logs, or in any cold backup we hold.

This applies to every legal channel: civil subpoenas, criminal court orders, administrative subpoenas, National Security Letters (NSLs), FISA orders, and informal government requests of any kind. We comply with valid legal process by producing what we have — encrypted blobs and account metadata such as email addresses and timestamps. We cannot produce plaintext content because we do not have it.

This is not a policy commitment ("we promise not to read your content"). It is an architectural property ("we cannot read your content"). Promises can be broken under pressure or rewritten by future leadership; architectural properties cannot, without rewriting the codebase end-to-end — which would be a public, observable event. The same guarantee that protects you from us protects you from anyone who might one day acquire us, run us, or compel us.

Belt and suspenders, all the way down

Your content blobs sit on enterprise-grade cloud storage, encrypted end-to-end by your device before they ever leave it — so we don't rely on infrastructure for confidentiality. The storage layer adds defense-in-depth on top: encrypted at rest, TLS-only in transit, redundant across multiple physical datacenters with eleven-nines durability. Your encrypted Safes are storage-grade resilient the moment you save them — not just secure, durable — for the 30-year delivery window TRS is built to honor.

The keys live on your device

Your private key — the one that unwraps wrapped keys — lives in your phone's secure enclave (Face ID / fingerprint protected on iOS, equivalent on Android). It never leaves the device. We don't have a copy. We can't reset it. Even we can't recover it for you — and that's the point.

Recovery without a master key

So how do you recover access if you lose your phone?

Through Designees. You pick a small circle — typically 2 to 5 people you trust — and configure a quorum (usually "2 of 3 must approve"). If you're locked out, a quorum of them can verify it's really you and help you back in. Each Designee verifies independently. There's a deliberate cooling-off period between recovery initiation and key restoration. You're notified of every step and can cancel a recovery you didn't initiate.

No single Designee can restore your account on their own. Neither can we. The math forces collusion of multiple trusted people, with friction and observability — exactly the right shape for the kind of attack we're worried about.

Quorum-gated release — when one person isn't enough

The same multi-party authorization that gates account recovery also gates safe release, when you configure it that way. For a Safe whose contents shouldn't go out on one person's judgment alone — estate disclosures, business succession material, sensitive multi-stakeholder content — you can set a release Quorum: "two of three trusted contacts must approve before this releases." Each voter approves independently. The Safe stays sealed until the threshold is met, and the standard Pending Release cooling-off window still runs afterward.

Recovery Quorum protects the owner getting back in. Release Quorum protects the recipients from a release that shouldn't have happened. Same cryptographic primitive, opposite endpoints — and you can mix-and-match per Safe.

Two-layer recovery — explained plainly

We separate your sign-in password from your encryption keys, on purpose:

• Sign-in password — proves who you are to the server. Recoverable by email reset.
• Encryption keys — decrypts your Safes. Recoverable through Designees.

This means a forgotten password on the same phone takes 30 seconds. A forgotten password and a new phone is a Designee-recovery flow — slower, deliberately. Both layers have to come apart for someone to reach your content, and "both layers come apart" is the threshold where the system asks your trusted circle to vouch for you.

The Pending Release window

When a release trigger fires, the Safe enters a Pending Release state — a cooling-off window before content actually goes out. 24 hours by default, 72 hours for inactivity-based releases (where you might just be on a flight). You're notified the moment a trigger fires, by every channel you've enabled. You can cancel with one tap during the window.

After the window closes, delivery is irrevocable. We commit to that line and we tell you exactly when it crosses. No silent extensions, no "oh we paused it for you," no calls to support to claw a release back. The certainty is the feature.

Releasee abstraction — privacy from your own helpers

If you designate a Releasee — a person who can fire releases on your behalf — they only see what they need. They never see your Safe names, file names, recipient names, or contents. Only the count: "3 Safes." When they fire, every Safe they're authorized for fires together. They can't browse, edit, or pick. This protects your privacy from your own trusted helpers.

The release key

Every release attempt by a Releasee requires a release key — a credential you give them out-of-band, separately from the app. Identity verification (their email + phone) scopes which Safes they can release. The key authorizes the trust circle. Both are required; neither is sufficient on its own.

The key isn't stored in the Releasee's app. It's held only by them, however they choose — memory, paper, password manager. It's rotatable from your phone at any time. Every key submission is logged and you're notified the moment one is attempted, correct or incorrect.

What we log, what we don't

We log enough to detect abuse and audit your own activity:

• Sign-in events (timestamp, device fingerprint, region — not exact location)
• Safe state transitions (Draft → Sealed → Pending Release → Released)
• Trigger fires, including which Releasee or system event caused them
• Release-key submission attempts (success or failure)
• Recovery requests, Designee verifications, cooling-off-window timing

We don't log:

• Plaintext content, file names, or thumbnails (we don't have access to them)
• Recipient names or relationship metadata beyond what's required to deliver
• Read receipts on contents (recipients see them, we don't)

What we protect, and what we don't

Every encryption system has a boundary. The honest question is where ours sits — what an attacker gets if they fully compromise our servers, and what they don't.

What's protected from a server breach. Every byte of Safe content — files, notes, voice memos, vault contents — is encrypted on your device before it touches our network. The per-Safe keys are wrapped to each recipient's public key and opened only on their device. The Shamir shards your Recoverees hold are wrapped to those Recoverees' public keys. The owner-sealed Layer-3 material that lets you recover Safes from a new device is encrypted to your own key. None of this material is ever decryptable from our infrastructure. If our entire database and all our backups were leaked tomorrow, the attacker would get ciphertext — useless without keys we don't possess.

What our servers do see. To route releases to the right Recipients, fan out triggers to the right Releasees on inactivity, enforce Quorum thresholds, and let your trust circle help you recover an account, our servers need to know the relationship graph. That graph — who has designated whom as Recipient, Releasee, Recoveree, or Quorum member — lives in plaintext on our infrastructure, alongside email addresses, names, phone numbers when provided, push-notification device tokens, and Safe metadata such as creation time, trigger type, and current state.

What a breach of our servers would expose. The relationship graph and account identifiers — sentences like "Alice has designated Bob and Carol as her Releasees, holds 5 active Safes, last checked in June 4." What it would not expose: the contents of any Safe, the contents of any shard, your password, your private key, or any decryption key. Content stays content-private. The graph does not.

The Signal comparison. This is the same boundary Signal draws. Signal's message contents are end-to-end encrypted, but Signal's servers know which phone numbers are registered and when they connect. We sit in the same conceptual zone: content-private, relationship-graph-visible. Hiding the relationship graph too — through techniques like private set intersection, oblivious routing, or fully blind delivery — is active cryptography research, not production-ready for a system that has to deliver real content on a 30-year schedule.

Where we're going from here. Reducing this exposure is on the roadmap: hashed identifiers on relationship tables, KMS-managed encryption at rest, and opaque-token routing that replaces direct user references with revocable handles. Each hardening step will ship with a public note explaining what changed and why. We won't claim a guarantee we haven't built.

AI-worm resistant by design

As AI assistants gain access to inboxes, calendars, and file systems, a new class of attack has emerged: prompt-injection “worms” that hide instructions inside ordinary-looking content and trick AI agents into leaking data or spreading.

Time Release Safes is structurally immune to this attack class:

• Your files are encrypted on your device before they leave it. An AI worm in your recipient’s inbox can read the surrounding email — but not what’s inside the Safe.
• Release emails carry links, not content. AI summarizers can’t extract Safe contents from a mailbox; they have to go through our authenticated viewer.
• The in-app Assistant is deterministic, not an LLM. There is no agent inside the product to hijack with hostile instructions.
• Trust invitations use signed verification tokens. Auto-clicking AI bots can’t impersonate someone by following a link.

These architectural choices were made deliberately for exactly this class of risk — and they compound as the threat landscape evolves.

External audit and bug bounty

We're commissioning an external security audit with a reputable firm (Trail of Bits, Cure53, or NCC Group) prior to public launch — and we'll publish the findings, including anything they find. Annual re-audits thereafter.

A public bug bounty program (HackerOne or Intigriti) opens with public launch. Trust earned by exposure beats trust earned by marketing.

Compliance posture

• SOC 2 Type II: readiness work begins after V1 launch.
• HIPAA: on the roadmap for the B2B / healthcare tier.
• GDPR / CCPA: compliant from day one. You can export everything, and you can delete everything.
• Data residency: currently US-only (AWS US-East). EU residency option planned for V1.5.

Patent

The email-bound multi-party delegated authorization model — both for content release and for account recovery — is the foundational architectural claim of TRS. Patent application has been filed for prior-art search. We don't talk about the patent because we expect to enforce it; we talk about it because if it issues, no other consumer service can build the same architecture without our license.