What we can and cannot do

• A breach of our servers or database. The backend never holds a usable key. For time-lock drops it stores a drand-locked ciphertext that unlocks only at a future round; for multi-sig drops 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 — 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.
• Coercion or subpoena of the operator. We have no key to surrender.

• 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 — prefer them for the most sensitive drops.
• 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 drop exists, roughly when it releases, and how many parties are involved — but not its title, its contents, or who the recipients are (those are encrypted).

A public drop 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.