Bitkey

• Name: Bitkey
• URL: https://bitkey.world/
• Category: bitcoin self-custody system / collaborative multisig recovery architecture / hardware-app-recovery control plane
• Tags: bitcoin-ecosystem
• Summary: Bitkey is better cataloged as a collaborative Bitcoin self-custody system than as a simple hardware wallet. The important part is the recovery architecture: hardware signer, mobile app, server-held recovery key, multiple recovery paths, delay-and-notify protection, trusted-contact recovery, emergency access tooling, inheritance, and public hardware / app / server code. That makes it a Bitcoin custody-and-recovery operating stack built around coordinated key management rather than just a device brand. The broader named-operator and distribution boundary around Bitkey now lives separately in block.
• What it does:
  • Combines a hardware device, mobile app, and Bitkey-run server key into a 2-of-3 collaborative multisig custody model for bitcoin
  • Gives users two keys they control directly while Bitkey holds a third recovery-oriented key that cannot move funds alone
  • Provides several recovery paths including phone replacement, hardware replacement, trusted-contact-assisted recovery, and emergency access with the two user-controlled keys
  • Documents delay-and-notify protections around sensitive recovery actions and positions recovery / inheritance as core product features rather than afterthoughts
  • Publishes repository code for firmware, mobile apps, shared wallet logic, infrastructure, server components, and hardware schematics for transparency and auditing
  • Invests in privacy work around collaborative multisig, including Chain Code Delegation to avoid exposing wallet balance and transaction history to the service in normal operation
• Key claims:
  • The Bitkey development blog says Bitkey is a mobile app, hardware device, and set of recovery tools for simple, secure self-custody, which is more expansive than a standalone hardware-wallet pitch
  • The code-release post says Block published code for the hardware device, mobile app, server, and hardware schematics so auditors can verify Bitkey does what it claims, and it highlights reproducible-build goals for the app
  • The repository overview shows distinct codebases for firmware, Android/iOS apps, shared Rust and Kotlin layers, nodes, server / Wallet Security Module, and infrastructure-as-code, which reinforces that Bitkey is a full operating stack
  • The “There’s no seed phrase” post says the wallet uses three keys, requires two keys to move funds, and offers three main recovery routes plus an emergency-access path without relying on Bitkey’s server key
  • The “Not our keys, not our business” post says Bitkey implemented Chain Code Delegation so collaborative multisig can preserve privacy around wallet balances and transaction history in normal operation
  • The “Hardware wallets are not enough” post is especially useful for categorization because it explicitly frames Bitkey as solving for loss, theft, coercion, inheritance, and survivability rather than only secure signing
• Whitepaper: No canonical Bitkey whitepaper or litepaper surfaced in this pass. The clearest current sources of truth were the official development blog, public code repository, and technical/product posts on recovery, privacy, and open development; see ../whitepapers/bitkey-primary-sources-2026-05-01.md.
• Sources:
  • https://bitkey.world/
  • https://bitkey.build/
  • https://bitkey.build/sharing-the-code-behind-bitkey/
  • https://bitkey.build/what-do-you-mean-theres-no-seed-phrase/
  • https://bitkey.build/not-our-keys-not-our-business/
  • https://bitkey.build/hardware-wallets-are-not-enough/
  • https://github.com/proto-at-block/bitkey

Internal linkages

• Company / operator boundary above the product surface: block.
• Strongest recovery-architecture reads: casa and unchained.
• Hardware-signer provenance contrast: coinkite.

Protocol / company boundary

• Keep this note on the product surface: the collaborative custody architecture, the hardware signer, the mobile app, the Bitkey-held recovery-oriented server key, and the exact recovery / delay / inheritance flows users inherit.
• Use block for the named-operator layer above that product: release workflow, broader bitcoin distribution strategy, Square and Cash App adjacency, and the shared company boundary that packages Bitkey with other Block bitcoin surfaces.
• That split matters because how does Bitkey recovery work? and who controls the wider distribution and policy shell around Bitkey? are related but not identical questions.

Control surface

• The leverage at the product layer is in recovery policy: who can trigger which path, how long delay-and-notify windows are, what the Bitkey-held server key can and cannot do, and how trusted-contact or inheritance flows are operationalized.

• Firmware openness matters, but it is not the whole note. The system lives or dies on coordinated policy across hardware, app, server, recovery tooling, and user communication.

• Read Bitkey as a custody-and-recovery operating model with a hardware signer attached, not as just another device SKU. For the broader corporate and distribution shell above it, read block.

• Last reviewed: 2026-08-07 UTC