Problem
Spotted while removing the `console.log` security leaks in 747b4d0. Both connect-modal password steps don't actually do anything with the keystore / mnemonic they were meant to consume.
`views/ConnectModal/MnemonicPassword.js`
After 747b4d0 the handler is:
```jsx
const handleConfirm = () => {
setPassword(); // <- called with no arg — sets password to undefined
setStep(4);
};
```
The mnemonic that was generated in the previous step (`views/ConnectModal/Mnemonic.js` → `MnemonicSeed` state in parent) is never combined with the password to produce an encrypted keystore. The user types a password, clicks Confirm, the password is silently dropped, and the modal advances to step 4 (success).
`views/ConnectModal/KeystorePassword.js`
```jsx
const handleConfirm = () => {
setTimeout(() => {
setStep(6); // success
// success is 6 error is 7
}, 1000);
};
```
The user uploads a keystore file (`UploadKeystore.js` → `KeystoreFile` state), enters a password, clicks Confirm — the handler does nothing with either. It just `setTimeout`s a step advance to "success" 1 s later. There's no decryption, no signer creation, no error path — just a fake delay before declaring success.
Why this matters
The wallet primarily uses cosmos-kit for actual key management (Keplr, Leap, Cosmostation extensions), and these mnemonic/keystore flows look vestigial — left over from an earlier "manage your own key" intent. But they're still wired into the live UI (`views/ConnectModal/index.js` cases 5 + 10), which means users can:
- Generate a mnemonic
- Enter a password "to encrypt" it
- See a "Success" screen
- Have nothing useful happen — the mnemonic isn't saved anywhere encrypted, the password isn't bound to anything, and they have no way to use this seed in the wallet afterwards.
That's misleading UX for what is effectively a no-op flow, and worse, the mnemonic state lingers in React (see #199).
Proposed fix — pick one
A. Remove the dead flows. If the official onboarding is "use Keplr/Leap", strip:
- `Mnemonic.js`, `MnemonicPassword.js`, `GenerateKeystore.js`, `KeystorePassword.js`, `UploadKeystore.js`
- The corresponding step cases (5, 8, 9, 10) in `views/ConnectModal/index.js`
- The "Generate keystore" / "Use keystore" buttons in `views/ConnectModal/ChooseOption.js`
B. Implement them properly. If self-custody mnemonic support is on the roadmap:
- Encrypt mnemonic with password using `@cosmjs/proto-signing`'s `Secp256k1HdWallet.serialize(password)` → store ciphertext in browser `localStorage` keyed by an account-id.
- On unlock, `Secp256k1HdWallet.deserialize(ciphertext, password)` → use as offline signer.
- Wire that signer into the cosmos-kit wallet repository so the rest of the app sees it as just another wallet option.
(Pre-req for B: settle #199 first so the secret material has a defined retention model.)
Acceptance
If A: the unused flows are gone and the connect-modal options screen no longer offers them.
If B: a fresh user can complete the create-with-password flow and the next session can unlock with the same password and sign a transaction.
Background: surfaced while removing the `console.log` leaks in 747b4d0.
Problem
Spotted while removing the `console.log` security leaks in 747b4d0. Both connect-modal password steps don't actually do anything with the keystore / mnemonic they were meant to consume.
`views/ConnectModal/MnemonicPassword.js`
After 747b4d0 the handler is:
```jsx
const handleConfirm = () => {
setPassword(); // <- called with no arg — sets password to undefined
setStep(4);
};
```
The mnemonic that was generated in the previous step (`views/ConnectModal/Mnemonic.js` → `MnemonicSeed` state in parent) is never combined with the password to produce an encrypted keystore. The user types a password, clicks Confirm, the password is silently dropped, and the modal advances to step 4 (success).
`views/ConnectModal/KeystorePassword.js`
```jsx
const handleConfirm = () => {
setTimeout(() => {
setStep(6); // success
// success is
6error is7}, 1000);
};
```
The user uploads a keystore file (`UploadKeystore.js` → `KeystoreFile` state), enters a password, clicks Confirm — the handler does nothing with either. It just `setTimeout`s a step advance to "success" 1 s later. There's no decryption, no signer creation, no error path — just a fake delay before declaring success.
Why this matters
The wallet primarily uses cosmos-kit for actual key management (Keplr, Leap, Cosmostation extensions), and these mnemonic/keystore flows look vestigial — left over from an earlier "manage your own key" intent. But they're still wired into the live UI (`views/ConnectModal/index.js` cases 5 + 10), which means users can:
That's misleading UX for what is effectively a no-op flow, and worse, the mnemonic state lingers in React (see #199).
Proposed fix — pick one
A. Remove the dead flows. If the official onboarding is "use Keplr/Leap", strip:
B. Implement them properly. If self-custody mnemonic support is on the roadmap:
(Pre-req for B: settle #199 first so the secret material has a defined retention model.)
Acceptance
If A: the unused flows are gone and the connect-modal options screen no longer offers them.
If B: a fresh user can complete the create-with-password flow and the next session can unlock with the same password and sign a transaction.
Background: surfaced while removing the `console.log` leaks in 747b4d0.