Imagine a trader sends 25 USDC just before an exchange switches networks. The deposit exists on the old chain. Its receipt reaches the exchange after the migration snapshot. On Monday, the trader sees a new account balance and asks whether the 25 USDC made it across.
That question needs a precise answer. The team must know whether the deposit was already included in the opening balance, whether it needs a separate credit and when the trader can withdraw it.
A migration has more than one opening time
Bullbit announced its move from Base to BullChain on November 5. Its cutover plan described a trading pause, account and balance migration, and separate reopening times for trading and the bridge. The timing illustrates a useful design choice. Opening an order book and reopening transfers can have different prerequisites. Bullbit’s migration plan
The lab below uses an invented exchange and invented receipts. It models a risk any team moving balances needs to test.
Record the cutover boundary
Define the last source block or ledger cursor covered by the opening snapshot. Record the block hash or equivalent checkpoint alongside the migration batch. A reconciler should be able to point to the source record and show exactly how it ended up in the destination ledger.
In the lab, an account has an opening balance of 100 units. One 25-unit deposit is excluded from that snapshot because it was unresolved. Later, a matching receipt arrives. The destination still shows 100 until the receipt is checked and applied. Another copy of the same receipt leaves the total at 125.
For token transfers, a transaction hash by itself may identify several events. Choose a key that can distinguish them, such as the chain, transaction hash and log index. Then verify finality, token contract, recipient and amount under the route’s policy. A receipt that changes one of those fields belongs in review.
Put the reopen decision in the runbook
Use separate checks for crediting a deposit and enabling withdrawals. Teams can keep the destination available for balance inspection while withdrawal remains disabled. A production runbook needs an owner for the checkpoint, a way to compare the ledger totals and explicit rules for reorgs, interrupted imports and discrepancies.
Show the operator the source checkpoint, expected and observed amounts and every exception. Customers need a simpler view that shows the old balance, the carried balance and any deposit still being checked.
Try Migration Cutover Lab
Freeze the source, import the opening balance and deliver a late receipt. Try reopening withdrawals while the receipt is unresolved. Then apply the receipt, replay it and reconcile the ledger. This is a single-account simulation with one in-flight deposit and no live chain or custody.
What dOrg would build first. Start with one asset and one route. We can scope a checkpointed import, an exception view and acceptance tests for late, duplicate and mismatched receipts. Bring the source ledger, destination ledger and your proposed cutover window.