Fork and migration handling: what the decision maker looks at
When a tokenised asset forks or migrates to a new chain, the decision maker checks four things: which ledger holds the authoritative record, whether control passed to the same holder without a gap, what evidence ties the old address to the new one, and whether a cut-off date fixed the position. A missing link stops the file rather than delaying it.
A fork splits one chain into two competing histories, each with its own balances from the split point onward. A migration moves a token's record from one ledger to another, usually as a planned upgrade rather than a dispute. Both events break the simple assumption that a wallet address at time A is the same holding at time B. Where that break cannot be closed with evidence, we say so rather than smoothing it over — see When there is nothing to establish, we say so. This page sets out the sequence the decision maker follows to reach that conclusion, or to close the file with confirmed continuity.
What changes in practice
A fork or migration resets part of the evidence trail. Anything dated before the event now needs a second, independent link to the position after it — the earlier record on its own is no longer enough. Exchanges sometimes credit a new token automatically to holders of the old one; other providers require a manual claim within a set window. Either path can run alongside an airdrop to existing holders, which carries its own separate timing rule — see A token is airdropped to existing users token issuance. Treating a post-fork balance as a plain continuation of the pre-fork one, without checking how the claim actually worked, is the most common error at this stage.
The practical effect is timing. A file that would otherwise close within days can extend by several weeks once a fork or migration sits inside the period under review. The extension is not a formality. It reflects a genuine gap in what the ledger alone can prove, and that gap has to be either closed with evidence or stated openly.
The point of no return
Two moments close the door on a clean continuity check. The first is a claim window that lapses without action: once the deadline set by the exchange or wallet provider passes, the unclaimed position on the new chain may no longer exist, and the analyst has to note that a right existed but was not exercised. The second is consolidation: once a holder moves migrated tokens into a fresh wallet without keeping a record of which balance came from which chain, the trail beyond that point cannot be rebuilt from ledger data alone. Past either point, the file records what happened up to the cut-off and states plainly that nothing further can be established.
What to do
- The instructing party lists every chain the asset has touched, including any fork or planned migration, before the file opens.
- The analyst pulls the ledger state at the exact fork or migration block, not an approximate date around it.
- The analyst requests the claim, swap, or credit record from the exchange or wallet provider that executed the migration.
- The analyst matches the old address to the new one through a documented link — a signed message, a custodian statement, or an on-chain claim transaction.
- Where no such link exists, the analyst records the gap and states precisely what evidence would close it, rather than assuming continuity.
- The reviewing lead signs off the file only once every chain segment carries either a confirmed link or a clearly stated gap.
Who decides
| Stage | Who acts | What they produce |
|---|---|---|
| Chain mapping | Analyst | Full list of chains and fork or migration events the asset passed through |
| Evidence pull | Analyst | Block-level ledger state and claim or swap records |
| Continuity check | Reviewing lead | Confirmed link, or a stated gap, for each chain segment |
| File closure | Reviewing lead | Sign-off, or a return to the analyst for further evidence |
The reviewing lead is the decision maker referred to throughout this page. The lead does not certify continuity on inference alone. A gap in the evidence is recorded as a gap, not bridged with an assumption, and the reasoning behind each sign-off stays in the file.
If your situation is different
If the fork happened before the asset came into the current holder's control, the file treats the pre-fork history as a separate question and notes the exact boundary where the current holding begins. If the migration was voluntary and the holder never claimed the new token, the file records the old holding as unmigrated rather than assuming the swap happened by default. If the other side disputes which chain is authoritative, the file states both positions and the precise point on which they diverge, without the decision maker choosing a winner. If the same asset forked twice in sequence, the file checks continuity across each split separately rather than treating the two events as one.
Sources and limits
This page describes the internal review sequence, not a ruling on which of two ledgers holds the better legal claim — that question sits with the parties and, where it goes that far, with a court. The check here stops at what the chain and the exchange or wallet provider can document. It does not extend into off-chain agreements about which fork the parties intended to follow, and it does not predict how a dispute over the fork would be resolved.
Where the review feeds into a full asset trace rather than a standalone continuity check, the relevant report is Asset in Lithuania. Where the counterparty under review is a debtor rather than an asset holder, the relevant intake is Debtor in Czechia and its limits.
Verified
Reviewed on 2025-01 against the firm's internal case procedure for chain continuity review. No article, regulation or national provision is cited on this page. The sequence above is an operational description of how the file is built, checked against current internal practice rather than against a named source.
Related reading
A related check often runs on the same file in parallel: see Metadata verification: what the decision maker looks at.
FAQ
How long does fork and migration handling take in practice?
A single migration with a clear claim record adds a few days to the file. A contested fork with no claim record on one side can add several weeks, since the analyst has to document the gap rather than close it with a guess.
Which documents are needed to start?
A list of every chain the asset has touched, the wallet or exchange records around each fork or migration, and any claim, swap, or custodian statement covering the change from one chain to the other.
What happens if the other side does not respond?
The file proceeds on the evidence that is available and records the non-response as a gap on that side. Silence is not treated as agreement, and the file says so plainly rather than filling the gap with assumption.