The key ceremony

A key ceremony is the planned session where a company creates the keys for its multisig wallet, backs them up and proves it can recover them, all before any real funds move. This walkthrough follows a company 2 of 3 set-up with generic devices. It describes good practice in general terms and does not endorse any product.

1. Plan the roles first

   Decide who holds each key by role (for example two directors and a backup location), who prepares transfers and who approves them, and write it into the treasury policy. No one person should be able to move funds alone.

   Source: Bitcoin BIPs: BIP 11: M of N standard transactions (multisig).

2. Get three separate signing devices

   Use three hardware signing devices, ideally from more than one maker, bought directly from each maker or its authorised sellers. Using different makers means one product weakness is not enough to move funds. Install firmware only from each maker's official source and read its security advisories.

   Source: Bitcoin developer documentation: Wallets guide: signing-only wallets and hardware wallets, Coinkite: COLDCARD security advisory: weakened seed generation in affected firmware (July 2026).

3. Create each key on its own device

   Each keyholder creates their key on their own device, away from cameras and phones. The device shows a recovery phrase of 12 or 24 words. Nobody else sees it.

   Source: Bitcoin BIPs: BIP 39: Mnemonic code for generating deterministic keys, Bitcoin BIPs: BIP 32: Hierarchical deterministic wallets (extended keys).

4. Write the backups down, never digitally

   Write each recovery phrase on paper or a metal backup. Never photograph it, type it into a computer or phone, or store it in a cloud service. Each backup goes to its own secure location, separate from its device.

   Source: NIST: SP 800-57 Part 1 Rev. 5: Recommendation for key management, NCSC: Small organisations guide to cyber security.

5. Build the 2 of 3 wallet from public keys

   Coordinating wallet software on a computer combines the three extended public keys into a 2 of 3 wallet. Public keys can show balances and create receiving addresses, but cannot move funds. The software produces a wallet descriptor: a short text that records all three public keys and the 2 of 3 rule.

   Source: Bitcoin BIPs: BIP 32: Hierarchical deterministic wallets (extended keys), Bitcoin BIPs: BIP 380: Output script descriptors, general operation (wallet backups and exports), Bitcoin BIPs: BIP 11: M of N standard transactions (multisig).

6. Back up the descriptor separately

   Keep copies of the descriptor with each key backup or in the company records. It is not secret in the way a recovery phrase is, because it cannot move funds, but it reveals the wallet's balances and history, so store it with care. Without it, rebuilding a multisig wallet from the phrases alone can be very hard.

   Source: Bitcoin BIPs: BIP 380: Output script descriptors, general operation (wallet backups and exports).

7. Check a receiving address on every device

   Before any funds arrive, show the first receiving address on each signing device and confirm it matches the one on the computer screen. This checks that all three devices agree on the same wallet.

   Source: Bitcoin developer documentation: Wallets guide: signing-only wallets and hardware wallets.

8. Test with a small amount

   Send a small amount in. Then prepare a payment out, sign it with two of the three devices, check the amount and destination on each device screen, and broadcast it. Partially signed transactions (PSBT) let each signer add a signature in turn.

   Source: Bitcoin BIPs: BIP 174: Partially Signed Bitcoin Transaction format (PSBT), Bitcoin BIPs: BIP 11: M of N standard transactions (multisig).

9. Test recovery before the real transfer

   Wipe or set aside one device, restore its key onto a spare device from the written backup, rebuild the wallet from the descriptor, and confirm it shows the same addresses. Then record the test date.

   Source: Bitcoin BIPs: BIP 39: Mnemonic code for generating deterministic keys, Bitcoin BIPs: BIP 380: Output script descriptors, general operation (wallet backups and exports).

10. Record it in the key register and minutes

    Record each key by role, its device, the location of its backup, the date of the last test and who was present. Never write recovery words in the register. Repeat the recovery test at least once a year and after any change of signer.

    Source: NIST: SP 800-57 Part 1 Rev. 5: Recommendation for key management.

Where the keys end up affects the keyholders too: never two keys in one place, and no recovery words when travelling. See keyholder safety and privacy.

Where to go next

• A 2 of 3 multisig: what happens when a key is lost or stolen
• Keyholder continuity, with a handover template
• Steel backups for a 2 of 3 multisig: plates, the descriptor and where each lives
• Practices that apply to every custody model
• Glossary: recovery phrase, extended public key, descriptor, PSBT

Sources

Primary sources only. Each link was checked on 29 October 2026. Rules change, so confirm the current version with your adviser.

1. Bitcoin BIPsBIP 11: M of N standard transactions (multisig)
2. Bitcoin BIPsBIP 32: Hierarchical deterministic wallets (extended keys)
3. Bitcoin BIPsBIP 39: Mnemonic code for generating deterministic keys
4. Bitcoin BIPsBIP 174: Partially Signed Bitcoin Transaction format (PSBT)
5. Bitcoin BIPsBIP 380: Output script descriptors, general operation (wallet backups and exports)
6. Bitcoin developer documentationWallets guide: signing-only wallets and hardware wallets
7. NISTSP 800-57 Part 1 Rev. 5: Recommendation for key management
8. NCSCSmall organisations guide to cyber security
9. CoinkiteCOLDCARD security advisory: weakened seed generation in affected firmware (July 2026)