Skip to content

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

Description

@hellno

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).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions