Keylay

Overview

What this setup does and what you need.

This guide uses a 2-of-3 multisig configuration: three ColdCard Q hardware wallets each hold one key, and any two of the three are required to sign a transaction. Sparrow runs as a watch-only coordinator on a computer — it holds no keys and cannot spend funds, but it assembles the wallet, tracks balances, and constructs transactions. Keylay is the coordination layer that lets remote participants securely exchange the data needed for setup and signing without relying on email, messaging apps, or a trusted server.

You can adapt this to a different threshold (2-of-4, 3-of-5, etc.) by adjusting the Sparrow wallet policy. The per-step workflow is the same regardless of the number of signers.

What you need

ColdCard Q for each signer (firmware 1.0.0 or later)
Sparrow Wallet installed on a coordinator computer
A browser on each participant's device for Keylay
MicroSD cards for each ColdCard Q (optional but recommended)

What Keylay carries

Cosigner xpub data (setup phase)
Wallet descriptor / BSMS file (setup phase)
PSBTs during signing
Never: private keys, seed phrases, or funds

Privacy note. The wallet descriptor is a privacy exposure. Anyone who has it can see all incoming and outgoing transactions and the current balance. Do not share it outside the signing group. Keylay encrypts this data in transit, but care should be taken beyond the session as well.

Roles

What each component does.

ColdCard Q

Generates and holds private keys. Signs transactions. Verifies addresses. Never connects to the internet. The air gap is its primary security property — it handles all operations that touch private key material.

Sparrow

Watch-only coordinator. Assembles the multisig wallet from cosigner data, tracks balances and transaction history, constructs PSBTs for signing, and broadcasts finalized transactions. Holds no keys.

Encrypted relay between participants. Carries cosigner exports, wallet descriptors, and PSBTs across distance. Session codes connect participants without accounts. The relay server never sees plaintext.

Keylay sessions connect exactly two participants at a time. For a 2-of-3 multisig, the coordinator runs a separate Keylay session with each signer — three sessions during setup (one per cosigner exchange), and one or two sessions per signing round. This is how the tool works; plan session flows accordingly.

Part 1

Setup: assembling the multisig wallet.

Each signer generates a key on their ColdCard Q, exports their cosigner data, and sends it to the Sparrow coordinator via Keylay. The coordinator assembles the wallet, then sends the descriptor back to each signer.

1

Generate a key on each ColdCard Q

Each signer does this independently on their own device. From the ColdCard Q main menu, select New Seed Words, then choose 24 Words (recommended) or 12 Words. The Q generates the seed using its hardware random number generators and displays the words on screen. Write them down carefully in order. The device will then run a verification quiz — it asks for specific words in random order to confirm you recorded them correctly before saving the seed.

Do not read seed words aloud, photograph them, or type them into any document. Write on paper, verify the words, and store in a location separate from the ColdCard Q. Storing the paper backup in a tamper-evident security bag makes unauthorized access visible; these are available from security supply vendors and general retailers. If the hardware device is lost or damaged, the seed backup is required to restore the key on a new device. If the seed backup is stolen, an attacker can import that key onto another device — in a 2-of-3 wallet this stolen key is not sufficient to spend on its own, but it reduces your effective security to a single remaining key. If both the hardware and the seed backup are lost or destroyed, access to that signer's key is permanently gone.

Each participant generates their own key independently. Keys meant for independent signers should be generated on separate devices in separate locations, never on the same ColdCard Q at different times.

Camera and mirror warning. Generate seed words in a location with no cameras, mirrors, windows, or other surfaces that could reflect the screen. A camera that captures your seed display at this stage gives an attacker one of your three keys.

2

Export cosigner data from ColdCard Q

The coordinator needs each signer's xpub and derivation path. On the ColdCard Q, go to Advanced / Tools → Export Wallet → Generic JSON, then press ENTER to confirm. This produces a file (named ccxp-[XFP].json where XFP is your key fingerprint) containing your extended public key and metadata — not your private key or seed.

You have two options for getting this data to the coordinator:

Via QR: The ColdCard Q can display the export as a QR code. Open Keylay on your browser, join the coordinator's session (see Step 3), and use Keylay's Start Scan button to scan the QR directly from the ColdCard Q screen. Keylay captures the data and sends it through the session to the coordinator.

Via MicroSD: Save the export file to a MicroSD card, copy it to a computer, and upload it through the Keylay session using Keylay's file upload.

3

Open a Keylay session and share cosigner data

