Timechain Wiki

Bitkey

12 min read

2026 update (2026-07-15): screened hardware revision

Block shipped a new Bitkey hardware version with an on-device OLED touchscreen (announced at Bitcoin 2026, late April; now on sale at $250). This directly addresses the original’s single biggest weakness — the absent trusted display — by letting the holder verify transactions and security-critical settings on the device rather than on the structurally hot phone. Unlock is fingerprint-only. The collaborative-custody-style 2-of-3 architecture (Bitkey key + phone key + Block recovery-server key) appears unchanged. The summary and analysis below still describe the original screenless model and should be read with this revision in mind; a fuller rewrite is a pending follow-up.

Bitkey, made by Block, Inc., is the hardware wallet most strongly associated with mobile-first, non-technical self-custody. The original shipped at 250**) — and it defaults to a 2-of-3 multisig where the Bitkey device holds one key, the phone holds the second, and Block's recovery server holds the third. This is collaborative-custody-like architecture wrapped in consumer-friendly UX. The trade-offs (as analysed for the original): the absent trusted display shifts verification onto the structurally hot phone (largely resolved by the 2026 screen), the Block-held key introduces counterparty exposure, and the opinionated 2-of-3 default cannot easily be reconfigured. For non-technical mobile-first holders who value recovery support over the strictest sovereignty, Bitkey is genuinely good; for the sovereignty-focused technical holder, it is the wrong device. The right comparison set is Bitkey vs Casa, not Bitkey vs Coldcard.

What this is

Vendor: Block, Inc. (formerly Square, Inc.; San Francisco). The product is part of Block’s broader Bitcoin-focused initiatives, which include the TBD payments platform, the Spiral non-profit Bitcoin Core funding arm, and the broader Cash App Bitcoin integration.

Product line as of 2026-05-14:

  • Bitkey (150) — single product. NFC-enabled hardware device; the 2026 revision adds an on-device touchscreen (original was screenless); pairs with the Bitkey iOS/Android app.

Firmware: Open-source under MIT licence. Reproducible builds. Available on GitHub.

Architecture: The Bitkey device contains a secure element (specifically, a device-bound secure enclave); the device communicates with the paired phone via NFC. There is no display, no buttons, no charging port (charging is via USB-C but for power only — the device runs primarily from a small internal battery topped up via NFC interaction).

The phone app provides:

  • Wallet address generation and management
  • Transaction construction and broadcasting
  • The holder-facing display of transaction details
  • The fingerprint-based confirmation (on the device) when signing

The device provides:

  • Secure key storage (one of the three keys in the 2-of-3 multisig)
  • Cryptographic signing
  • A fingerprint sensor for biometric authorization

The 2-of-3 multisig structure (this is opinionated and central to Bitkey’s design):

  • Key 1: held on the Bitkey hardware device
  • Key 2: held on the holder’s phone (encrypted, requires the phone’s biometric authentication to use)
  • Key 3: held by Block on a recovery server

Any two of these three can sign. Block alone cannot move funds (they have one of three). The holder with phone alone cannot move funds (they have one). The holder with phone + Bitkey can sign (most routine spending). The holder with Bitkey + Block recovery (after a phone loss) can sign. Block + phone can sign (if the Bitkey device itself is lost).

This is collaborative-custody architecture, with Block as the partner. See Collaborative custody services for the framework Bitkey instantiates.

Who this is for

Bitkey is a strong fit for:

  • Non-technical holders — the UX is consumer-friendly; the phone-app interface is familiar; the fingerprint authentication is standard
  • Mobile-first holders — Bitkey is designed around the phone as the primary interface; holders comfortable with phone-based banking will find it natural
  • Holders who want recovery support — the Block-held key means a single device loss is not catastrophic; a phone reset is not catastrophic; both losses are recoverable with Block’s assistance
  • The wrench-attack-concerned non-technical holder — the 2-of-3 structure means a thief with the hardware device alone cannot move funds; this is structurally stronger than a single-sig setup against physical theft
  • First-time Bitcoin holders moving from custodial to self-custody — Bitkey is a gentler step than going directly to Coldcard

Bitkey is less appropriate for:

  • Strict sovereignty holders — the Block-held key is fundamentally a partnership; for holders who want pure self-custody with no counterparty, Bitkey is the wrong device
  • Technical holders comfortable with traditional hardware wallets — Bitkey’s opinionated design removes flexibility (no descriptor export to other coordinators, limited multisig configurations beyond the default, etc.)
  • Multi-vendor multisig holders — Bitkey doesn’t pair with other devices in the conventional multi-vendor multisig sense
  • The Block-skeptical — for holders philosophically opposed to large corporations holding any part of their wallet infrastructure, Bitkey is structurally incompatible
  • The strictly air-gapped — Bitkey requires the phone for every operation; the phone is structurally hot

