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 same battle-tested library Signal uses) before it ever touches our network. Each Safe gets its own symmetric key. That key is then wrapped — once per recipient — with the recipient's public key.

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. If a court order lands on our doorstep, we can hand over ciphertext and metadata — and that's all we have to give.

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)

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.