Development and test wallet · Chrome MV3 · Bitcoin focus
Gandalf is a browser extension wallet with a Rust/WASM signing core, an encrypted local vault, and a Wallet Chain API (WCA) v1 proxy boundary. Bitcoin is the current product focus. The software is early-stage and intended for development and test use.
Interface preview · example data
0.034200 BTC
01 · Why
A wallet send path includes network identity, destination, amount, fee, inputs, outputs, signing, and result state. Gandalf keeps those steps visible instead of compressing them into a single ambiguous confirm control.
Seeds, passwords, and private keys stay inside the extension and Rust/WASM runtime. Only signed transactions cross the network boundary.
Network, destination, amount, fee, and (where applicable) inputs, outputs, and change are shown before the password is requested.
Pending, confirmed, rejected, offline, and wrong-network outcomes remain separate instead of collapsing into a generic failure.
02 · How it works
The browser extension owns vault state, review UI, and signing. The proxy normalizes provider APIs. Network infrastructure never receives signing material.
Browser extension (React UI · encrypted vault · transaction review)
└─ Rust core → WebAssembly (derive · plan · authorize · sign · zeroize)
│ Wallet Chain API v1 — public data or signed payloads only
▼
Gandalf Proxy (capabilities · identity checks · adapters · broadcast · status)
│ provider-specific APIs
▼
Network infrastructure (Esplora · Horizon · gateways · …)Create a wallet or import supported material into an encrypted local vault. Set a password and account name.
Show a receive address. For send, enter destination and amount with field-level validation.
Confirm network, destination, amount, fee, inputs, and outputs. Unseal only at the signing boundary in WASM.
Submit the signed payload. Track pending, confirmed, and rejected outcomes separately.
03 · Scope
Bitcoin is the immediate product focus. Catalog presence or design-system colors do not imply a live signing path. Experimental ledger adapters in the repository are not part of the current public product promise.
| Area | Current implementation |
|---|---|
| Vault | BIP39 and supported key imports; Argon2id and XChaCha20-Poly1305 envelope with authenticated public metadata; multi-account metadata |
| Bitcoin | BIP84/86 derivation, WIF import, P2WPKH and P2TR planning/signing; Esplora and development adapters |
| Client | Chrome Manifest V3 popup, onboarding, account and network switching, receive and send flows, pending transaction tracking |
| Proxy | Rust/Axum WCA v1 service: network registry, health, state, validation, broadcast, and status routes |
| Protocol | Versioned JSON schemas, network registries, and cross-language cryptographic/transaction fixtures |
| In repository, not product promise | Experimental adapters (for example Stellar and primary development-ledger paths) used for research and local stacks |
| Not complete | Chrome Web Store distribution; Cardano, XRPL, and EVM-family product paths; full release-stage security review |
04 · Proxy
The proxy sits outside the custody boundary. It translates upstream infrastructure into one versioned contract and never receives private signing material. Direct provider paths can remain available for debug or environment-specific use when configured.
chain-api/v1
Versioned contract
Wallet surfaces consume a deliberate schema instead of each provider’s private API shape. Amounts cross the API as decimal strings in the smallest unit.
No secret transit
The proxy reads network state and submits signed payloads. It does not hold seed phrases, passwords, or private keys.
Honest failure
Offline, rejected, unsupported, and wrong-network outcomes remain distinct so recovery paths can stay specific.
Local development default listen address: http://127.0.0.1:18765.
A hosted production WCA endpoint is planned only after operational and privacy review.
05 · Security model
The extension is the trusted client boundary. The proxy, providers, and networks are untrusted inputs. The table below is the documented model, not a claim of completed independent audit.
| Boundary | Enforced rule |
|---|---|
| Secrets | Not returned across the serialized WASM API |
| Vault | Argon2id (65,536 KiB, 3 iterations, 1 lane); XChaCha20-Poly1305 with random salt and nonce; authenticated metadata |
| Authorization | Each signature path decrypts again with the user password |
| Network | Identity mismatches abort; test-family Bitcoin accounts do not default to mainnet |
| Extension | MV3, self-hosted code, strict CSP, no content scripts, explicit host permissions |
| Proxy | Public chain data and signed payloads only; no custody and no signing |
Suspected vulnerabilities should not be filed as public issues. Use private vulnerability reporting for the repository owner until a dedicated security mailbox is published. Do not include real wallet secrets or mainnet keys in a report.
06 · Roadmap
An item is treated as done only after its acceptance tests pass. The intended first public release is a testnet-oriented build when store packaging and release checklist work are ready.
Protocol fixtures, Rust core and vault, extension foundation, onboarding, read-only sync, and first end-to-end transfers on supported development and test paths.
Bitcoin crypto and send flow, WCA schema, proxy adapters, and public Bitcoin network profiles as documented in the wallet roadmap. Product messaging remains Bitcoin-first.
Reliability and recovery; security and release checklist; fee-economics research; additional ledger families only when they exit experimental status; hosted production WCA after operational and privacy review.
07 · Visual system
The public website and the extension import the same design-system stylesheet. Theme (light/dark) and density (comfortable/compact) are independent. Product CSS may compose layout but must not redefine the token architecture.
Wider spacing and section hierarchy for project documentation.
Denser rows for balances, history, and signing review in the extension popup.
Reference site: gandalfsystem.com.
Updates
Very low-frequency email about wallet milestones, network support, security work, and releases: one or two messages per month at most. No market alerts.
Further reading
Design system reference and the sections above. There is no public install link while the extension remains unpacked-only.