Steps 1–2 · Seed & Wallets

The pipeline's foundation: one seed phrase, X derived wallets.

Step 1 — Generate the seed

In the Setup view, enter a wallet count (2–32) and a vault password (8+ characters), then Generate.

The app shows the BIP-39 phrase once — a numbered grid of words. Write it on paper. It is never shown again and never stored in plaintext. Behind the overlay, JBVault.create(count, password) encrypts the phrase into the browser's localStorage (jb:vault, PBKDF2-SHA256 + AES-GCM-256) and derives the X wallets.

A vault can only be generated once. If one exists, the Generate button refuses — that is deliberate, not a bug.

Step 2 — Wallets are derived

All X addresses are derived from the phrase at m/44'/60'/0'/0/i and stored alongside the vault as a plaintext address list — addresses are not secrets, and they are exportable as CSV (JBVault.exportCSV()). The Wallets view lists them with live ETH balances.

Wallet 0 is special — it is the funder. Everything downstream (distribution, the deployer's launchAndBuy) flows through it. The other wallets are the bundle that buys and holds.

In the browser

Call	Notes
JBVault.create(count, password)	returns {mnemonic, addresses} — mnemonic rendered once, discarded
JBVault.unlock(password)	opens the vault into tab memory; verifies the derived addresses against the stored list
JBCore.multicall([…])	batches the per-wallet getEthBalance reads behind the Wallets view

Until this is done

The progress bar reads 0/4, step 1·2 shows pending, and New Launch is locked — the gate is computed in-page from real state (Vault.exists(), wallet count), so no stale UI flag can open it early.