Background
The Keymaster derives each ID's signing key at the BIP44 path:
m/44'/0'/<account>'/0/<index>
(packages/keymaster/src/keymaster.ts:758, and three other call sites).
coin_type = 0' is Bitcoin in SLIP-0044. Archon DIDs are not Bitcoin — they're independent secp256k1 identities — but they share the Bitcoin derivation path space. A user who imports the same 12-word seed into a Bitcoin wallet would derive keys that collide with Archon DID keys at the same account/index.
This is a defense-in-depth / spec-hygiene concern, not a functional bug. Existing DIDs keep working; signatures don't change; nothing is broken today.
Documented in docs/services/keymaster/README.md §3.3.
What to do
-
Register a coin_type with SatoshiLabs. PR to satoshilabs/slips adding an entry for Archon. Pick an unused number outside densely-registered ranges; SatoshiLabs may push back and assign a different one, in which case we correct before shipping.
-
Add the new coin_type in code backwards-compatibly. Options in decreasing order of safety:
- Wallet-version bump (v3). Bump `WalletFile.version` to 3. New wallets use the Archon coin_type. Existing v2 wallets keep deriving at `0'` forever. Old Keymaster readers refuse to load v3 wallets rather than silently diverge.
- Per-ID `coinType` field on `IDInfo`, default `0` if absent. Old IDs unchanged, new IDs opt in. Needs care: older Keymaster binaries reading a wallet with mixed-era IDs would fall back to `0'` on the new IDs and compute wrong keys — so a version bump is still needed to gate readers.
- Don't register; keep `0'` forever. Valid choice if interop with hardware wallets / external SLIP-0044-aware signers isn't a goal.
-
Update the spec. docs/services/keymaster/README.md §3.3 says "BIP44-ish" — drop the hedge, document the exact path, and explain the coin_type choice (plus migration story once registered).
Out of scope
- Migrating existing DIDs to a new derivation path — there is no backwards-compatible way to do this. Existing DIDs are locked to their original signing key.
- Multi-seed / multi-wallet support (separate issue).
Acceptance
- SLIP-0044 PR merged (or a specific unregistered number chosen with rationale).
- Keymaster wallet schema version bumped.
- New IDs derive under the Archon coin_type; existing v2 wallets unchanged.
- Regression test: load a v2 wallet fixture, derive an ID's key, assert it matches the legacy bytes.
- Regression test: create a v3 wallet, export, reload, derive — round-trips identically.
- Spec updated.
Priority
Low. Nothing is broken; this is hygiene for future interop.
Background
The Keymaster derives each ID's signing key at the BIP44 path:
(packages/keymaster/src/keymaster.ts:758, and three other call sites).
coin_type = 0'is Bitcoin in SLIP-0044. Archon DIDs are not Bitcoin — they're independent secp256k1 identities — but they share the Bitcoin derivation path space. A user who imports the same 12-word seed into a Bitcoin wallet would derive keys that collide with Archon DID keys at the sameaccount/index.This is a defense-in-depth / spec-hygiene concern, not a functional bug. Existing DIDs keep working; signatures don't change; nothing is broken today.
Documented in docs/services/keymaster/README.md §3.3.
What to do
Register a coin_type with SatoshiLabs. PR to satoshilabs/slips adding an entry for Archon. Pick an unused number outside densely-registered ranges; SatoshiLabs may push back and assign a different one, in which case we correct before shipping.
Add the new coin_type in code backwards-compatibly. Options in decreasing order of safety:
Update the spec. docs/services/keymaster/README.md §3.3 says "BIP44-ish" — drop the hedge, document the exact path, and explain the coin_type choice (plus migration story once registered).
Out of scope
Acceptance
Priority
Low. Nothing is broken; this is hygiene for future interop.