Features and capabilities

Bitkey specifics

  • NFC — primary signing channel; fast, contactless
  • Fingerprint sensor — on-device biometric authentication
  • No screen, no buttons — the phone is the entire interface
  • Small internal battery — topped up via NFC; no charging cable needed for routine use
  • USB-C — for occasional firmware updates and recovery scenarios
  • Secure element — device-bound; signing happens internally; the key never leaves the device
  • Physically small and durable — keychain-sized; designed to live in a pocket or on a keyring

The Bitkey software stack

  • Bitkey iOS/Android app — the entire user interface
  • Block recovery service — the third key in the 2-of-3 multisig
  • Recovery flow — if Bitkey or phone is lost, the holder can recover with Block’s assistance (typically requires identity verification through Block’s process)

Bitkey-specific quirks

  • The “no trusted display” design choice — every other mainstream hardware wallet has a display the holder can verify against. Bitkey trusts the phone. The argument is that for non-technical holders, the trusted-display security model fails because holders don’t actually verify the addresses anyway; the convenience-driven design is more honest. The counter-argument is that for holders who do verify, Bitkey removes that protection.
  • The opinionated 2-of-3 — holders cannot easily reconfigure Bitkey to use a different multisig structure or to operate single-sig.
  • Block as the recovery partner — non-negotiable; Bitkey holders have a permanent relationship with Block for the recovery key.

Tradeoffs vs alternatives

DimensionBitkeyColdcard Mk4BitBox02 BTC-onlyTrezor Safe 3Casa multi-key
Price150)$150$149$79Variable (subscription)
Bitcoin-onlyYesYesYesNoYes (typically)
Open-sourceYes (MIT)Source-availableYes (OSI)Yes (GPL)App open-source; service proprietary
Has its own displayNoYesYesYesN/A
Counterparty riskYes (Block)NoNoNoYes (Casa)
Default multisig2-of-3 (Block-partnered)None (user choice)None (user choice)None (user choice)2-of-3 (Casa-partnered)
Recovery supportYes (Block)NoneNoneNoneYes (Casa)
Holder profileNon-technical, mobile-firstTechnical, sovereignty-focusedMainstreamMainstreamTier 2+ collaborative
Multi-vendor pairingNoYesYesYesN/A

Bitkey occupies a different position from the other hardware wallets — closer to collaborative custody services like Casa than to standalone hardware wallets. The right comparison set is “Bitkey vs Casa,” not “Bitkey vs Coldcard.”

Setup and operation

The setup flow:

  1. Verify packaging — tamper-evident packaging from Block
  2. Install Bitkey app — iOS or Android
  3. Pair Bitkey with phone via NFC — initial pairing exchanges device identity
  4. Set up the Bitcoin wallet — the app walks through generating the multisig:
    • Bitkey generates Key 1
    • Phone generates Key 2 (stored encrypted on the phone)
    • Block provides Key 3 (held on Block’s recovery server)
  5. Register with Block — identity verification for the recovery service
  6. Backup the phone key — the phone-resident key has a recovery flow; holders are walked through it

The signing flow:

  • Holder initiates spend in the Bitkey app
  • App constructs the transaction
  • App signs with the phone-resident key (after biometric authentication)
  • App requests signature from Bitkey via NFC; the Bitkey device is tapped to the phone
  • Bitkey fingerprint-authenticates the holder; signs internally
  • App now has 2 of 3 signatures; broadcasts the transaction
  • Block’s key is not needed for routine spending

The recovery flow (phone lost):

  • Holder obtains a new phone; installs Bitkey app
  • App walks through re-pairing with the Bitkey hardware device
  • Block validates the holder’s identity through its recovery process
  • App reconstructs the wallet from Bitkey + Block keys

The recovery flow (Bitkey lost):

  • Holder reports loss to Block
  • Block validates identity
  • App walks through generating a new Bitkey-replacement key
  • New 2-of-3 multisig configuration is established (with the new Bitkey, phone, Block)

Security considerations

Strengths

  • 2-of-3 multisig by default — substantially stronger than single-sig against physical theft
  • Fingerprint authentication on-device — adds a biometric layer
  • Open-source firmware and app
  • Recovery support — the Block-held key means single-device losses are recoverable
  • Small attack surface on the device itself — no screen, no input methods beyond fingerprint
  • The holder cannot accidentally expose the seed — there is no displayed seed phrase in the conventional sense; the wallet is reconstructed via the multisig keys

