What we can and cannot do

• A breach of our servers or database. The backend never holds a usable key. For time-lock safes it stores a drand-locked ciphertext that unlocks only at a future round; for multi-sig safes it stores material that needs a threshold of signer approvals. Dump the whole database and you still cannot decrypt.
• A breach of the storage network. Shelby only ever holds ciphertext. Your file is encrypted in this browser with AES-256-GCM before it leaves.
• Trying to open a time-lock early. It is mathematically prevented until the drand round publishes. That's the same timelock the rest of the world also can't shortcut.
• A reused retrieval link. Each private link is single-use: the first claim burns it, and every later attempt returns the same “no longer valid” response.
• Someone forcing or legally ordering us to hand it over. We hold no key, so there is nothing to give up.

• A compromised device at encryption time. If your machine is owned while you encrypt, the plaintext is right there. Nothing downstream helps.
• A compromised recipient email account. For email recipients, the link is the credential. Wallet recipients are immune to this, so prefer them for the most sensitive safes.
• Malicious served code. Any browser-delivered crypto app could in principle be served backdoored JavaScript. This can't be fully eliminated, but it is made detectable: the source is published and the bundles will carry integrity hashes you can verify.
• Metadata. We can see that a safe exists, roughly when it releases, and how many parties are involved. We can't see its title, its contents, or who the recipients are (those are encrypted).

A public safe proves a file existed and was sealed to open at a set time. It does not prove who created it or that the contents are true. Only that they were fixed in advance and could not be altered after sealing.