Authentication

The app gates entry behind the vault password — there are no accounts, no wallet connect, nothing to sign in to.

First visit

1. Open the app — the gate offers vault creation.
2. Choose a wallet count and a password (8+ characters).
3. The 24-word BIP-39 phrase is shown once. Write it on paper, confirm, and the vault is created encrypted in localStorage (jb:vault) and unlocked for the session.

Returning visits

The gate asks for the vault password. Unlocking derives all wallets from the decrypted phrase and verifies them against the stored address list — a wrong password fails decryption outright, a tampered vault fails the address check. The sidebar then shows wallet 0's address; lock from the same place.

Locking is just forgetting: the in-memory keys are dropped (JBVault.lock()), the encrypted blob stays. Closing the tab locks too.

Honest scope

This is not server-enforced access control — there is no server. A static page cannot stop anyone from reading it, and it does not try to. What the password protects is real: the AES-GCM-256 encryption of your keys. The security boundary is the vault, and the vault is genuine cryptography, not a login form.

One identity, two roles

There is no connected-wallet identity anymore — the vault is the identity:

• Wallet 0 — the deployer and funder. It receives your budget on the source chain, signs launchAndBuy, and its address is what canLaunch checks against the Pons whitelist.
• Wallets 1…N — the bundle. Funded by relay.link distribution, they buy progressively and hold the position.