The coordinator opens app.keylay.org and creates a session. The app produces a short session code. Share that code with the first signer out of band — a phone call, Signal message, or any channel you already trust. The session code never goes through Keylay itself.

The signer opens Keylay, enters the session code, and joins. The signer then sends their cosigner export through the session — via QR scan or file upload as described in Step 2. The coordinator downloads it from the session.

Because Keylay sessions are two-participant, the coordinator repeats this process with each remaining signer in turn — a fresh session per signer, or the same session reused if the previous signer has left. The coordinator collects one cosigner export from each of the three signers before proceeding.

4

Assemble the multisig wallet in Sparrow

On the coordinator's computer, open Sparrow. Go to File → New Wallet and give it a name. Under Policy Type, select Multi Signature. Set the threshold and total signers (for example, 2 Required, 3 Total).

For each cosigner, click Add Keystores and choose Airgapped Hardware Wallet. Click the ColdCard icon, then click Import File and select the cosigner export JSON file received from that signer via Keylay. Repeat for each of the three signers.

Before clicking Apply, confirm that all three keystores show the same script type — P2WSH for native SegWit multisig. Sparrow reads the script type from the derivation path in each JSON export and sets it automatically, but a mismatch across signers produces a wallet whose addresses no ColdCard Q will recognize. Once confirmed, click Apply. Sparrow will generate the wallet descriptor. This descriptor encodes the full wallet policy and must be distributed to every signer before the setup is complete.

5

Export the wallet descriptor from Sparrow

In Sparrow, go to Settings → Export Wallet. Select BSMS as the export format and save the file. BSMS is the standard descriptor format compatible with ColdCard Q's multisig import.

This descriptor file must be sent to every signer so that each ColdCard Q can recognize transactions and verify receive addresses. The coordinator uploads it through the Keylay session for each signer to receive.

6

Send the descriptor to each signer via Keylay

The coordinator opens a Keylay session with each signer in turn and uploads the BSMS descriptor file. Each signer downloads it.

Each signer then imports the descriptor to their ColdCard Q using one of two paths:

Via QR: The coordinator uploads the BSMS file to a Keylay session. The signer's Keylay browser displays it as a QR code. On the ColdCard Q, go to Multisig Wallets → Import from QR and scan from the browser screen. This works for both remote and co-located signers.

Via MicroSD: Download the BSMS file from the Keylay session, save it to a MicroSD card, and insert into the ColdCard Q. On the ColdCard Q, go to Multisig Wallets → BSMS (BIP-129) and select the file.

Either way, the ColdCard Q will display the descriptor details before asking you to confirm. Verify the threshold, total signer count, and each participant's XFP fingerprint match what was agreed. The practical way to do this: on the same voice call used to share the session code, each participant reads their 8-character XFP aloud — visible on the ColdCard Q and in Sparrow next to each cosigner entry. The coordinator confirms they have the right fingerprint for each signer; each signer confirms their own fingerprint appears in the descriptor alongside the correct threshold and signer count.

7

Back up the descriptor

Every signer and the coordinator should store a copy of the BSMS descriptor file in a secure location — separately from any seed phrase backup. Loss of the descriptor is a real failure mode: recovering the wallet without it requires manually reconstructing the wallet in Sparrow from each signer's xpub and derivation path. This requires cooperation from all signers and is difficult to do correctly. It is not a theoretical risk. Store a copy on each MicroSD card alongside the seed phrase backup paper, or in encrypted storage, in at least two geographically distinct locations.

8

Fund and test the wallet

In Sparrow, go to the Receive tab to generate a receive address. Before sending any significant amount, verify the address on at least one ColdCard Q: on the ColdCard Q, navigate to the multisig wallet and use the Address Explorer to confirm the address matches what Sparrow is showing. Hardware verification prevents address substitution attacks.

Send a small test amount. Once confirmed, complete a full test signing cycle (Part 2 below) to confirm that every required signer can participate before storing larger amounts.

Part 2

Signing: sending a transaction remotely.

The coordinator builds the transaction in Sparrow and exports a PSBT. The PSBT travels to each required signer via Keylay. Each signer signs on their ColdCard Q and returns the partially signed result. The coordinator finalizes and broadcasts once enough signatures are collected.

1

Build the transaction in Sparrow

In Sparrow, open the multisig wallet and go to the Send tab. Enter the recipient address, amount, and fee. Use Sparrow's coin control features if you want to select specific UTXOs. When ready, click Create Transaction, review the details carefully, then click Finalize Transaction.

