Forks create opportunity and confusion. I’ve handled a few forks in long-term cold-storage setups, and what I’ve found is that the steps are predictable — when you follow safe practices. This guide explains, in plain terms, how to approach legacy coins like Bitcoin Cash (BCH) or Bitcoin Gold (BTG) that split from Bitcoin, how your hardware wallet fits into the picture, and safe, step-by-step ways to claim (or decline) forked funds.
Short version: don’t impulsively expose your seed phrase. Read the checklist. Then act.
A fork happens when a blockchain changes rules and creates a split. Sometimes the result is two independent chains that both recognize the same history up to the split. That means balances at the time of the split can appear on both chains. Hard forks create new, separate tokens. Soft forks usually keep a single chain.
Why should you care? Because if you held bitcoin at the moment of a hard fork, you may technically control coins on both resulting chains — but claiming the new chain’s tokens can be tricky and may expose your private keys if done poorly.
Hardware wallets protect private keys inside a secure element and require on-device confirmation for transactions. But not every hardware companion app or third-party wallet supports every forked chain or the address type (legacy, nested segwit, native segwit) you used in 2017. That affects whether you can sign fork-chain transactions safely without exporting sensitive information.
In my experience, supported apps and firmware make claims straightforward. When support is missing, you need extra steps (and more caution).
Key concepts:
Air-gapped signing preserves the private keys inside the hardware wallet while letting a third-party app build and the device sign transactions. That’s the safest route when available.
This is the safe, conservative workflow I use. Follow each step and pause before you reveal a seed.
Step 1 — Inventory: Identify whether you actually control forked coins. Use a block explorer for the fork chain and paste the same public addresses you used on the original chain. (If you don’t know the address, find it in your hardware wallet companion app.)
Step 2 — Check support: Does your hardware wallet or a trusted third-party wallet support the fork and the address type you used? See supported coins & compatibility and Electrum integration or similar pages.
Step 3 — Prefer hardware-backed claiming: If a compatible external wallet can talk to your hardware wallet and the third-party app supports the fork, use that combination. The hardware wallet signs; the app broadcasts. No seed export. Safe.
Step 4 — If no hardware support, avoid importing your seed into an online wallet. Instead, create a cold, air-gapped environment (hardware or offline VM), restore only on that isolated machine, construct an unsigned transaction, sign it offline (if possible), then broadcast via a networked machine (or a public RPC) — but only after you understand replay protection risks.
Step 5 — After claiming: Move the original chain coins (and newly claimed coins) to fresh addresses if the fork lacked replay protection. That prevents accidental replay of transactions between chains.
Step 6 — Record everything for taxes and future reference.
(And yes, I prefer to skip claiming small forks unless they’re worth the operational risk.)
These are simplified, real-world patterns — not step-by-step instructions for any single app.
Example A — Claiming Bitcoin Cash (BCH)
Example B — Claiming Bitcoin Gold (BTG)
BTG historically used different address formats and tools. The safe pattern is the same as above: prefer device-backed signing via a compatible app. If not available, use an air-gapped restore and sweep the BTG to a new address. Don’t type your seed into a website.
For both examples, see sweep & recover software wallets for deeper guidance.
If funds are held in a multisig (multisignature) setup, claiming forked coins requires cooperation from the cosigners and compatible multisig software for the fork chain. Multisig cosigners may need to agree to sign fork-chain transactions. That process is more complicated (and often safer) than single-sig claims. See multisig setup for configuration reminders.
Troubleshooting quick fixes: follow the flowchart in /troubleshooting-flowchart and consult /error-codes-index if you hit device errors while attempting a signed transaction.
| Option | Device-backed signing | Requires seed exposure | Ease for forks | Good when |
|---|---|---|---|---|
| Hardware wallet + supported app | Yes | No | Easy | Companion app supports chain |
| Hardware wallet + third-party app | Yes (if supported) | No | Moderate | Compatibility confirmed |
| Air-gapped restore to software wallet | No (software signs) | Yes (seed restored) | Difficult | No direct device support |
| Software-only sweep | No | Yes | Risky | Last resort for small claims |
Forks and legacy coins are manageable if you plan and protect your seed phrase. In my experience, the safest approach is to use device-backed signing or an air-gapped workflow rather than exposing your seed to an online wallet. Ask yourself: is the value worth the operational risk? If not, you can leave the forked tokens where they are.
If you want a practical next step, start with a compatibility check at /supported-coins-compatibility, then review /sweep-recover-software-wallets for step-by-step sweeps. For help with seed safety, see /seed-phrase-management and /passphrase-25th-word.
If you ran into a device-specific error while attempting a claim, consult /firmware-updates-bootloader and /troubleshooting-index.
Need a guided checklist before you start? Head to /setup-guide and follow the "How to" steps for a clean, safe claiming session. Good luck — and act deliberately.