Known concerns

  • No trusted display — the phone-app is the only interface for verifying transactions. A compromised phone could in principle display one address while the underlying transaction sends to another. The defence depends on the phone’s security model.
  • Block-held key — the recovery service is also a counterparty exposure. Block cannot move funds alone (one of three keys), but Block’s solvency, integrity, and continued operation are factors.
  • Phone as the central interface — phones are continuously exposed to remote attacks. The phone’s compromise has greater consequences in Bitkey’s architecture than in traditional hardware-wallet architectures.
  • The closed nature of the 2-of-3 default — holders cannot easily transition to true sovereign multisig without leaving the Bitkey ecosystem
  • Block’s broader business interests — Block is a public company with regulatory obligations; the recovery key is in principle subject to court orders or regulatory action

Supply-chain integrity

Buy directly from bitkey.world or authorized resellers. Tamper-evident packaging. The Block brand provides regulatory accountability that smaller hardware-wallet vendors don’t have, which is a partial defence against some supply-chain risks.

Pricing and acquisition

As of 2026-05-14:

  • Bitkey: 150); sometimes bundled with discounts during promotional periods
  • No subscription fee — unlike Casa or Unchained collaborative-custody plans, Bitkey’s recovery service is included in the device price (Block’s business model relies on broader Block ecosystem revenue rather than per-customer subscription)

Authorized channels: bitkey.world directly; Block’s retail partners; some Bitcoin-focused stores.

Common pitfalls

Buying Bitkey expecting traditional hardware-wallet behaviour. Bitkey is a different architecture. The opinionated 2-of-3 default and the Block-partnered structure are not negotiable; holders expecting to configure Bitkey like a Coldcard will be frustrated.

Treating the Block-held key as a security flaw. It is a deliberate design choice that introduces counterparty risk in exchange for recovery support. Whether the trade is right depends on the holder’s threat model; treating it as inherently bad misses what Bitkey is optimizing for.

Using Bitkey for substantial holdings without engaging the Block counterparty question. For Tier 2+ holdings, the Block partnership becomes a meaningful concentration of trust. The holder should engage the question rather than defaulting.

Treating the phone as cold storage. The phone-resident key is structurally hot. Bitkey’s architecture is multisig-with-hot-component, not deep-cold-multisig.

Forgetting that Block has KYC information. The recovery service requires identity verification. Bitkey holders have a paper trail at Block. For privacy-conscious holders, this matters.

Trying to bridge Bitkey to other coordinators. Bitkey is designed to work with the Bitkey app; bridging to Sparrow or Nunchuk is not the intended use case and is poorly supported.

Buying Bitkey for the wrong holder. A technical holder who wants sovereignty will find Bitkey too constrained. A non-technical holder who wants simplicity will find Coldcard too operationally heavy. Match device to holder.

Tooling and resources

Bitkey documentation (as of 2026-05-14):

  • bitkey.world — official site
  • Bitkey help center — comprehensive
  • The Block blog and Spiral blog — Bitkey context in the broader Block ecosystem
  • The Bitkey GitHub repositories — open-source firmware and app

The Bitkey app:

  • iOS and Android — the primary user interface

The synthesis document: Bitcoin Self-Custody & Security (LegacyCipher, April 2026) — Bitkey treated as the non-technical mobile-first option with the structurally different architecture explicitly flagged.

As of 2026-05-14: Bitkey has been shipping since 2024; firmware and app are actively updated. Block’s broader Bitcoin commitments suggest continued development.

Open questions for further development

  • The “no trusted display” design choice is contested. Does the empirical record support the argument that non-technical holders don’t actually verify addresses, making the trusted-display security model less load-bearing than it appears? Or do attacks against Bitkey holders vindicate the traditional trusted-display approach?
  • Block’s regulatory exposure is a meaningful question for the Block-held recovery key. How would court orders or regulatory action affect Bitkey holders in different jurisdictions?
  • The Bitkey 2-of-3 default is opinionated. Should the framework recommend Bitkey for specific user profiles, or treat it as a structurally different product from the rest of the hardware-wallet category?
  • The Bitkey vs Casa comparison is more meaningful than the Bitkey vs Coldcard comparison. Should the framework restructure its hardware-wallet vs collaborative-custody categorization to reflect this?

The framing context:

Per-device alternatives:

Relevant capabilities:

The principal practitioners:

The sub-MOC home:

Graph View

Backlinks