Fork and migration handling: stages and deadlines
A chain fork or a token migration forces three actions. Record the pre-event position. Pick a side or a standard. Complete the swap before the operator's cut-off. Miss that cut-off and the claim to the new asset weakens or disappears. The steps below set out the order, the documents, and the point after which nothing can be reversed.
"Fork" here means a protocol-level split that creates two competing chains. "Migration" means a planned move to a new contract, token standard, or ledger. Both create the same practical problem: the asset a rights holder held a claim against no longer sits where it did.
This page assumes the underlying right is already established. It moves straight to the mechanics of the fork or the migration. The wider position on which claims we take on, and which we decline, sits in What we do not do, and why the line.
What changes once a fork or migration is announced
The window is fixed by the node operator, the custodian, or the exchange. It is not fixed by the rights holder. Once the snapshot block or migration date is published, three things happen at once. The old contract enters legacy status. A claim window opens. Any pledge or lien on the original token needs a matching entry against the new one.
A late claim risks landing outside the migration ledger. At that point, recovery depends on the counterparty's goodwill, not on a scheduled process. No forum reopens a closed window as a matter of course.
Metadata that ties a token to its off-chain right does not migrate on its own. If the pointer is not rebuilt against the new contract, the on-chain object and the underlying right can drift apart, even where the claim itself was filed correctly and on time.
If the migrating token is a stablecoin whose peg is already in question, the clock above does not automatically apply. That is a separate decision path. See A stablecoin peg is challenged token issuance who decides for how that scenario is decided.
What to do
- Freeze internal records. The compliance officer logs the snapshot block or migration date as soon as it is published.
- Confirm holding proof. The custodian exports a signed balance statement dated to the snapshot block.
- Choose the claimed asset. The rights holder instructs in writing which fork branch, or which new contract standard, it claims.
- Re-register encumbrances. Whoever holds the original pledge or lien re-enters it against the new asset before the window closes.
- Submit the claim before the cut-off. The custodian or the exchange support desk must receive the instruction inside the published window.
- Archive the trail. Legal or compliance keeps timestamps, correspondence, and confirmations for as long as the underlying claim can still be challenged.
Who decides, and by when
No single forum runs every fork or migration. Each actor below controls one stage only, and none of them answers for the others. The table lists the actors who typically hold each decision, and the deadline pattern each one usually sets.
| Stage | Who decides | Typical deadline pattern |
|---|---|---|
| Snapshot or fork block | Node operator or protocol foundation | Announced ahead of the event, days to weeks out |
| Claim window | Custodian or exchange support desk | Set once the event has occurred |
| Encumbrance re-registration | Holder of the original pledge or lien | Before the claim window closes |
| Point of no return | Node operator or contract deployer | When the legacy contract is frozen or the old chain is deprecated |
None of these deadlines are court deadlines. They are operational cut-offs set by whoever runs the infrastructure. They are not extended for a late filing, and there is usually no appeal to a second body once the window is shut.
Common branches
- If the custodian does not support the new standard, move the asset to one that does. Do this before the window closes, not after.
- If the pledge was registered against the old contract only, notify the secured party in writing. Re-register against the new asset in parallel.
- If the fork produces two competing chains and no side has a clear majority yet, keep the claim on the chain you already hold. Do not wait for consensus to file.
- If the migration changes the token standard rather than the chain, check whether the pledge register accepts the new standard before re-registering. Some registers need a fresh filing, not an amendment.
- If the counterparty does not respond to the claim, escalate through the operator's dispute desk. Keep a dated record of every attempt.
Limits of this page
This page does not decide who holds the underlying right before the fork happens. Where a right is about to be pledged, and that question is still open, Asset report before a right is pledged sets out that decision point.
Where the counterparty is a debtor, and the claim is being sold rather than migrated, Debtor report before selling the claim covers that separate question.
Checked
Checked: on the date this page was published. Basis: node client release notes, custodian and exchange operational bulletins, and internal fork-tracking logs. No statute or court decision is cited on this page. The mechanics above follow published operator procedure, not a legal deadline, and they change whenever an operator changes its own bulletin.
For the metadata side of the same migration, see Metadata verification: stages and deadlines.
FAQ
How long does fork and migration handling take in practice?
The claim window itself is set by the node operator or the custodian. It commonly runs for several weeks. Internal steps — freezing records, confirming holding proof, re-registering an encumbrance — can be finished within a day if the underlying records are current. The slowest part is usually waiting for the custodian to confirm the new standard is supported, not the paperwork itself.
Which documents are needed to start?
A dated balance statement from the custodian, the original encumbrance registration if one exists, and a written instruction naming the claimed branch or contract. Correspondence with the operator should be kept alongside them, since the timestamp on that correspondence is often the only proof a claim was filed inside the window.
What happens if the other side does not respond?
A non-response does not extend the deadline. Escalate through the operator's dispute desk, keep every dated attempt on file, and treat the claim window as closing on schedule regardless of the silence. Silence from a counterparty is a common outcome, not an exception, and the process is built to continue without it.