Sparrow will display the PSBT (Partially Signed Bitcoin Transaction) — an unsigned or partially signed transaction file that gets passed to each signer in sequence. Save it as a binary file: Save Transaction → As Binary. This is the file you will upload to Keylay.

Sparrow is an untrusted transaction constructor. Sparrow runs on a networked machine and constructs the transaction, but it cannot be trusted to do so correctly if compromised. A compromised Sparrow can substitute a malicious recipient address or manipulate the change address. The ColdCard Q is the only verification point. Confirming the transaction on Sparrow's screen is not sufficient — verify every detail on the ColdCard Q before signing.

2

Send the PSBT to the first signer via Keylay

Open a Keylay session at app.keylay.org and share the session code with the signer. Upload the PSBT binary file to the session. The signer's Keylay browser receives the file and can display it as an animated BBQr sequence using the Show as QR for ColdCard button — the signer's ColdCard Q scans directly from the browser screen.

Alternatively, the signer can download the PSBT file from Keylay and transfer it to their ColdCard Q via MicroSD.

Note on Sparrow's "Show BBQr" button. Sparrow can also display the PSBT as a BBQr sequence directly. This is useful when the coordinator and signer are in the same room and the ColdCard Q is scanning from the coordinator's screen. For remote signers, route the PSBT through Keylay instead — the signer scans from their own Keylay browser session.

3

Sign on the ColdCard Q

The signer has two options:

Via QR: On the ColdCard Q, go to Scan Any QR Code and scan the animated BBQr displayed by Keylay in the signer's browser. The ColdCard Q will parse the transaction; display the destination address, amount, and fee for verification; and prompt for confirmation. After the signer approves, the ColdCard Q produces the signed PSBT as an animated BBQr on its screen.

Via MicroSD: Download the PSBT file from the Keylay session to a computer, copy it to a MicroSD card, and insert into the ColdCard Q. Go to Ready To Sign and select the PSBT file. After verification and confirmation, the ColdCard Q saves a signed PSBT back to the MicroSD card.

Always verify the destination address and amount on the ColdCard Q screen before signing. Do not trust amounts or addresses shown only on a networked computer screen.

4

Return the signed PSBT to the coordinator via Keylay

If signed via QR: The ColdCard Q displays the signed PSBT as an animated BBQr. In the signer's Keylay browser, click Start Scan and scan the BBQr from the ColdCard Q screen. Keylay captures the signed PSBT and sends it through the session. The coordinator clicks to download it on their end.

If signed via MicroSD: Copy the signed PSBT from the MicroSD card to a computer and upload it through the Keylay session for the coordinator to download.

The coordinator imports the signed PSBT into Sparrow: File → Open Transaction → From File. Sparrow will show one signature applied.

5

Collect the second signature

For a 2-of-3 wallet, one more signature is needed. The coordinator opens a separate Keylay session with the second signer and sends them the original unsigned PSBT — there is no need to wait for the first signer to respond before doing this. Once any two signed PSBTs are returned, Sparrow can combine them using Combine Transaction and broadcast. Alternatively, the coordinator can forward the partially signed PSBT from the first signer to the second, but this requires waiting for the first signer to respond before the second can begin.

It is also possible for the two signers to coordinate directly — Signer A sends the partially signed PSBT to Signer B through a Keylay session, Signer B signs and returns to the coordinator. The workflow is the same; only the session path differs.

6

Finalize and broadcast

Once Sparrow shows the required number of signatures, the Broadcast Transaction button becomes active. Review the final transaction one more time — recipient, amount, fee — then click Broadcast Transaction.

Sparrow connects to the Bitcoin network to broadcast. If you want to reduce address linkage, consider using a privacy-preserving node connection (your own node, or Tor) rather than a public Electrum server. Broadcasting through a public server reveals your transaction to that server operator before it reaches the mempool.

Receiving funds

Receiving is straightforward.

In Sparrow, go to the Receive tab. Sparrow will display the next unused receive address along with a QR code. Share the address or QR with the sender.

Before sharing an address for a significant amount, verify it on at least one ColdCard Q using the Address Explorer as described in Setup Step 8. This confirms that Sparrow's display has not been tampered with and that the address genuinely belongs to the multisig wallet.

No signatures are needed to receive funds. Before sharing a receiving address, any signer can verify it belongs to the wallet using the ColdCard Q's Address Explorer. Once funds appear on-chain, all signers can independently confirm the incoming transaction using their own Sparrow watch-only instance.

