External signers
Keeping the key on a device that never goes online, how transactions cross the gap on BSV, and what the user has to check for it to be worth anything.
An external signer is a device whose only job is to hold a key and sign with it. It never browses, never installs anything, and in the strictest setups never connects to a network at all. A transaction is carried to it, approved there, and the signature carried back.
The protection is specific and worth stating precisely: it protects against a compromised computer. Malware on the phone or laptop can see everything that happens there and still cannot reach the key, because the key was never there. It does not protect against a user who approves the wrong thing on the signer's own screen, which is why that screen is the whole design.
Crossing the gap
The transaction has to get to the signer and the signature back, without a shared network. Three ways:
- USB or Bluetooth. Convenient, but a connection, which some owners accept and others bought the device to avoid.
- Removable storage. Slow, awkward, genuinely air-gapped.
- Optical. The data is shown as codes on one screen and read by the other device's camera. Air-gapped with no cable and no card.
Optical is the one with a BSV-specific answer. A signed transaction with its supporting data is usually too large for a single code, so the fountain-coded air-gap transport (BRC-141) exists for it: the payload is broken into pieces and shown as an animated sequence of codes, and the reader collects pieces until it has enough to rebuild the whole thing. The camera does not have to catch any particular frame, or catch them in order, which is what makes scanning a large payload practical by hand.
Do
Show progress while an animated code is being scanned, as a proportion collected rather than a frame count. Users point a camera at a flickering screen for several seconds and need to know it is working.
What the signer has to show
A signer that displays a hash and an amount is a device that trains people to press approve. The point of the second screen is that it is the only screen malware cannot rewrite, so it has to carry enough for the user to catch a lie.
For a payment, the signer should show:
- the amount, in the unit the user thinks in
- who it is going to, by handle or saved contact name where the wallet knows it
- what is coming back as change, and that it is coming back to this wallet
- the fee, if it is anything other than negligible
That comparison is the entire security model: if the two screens disagree, the computer is lying, and the signer is the one to believe.
Do
Prompt the user to compare the signer's screen with the computer's before approving, and say which one to believe if they differ.
For anything that is not a payment, say what it actually is. "Sign message", "Prove an attribute", "Reveal key linkage" are different acts with different consequences, and a signer that calls all of them "Sign?" has given the user nothing to decide with.
BSV specifics
Commonly misunderstood: PSBT
Signer integrations often reach for PSBT (BIP-174) and output descriptors, the formats BTC signers use. They do not carry what a BSV signer needs: the transaction with its BEEF proofs and derivation details.
The signer needs context, not just a hash
Each payment's key is derived from the counterparty and an invoice number. A signer therefore needs the derivation details to know which key to use, and the user needs them to know what they are approving. Carry them across the gap with the transaction.
Verification needs proofs, not a chain
The signer cannot check the transaction's inputs against a blockchain it has never seen. The BEEF package carries the merkle proofs with it, so an offline device can verify the inputs against block headers it already holds. Keep its headers reasonably current: a signer that has been in a drawer for two years can still sign, but can verify less. See Nodes and verification.
What you can actually buy
The honest part, and the one that decides whether any of the above is a design you can ship.
The devices on sale are built around a different signing path, and no mainstream device ships native support for the BSV one (as of October 2026).
Where a hardware device works with BSV at all, it is older desktop software driving it down the legacy route: plain addresses, seed-derived keys, no certificates, no BEEF verification on the device. That still buys the one thing that matters most, a key the computer cannot reach, and it buys none of the rest. See Legacy compatibility.
Check before you design around one
This is the fastest-moving claim on this page. Verify current support with the manufacturer rather than with a guide, this one included, and treat an affiliate comparison site as marketing. A flow built around a device nobody can buy is a flow nobody can use.
Do
Design the capability, and be honest in the product about what exists. "Use a signing device" is a promise; "works with devices that support air-gapped BEEF signing" is a fact the user can check.
Don't
Build a savings or inheritance flow whose only safe path needs a device your users cannot obtain. Multi-key across phones and people is available today and is the better default until that changes.
Designing around one
Do
Treat the signer as one key in a set rather than the only key, where the amount justifies it. A single signing device that is lost is a total loss. See Multi-key.
Do
Let the wallet work read-only while the signer is away. Balances, history and receiving should all function without it, so the device is only needed to spend.
Do
Say what happens if the device breaks, during setup, not during recovery. The answer is the recovery material, and the user should have it before they need it.
Don't
Require the signer for receiving. Nothing needs signing to receive, and a wallet that asks for it has made the device a daily chore for no gain.
Who it is for
Not everyone. An external signer adds an object to keep track of, a routine to follow, and a second thing to back up. For an everyday wallet it is friction without much benefit, because the balance should be small enough to lose anyway.
It earns its place for savings, for long-held amounts, and for people who already own one.
Open questions
- Which signing devices support BEEF verification and derived keys natively, and when will that change?
Pros and cons
Pros
- A compromised computer cannot reach the key.
- The signer's screen is an independent check on what is being approved.
- Works well as one key in a multi-key set.
Cons
- A second object to keep, charge and find.
- Every payment takes longer, and optical transfer takes longer still.
- Lost or broken, it is a total loss without separate recovery material.
- Its value depends entirely on users reading its screen, which many will not.
Related
- Multi-key
- Nodes and verification: what an offline device can still check
- Savings wallet
- Hardware categories
Written from: BRC-100, BRC-141, BRC-42, ts-stack docs.
Checklist
The rules on this page, in a form you can work through.
8 rules