Spec: hardware-wallet signing as a signer kind behind signerd (Ledger/Trezor) — lower priority #78

Status

In scope, lower priority — a spec + discussion issue, not slated for immediate build (~months out).

Why

• Biggest credibility / safety gap for a self-custodial wallet; serious users expect it.
• A HW signer fits the key-isolation thesis better than a software key in signerd: the device holds the key and signs on-device, so the host — even a perfectly isolated signerd — never has the secret. The device is the isolation.
• Slots behind the existing boundary: signerd already owns signing (signing.rs); a HW signer becomes another signer kind, app / agent stay key-less, the policy gate + approval flow are unchanged (the device adds a physical second confirmation).

The hard constraint (design-defining)

EOA HW devices sign secp256k1 only. Railgun private spends use babyjubjub (railgun_keys.rs) — a HW device cannot produce them. So HW covers public txs (Send / Swap / approve / shield-deposit) but the private spend path still needs a software key → a split-custody model (HW public, software-keystore private). Spec must define how that split is presented, and whether a HW-only (no-private) mode exists.

Open questions to spec

• Vendor scope: Ledger first, or Ledger + Trezor (Stage-1 wants 3+)? Trezor adds transport complexity.
• Deps: alloy signer-ledger / signer-trezor pull HID / USB transport crates — real new-dep footprint (no-new-deps approval + cargo-deny / Supply-chain: add cargo-vet (who-reviewed-the-code provenance), non-blocking first #75 cargo-vet entries). Quantify.
• How the device confirmation composes with the policy gate + in-app approval (two confirmations? device replaces the hold-to-confirm for HW accounts?).
• Account model: a HW account as a new kind alongside the HD seed, without disturbing the seed envelope.
• Split-custody UX honesty: public on HW, private on software — acceptable, or does it undercut the privacy story?
• Relationship to secure-enclave unlock (design: multi-surface design foundation (DESIGN.md + CLAUDE.md) #5) — both "hardware-backed," different layers.

Not now

Lower priority; spec + discussion only. Implementation is a prioritized follow-up.

Files (when built)

crates/deckard-signerd/src/{signing,config}.rs, crates/deckard-core (account model), crates/deckard-app (HW onboarding + signing UX), Cargo.toml (alloy HW features — approval-gated).

Grounding: WALLETBEAT #4, the key-isolation thesis, railgun_keys.rs (babyjubjub).