A blockchain split can leave an institution with two technically spendable balances and no settled answer about what belongs in its client records. The operating problem starts before trading. Someone must identify the relevant chain, determine which holdings existed at the split, establish what the custody agreement covers and decide whether the second balance represents an asset the institution can support.

This article considers a persistent split into separately operated networks. A short-lived competing block is a different event. The distinction matters because a temporary reorganisation calls for transaction reconciliation, while a persistent split may require a new asset record and an explicit entitlement decision. Neither should be handled by accepting a ticker that appears in a wallet interface.

A copied ledger is only the starting point

Bitcoin's developer guide explains how nodes resolve competing branches and describes consensus rule changes. That is the technical background for distinguishing a transient fork from a chain that continues under different rules. It does not establish a custodian's distribution obligation. See the Bitcoin block-chain guide for the protocol mechanics.

Consider a hypothetical manager with native coins in self-custody, tokens held through a custodian and a claim against a trading venue. The native balance might exist on each branch. The token contract state might also be copied. The venue claim remains a claim against the venue, subject to its support and contractual arrangements. These are three separate operating questions even if a dashboard originally displayed all three under one portfolio heading.

The first inventory should therefore classify positions by holding form. Record native assets, issuer-backed tokens, wrapped assets, vault shares and contractual claims separately. For each position, retain the pre-split chain identifier, address or account reference, balance source and relevant block hash. Give the provisional new branch its own internal identifier. A copied symbol is too ambiguous for custody instructions.

Issuer support determines whether backing follows

A useful historical example is Circle's announcement of 9 August 2022. Ahead of Ethereum's Merge, Circle stated its intention to support only the proof-of-stake chain for USDC. This was an issuer decision about a specific event, not a general rule for every future fork. The dated Circle Merge statement illustrates why duplicated token state cannot be treated as duplicated redemption backing.

The operational lesson extends beyond stablecoins. Where a token points to an offchain asset or service, a second copy of the contract does not by itself demonstrate a second enforceable claim. The institution should obtain the issuer's event-specific position, identify the supported network and retain the communication used in its decision. Silence is an unresolved dependency, not affirmative support.

This is also why a portfolio team should resist marking every copied balance at the price of the original instrument. A symbol and an integer balance do not establish fungibility. The existing discussion of token identifiers and reference data explains the broader identification problem; a chain split adds a time-bound decision about which branch each identifier describes.

Freeze the snapshot, then test its completeness

A snapshot should be reproducible. Save the network, block height, block hash, extraction time and source for each balance. If the split point is disputed or the service provider uses another cutoff, record the disagreement rather than overwriting the first file. A later reconciliation needs to distinguish a changed fact from a changed interpretation.

For omnibus custody, a chain balance cannot allocate holdings between clients. The allocation also depends on the custodian's subledger. Ask how unsettled deposits, withdrawals, loans, collateral and fees were treated around the snapshot. A transfer initiated before the cutoff but included later may appear on one record and not another. The correct adjustment depends on the agreed booking policy and the transaction evidence.

A practical entitlement file should include:

  • The original holding and the provisional branch-specific balance.
  • The client or portfolio account to which any recognised entitlement would attach.
  • The custody or venue provision used to decide support and distribution.
  • Unsettled transactions and other exceptions at the snapshot.
  • The reviewer, decision date and remaining conditions before release.

Keep the raw snapshot separate from the approved allocation. The first records what the systems observed; the second records what the organisation decided. Combining them makes it difficult to explain why an address with a visible balance did not result in a client distribution.

Replay exposure belongs in the movement plan

Ethereum's EIP-155 replay-protection specification includes a chain identifier in the signing scheme for protected transactions. Its relevance here is conditional: different identifiers and correct signing support help distinguish networks. Reading the proposal alone does not prove that a particular fork, wallet and transaction type provide effective separation.

Before moving assets on either branch, engineering should verify the actual replay behaviour of the proposed signing path. Record the network parameters, client configuration and transaction format. A production operation should not become the test. If a provider says assets have been separated, ask what procedure produced that result and which balances the evidence covers.

Keep the new branch outside routine payment automation until the review is complete. A network with a familiar address format can still require different software and operating assumptions. The approval should cover the RPC endpoint, signer, destination, fee asset and recovery procedure together. Recognising an entitlement does not mean the organisation is ready to execute a transfer.

Supporting custody is a separate business decision

The decision to support the asset should consider whether it can be held, reconciled, transferred and serviced using the institution's controls. A trading quote is insufficient. Operations needs a usable node or provider, reliable balance retrieval, transaction evidence and a way to explain discrepancies. Finance needs an approved valuation and treatment appropriate to the instrument and reporting framework.

Costs can change the distribution proposal. A large number of small client allocations may require engineering, custody setup and transaction fees that are disproportionate to the expected value. That does not resolve ownership. It means the institution should separate its interpretation of entitlement from the mechanics and cost of delivery, then apply the relevant agreement and obtain the necessary specialist review.

For a third-party custodian, request a written event plan. It should identify supported branches, restrictions during the split, the allocation method, treatment of assets received late and the route for corrections. The questions belong alongside the wider distinctions in institutional custody. Access to a private key and the provision of an administered client service are different capabilities.

Run a fictional split through the entire ledger

Suppose a fund holds 100 native units through an omnibus custodian. Its internal books allocate 60 to one portfolio and 40 to another. A five-unit withdrawal is approved before the split but not yet included. The exercise should require the team to determine which authoritative records show the withdrawal, whether its booking affects either client's entitlement and how a later inclusion changes the exception file.

Add an issuer-backed token and a vault position to the exercise. Require separate answers about branch support and the underlying claim. If the team uses a single percentage allocation for everything, it has probably skipped the instrument review. The purpose is to expose where the process assumes that a copied ledger preserves the entire economic relationship.

The exercise should end with two deliverables: a signed entitlement decision and an executable custody plan. They may have different dates. That is acceptable when the second remains blocked by unsupported infrastructure or unresolved issuer information. The status should make the distinction visible to client service and portfolio management.

A decision register should include assets the institution elects not to support, with the basis recorded. Rejected support should not erase the original observation or imply that the entitlement question was resolved by software compatibility. Keeping both decisions visible gives the institution a usable record if infrastructure, liquidity or issuer information changes later.

The closeout is an explanation, not just a balance

After the decision, reconcile allocated quantities to the snapshot, movements and residual holdings. Any rounding, fees, unclaimed allocations or retained amounts should have an owner and an explanation. Keep unsupported balances visible in the exception register rather than hiding them because they do not fit the production asset catalogue.

Client communication should distinguish observation, recognition and delivery. A balance may have been observed, an entitlement may have been recognised and distribution may still be pending. Those statements should not collapse into a promise that the institution has already received freely transferable value. The records should support whichever statement is used.

The useful control is a documented sequence: identify the branch, preserve the snapshot, verify backing and service support, approve the entitlement, then authorise movement. A fork can happen in software. Its treatment in institutional books requires named decisions and evidence that survives the event.