How it keeps things locked

Think of your vault as a safe. The combination is made from two pieces: the password in your head, and a short setup code you are given once. Your phone or laptop puts them together to open the safe. The server stores the safe, and has never seen either piece.

kept on the server

your saved passwords: stored locked. The server has no way to open them.
the key to your vault: also locked, and it only opens with your password and setup code.
the list of your devices: so a new phone can be recognised, and an old one switched off.
your email address: locked under a separate key, used for sign-up and alerts.

never leaves your device

your master password: never stored, never sent. If you forget it, nobody can look it up.
your setup code: you get it once when you sign up. Keep it somewhere safe and separate.
the key itself: built on your device each time you unlock, then thrown away.
your recovery kit: the one way back in if you lose a device. It lives with you.

If you lose something

Lose a device and you switch that device off from another one. It stops working. Your passwords do not need changing, because that device only ever held a copy of the safe, not the combination.

Forget your master password and there is no reset email. That is the trade for nobody else being able to open your vault. The recovery kit you are given at sign-up is the way back in, so put it somewhere you will still have it in five years. A drawer at home beats a file on your desktop.

The technical version

Skip this unless you want it. The protocol and threat model documents carry the full write-up, including what this design does not protect against.

unlock: Argon2id, 64 MiB, 3 passes; the memory-constrained profile from RFC 9106. A device that cannot afford it refuses to unlock rather than dropping to weaker parameters.
vaults: XChaCha20-Poly1305; a fresh record key per revision, wrapped under the current vault key.
sign-in: OPAQUE; the server keeps a record it cannot run a dictionary attack against, and a wrong password tells it nothing.
second factor: WebAuthn, optional; checked after the PAKE completes. Without one, phishing resistance is the client’s pinned origin.
signatures: Ed25519; one key per purpose, with the purpose in the signed bytes, so a signature cannot be reused elsewhere.
writes: signed per device; a stolen session downloads ciphertext. It cannot write and it cannot unlock.
sharing: HPKE to a verified key; the recipient checks your signed account history first. A key the server hands over proves nothing.
automation: scoped credentials; one vault set and a write flag per credential. Mint one per CI job, revoke it on its own.