Vault — what it is: An encrypted folder that holds the user's identity and keys. It can live locally on their computer or be synced to a remote server.

The vault is private —Seed has no access to its contents.

• Local only — vault stays on the user's machine. No remote access, so it can't be used on other devices (e.g., desktop).

• Cloud synced — vault is synced to a server (like Dropbox) at a /vault path, enabling multi-device access.

• Desktop app: the user can choose between a local or a cloud vault. This is where the complex screen lives.

• Browser: local vault is not an option. Identity must always live in the cloud when using the web app (never on the user's device).

Key insight: Identity starts on one device. To use it across multiple devices, it has to move to the cloud. The user's private key is then in the cloud.

• The real user goal, not "create a vault" — it's "use Seed on my devices".

• The vault is an implementation detail. Users shouldn't need to understand it to get started.

• Where the complexity comes from. The current flow asks users to make an infrastructure decision (local vs cloud) before they've even used the product.

• Simplification principle: Hide the choice until it matters. Get the user working first, then surface storage decisions when they become relevant— for example, when they try to open Seed on a second device.

Use Dropbox as inspiration for the local-to-cloud transition flow.

1. Start on desktop: Seed creates your identity silently. No vault decision yet. You use the tool.

2. First trigger: user tries to open Seed on a second device, or explicitly goes to Settings → Devices. Only then do we explain that their identity needs to move to the cloud to be accessible elsewhere.

3. The moment of choice: framed not as "where do you want your vault?" but as "Do you want to use Seed on other devices?" Yes → we walk them through syncing. No → they stay local, no friction.

   1.