A crypto fork is a divergence in a network’s rules that leaves two chains where there was one. Holders often receive a balance on both, but the second balance is a claim on a different ledger with different liquidity, different infrastructure and a different set of people willing to buy it.
What a crypto fork actually delivers depends far less on the fork itself than on where your keys sat at the snapshot height. That single detail determines whether you receive anything, when, and at what cost.
Key takeaways
- A hard fork creates a second chain with its own ledger; a soft fork does not, and holders receive nothing extra.
- Receiving a forked balance requires control of the keys at the snapshot block, or a venue that explicitly supports the new chain.
- Unit counts are not value. A 1:10 redistribution gives ten times the units at roughly one tenth each.
- Claiming usually costs fees and a key-handling decision, and those costs are frequently larger than the credited balance.
What a crypto fork changes
A fork changes consensus rules, and only some rule changes split the network.
Soft forks
A soft fork tightens the rules in a way that upgraded nodes accept and old nodes still consider valid. Because everyone remains on one chain, there is no second ledger and nothing extra to claim. Most routine protocol upgrades fall into this category, which is why announcements about “a fork” do not automatically imply a distribution.
Hard forks
A hard fork relaxes or changes rules so that upgraded and unupgraded nodes reject each other’s blocks. If a meaningful group keeps running the old software, two chains persist. Both share the entire history up to the split, which is why every address that held a balance at that height holds the same balance on both ledgers — the same key controls both.
What you receive from a crypto fork
You receive a balance on a second ledger — the visible output of any crypto fork — denominated in a new unit, with no guarantee that anyone will trade it.
Snapshot balances
The split is defined by a block height. Whatever the ledger recorded for your address at that height is what the new chain carries forward. Balances moved after the snapshot do not appear on the new chain, and balances held on a venue at that moment depend on whether the venue itself held the keys and chose to honour the new chain.
Ratios
Some forks redistribute supply rather than copy it. A 1:1 fork credits the same number of units. A 1:10 fork multiplies supply by ten and credits ten units for each one held, with each unit representing one tenth of the previous claim. In both cases the underlying claim is unchanged; only the unit count differs. A headline number that looks ten times larger is exactly that — a number, not a gain.
The arithmetic of a forked position
Work the numbers before the split, because afterwards you will be making decisions under time pressure.
Suppose you hold 2.5 units in self-custody at the snapshot height, with keys you control. The new chain credits 2.5 units at 1:1. If the forked asset trades at 3% of the original’s value, the credit is worth 2.5 × 0.03 = 0.075 units of the original — a little under 3% of the position.
Now price the exit. Selling requires moving the asset to a venue: a network fee equivalent to about 0.0004 units, a trading fee near 0.20%, and slippage on a thin book. Assume 3% slippage. Gross 0.075, less 3.2% in fees and slippage leaves 0.0726, less the 0.0004 transfer cost leaves roughly 0.0722. The realised amount is a bit over 2.8% of the original position, and that is the optimistic case where a buyer exists.
Change one assumption. If the forked asset trades at 0.8% of the original’s value, the credit is 2.5 × 0.008 = 0.02 units, and the same costs leave about 0.0190 — under 1% of the position. The fixed transfer cost now accounts for 2% of the credit on its own. This is the ordinary shape of fork outcomes: a real balance, a real but small value, and a cost structure that eats a meaningful share of anything small.
The unit-count trap follows the same logic. If the fork runs 1:10, your 2.5 units become 25 units. Selling 25 units at one tenth of the price yields the same 0.075 units of value. Nothing changed except the arithmetic you have to do in your head, which is precisely why unit counts get quoted in announcements.
A fork gives you a claim on a second ledger. Whether that claim is worth exercising is a separate question from whether you received it, and the two questions have different answers more often than not.
Custody determines whether you receive anything
The snapshot is a ledger event; delivery is an operational one, and that gap accounts for most of the disappointment. Venues decide, per fork, whether to support the new chain, and that decision is usually published before the split.
| Where the balance sits | Snapshot recorded | Do you receive the forked asset | Main risk |
|---|---|---|---|
| Self-custody, keys you control | Yes, on-chain | Yes, if you can access the new chain’s software | Key handling and replay protection |
| Exchange account | Only if the venue supports the fork | Depends entirely on published policy | Silent non-credit, or a short claim window |
| Pooled or staked position | Recorded at the operator level | Sometimes, per the operator’s terms | Terms may assign the forked asset to the operator |
| Wrapped or bridged representation | Not on the underlying ledger | Usually not directly | Issuer decides whether to pass anything on |
Self-custody is not automatically better. A private key that controls both chains must be handled carefully, and some forks lack replay protection, meaning a transaction broadcast on one chain can be valid on the other. Using software and venues that explicitly handle the split is safer than improvising with a key you rely on.
Where a venue does support the fork, the practical constraints are familiar: a credit date, a minimum balance threshold, and sometimes a deadline after which unclaimed balances are written off. Those terms are usually shorter than people expect.
0 comments
No comments yet — ask a question and we will answer it here.