Security

What this setup protects and what it does not.

A 2-of-3 hardware multisig is a serious custody arrangement. Understanding its actual threat model prevents both overconfidence and unnecessary complexity.

What it protects against

Remote compromise of a single device or computer — an attacker who owns one key cannot spend
Loss or theft of a single device — the remaining two keys maintain access
Coordinator compromise — Sparrow holds no keys; a compromised coordinator machine cannot spend funds without two hardware signatures
Keylay relay compromise — the relay server sees only ciphertext; a compromised relay cannot read coordination data or spend funds

What it does not protect against

Physical coercion — someone who has physical access to two signers, or can compel two signers to sign, can spend
Supply chain attacks on hardware — address this with purchase from reputable sources and seed verification
Social engineering — an attacker who persuades two signers to approve a fraudulent transaction
Loss of enough signers to fall below the signing threshold — for a 2-of-3 wallet, if any two hardware devices are destroyed and their seed phrase backups are also gone, the funds are unrecoverable. Multisig raises the bar for this; it does not eliminate it.
Loss of the descriptor when no hardware device remains to re-export it — any functional ColdCard Q that holds the multisig wallet configuration can re-export the descriptor via Multisig Wallets → BSMS. The risk is losing all hardware and all descriptor copies simultaneously.

The threshold and signer distribution should match your threat model. For a family custody arrangement the risks are different than for an organization operating under surveillance risk. Consider who the signers are, where they are located, and under what conditions two of them could be compelled to sign simultaneously.

Ongoing maintenance

Keeping the setup working over time.

·

Test annually

Once a year, verify that each signer can access their ColdCard Q and load the multisig wallet, that the seed phrase backup is physically intact and readable, and that the BSMS descriptor file is available. Send a small test transaction through the full signing workflow. Firmware updates and hardware failures are most often discovered during routine tests, not during emergencies.

·

Recovery minimums

To recover full signing capability for this wallet, you need: any two seed phrases (from any two of the three signers), plus the BSMS wallet descriptor, plus a coordinator computer running Sparrow. Without the descriptor, recovery is technically possible if you know the derivation paths, xpubs, and wallet parameters exactly — but this is error-prone and should not be relied on. The descriptor cannot be used to spend funds, but it is privacy-sensitive — store it securely, and store it in multiple locations so it is available for recovery.

To recover a single signer's key only (for example, after a device is replaced), you need that signer's seed phrase and the BSMS descriptor to re-register the multisig wallet on the new device.

·

Store the descriptor separately from seed phrases

The descriptor and a seed phrase should not be stored in the same physical location. If both are compromised together, an attacker has the wallet structure and one key — not a full compromise for a 2-of-3, but it reduces the remaining attack surface to a single key. Store the descriptor in at least two geographically distinct locations accessible to the participants who need it for recovery.

·

Communicate recovery instructions to all signers

Each signer should know: the signing threshold, how to contact the other signers, where the descriptor is stored, and how to reconstruct the wallet in Sparrow from a seed and descriptor. Write this down and store it with each key backup — not in digital form. If a signer is unavailable during an emergency and no instructions were left, access may be delayed or lost.

·

Privacy considerations

Broadcasting transactions through a public Electrum server reveals your wallet's transaction history to that operator and links your IP address to your activity. Run your own Bitcoin node if this is a concern.

The wallet descriptor is a privacy exposure. Anyone who has it can see all incoming and outgoing transactions and the current balance. Limit access to participants who need it. Keylay encrypts coordination data in transit, but the session code should be shared through a channel you already trust — if an attacker learns the code before you begin, they could observe the coordination session.

Final rule

Verify on hardware. Always.

A networked computer screen can be compromised. Sparrow is open source and well-reviewed, but it runs on an internet-connected machine. The ColdCard Q does not. Every security guarantee this setup provides ultimately rests on the hardware device displaying the correct information and the signer reading it carefully before approving.

Verify the recipient address on the ColdCard Q screen before signing — check several characters spread across the address, not just the beginning or end. Attackers who generate substitute addresses often match the first and last few characters specifically to defeat quick checks. Verify the amount. Verify the fee. An attacker who has compromised the coordinator machine can substitute addresses or modify amounts in what Sparrow displays — the hardware is the last line of defense. If the ColdCard Q shows a different address than the one you intended to send to, do not sign.

Open App Security Model All Documentation