> For the complete documentation index, see [llms.txt](https://crosschain-docs.gitbook.io/crosschain-docs-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://crosschain-docs.gitbook.io/crosschain-docs-docs/consensus-rule-changes-for-supported-chains-explained.md).

# Consensus Rule Changes for Supported Chains Explained

A consensus rule change alters how a blockchain decides which blocks or transactions are valid. For a service that watches that chain, the key question is whether its software can follow the same rules at the right time.

That matters when deposits or withdrawals depend on the chain staying on one agreed history. If a transfer also raises questions about custody and costs, [how Chainflip handles business transfers](https://paragraph.com/@ai-defi-news/chainflip-for-business-transfers-assets-costs-and-custody) addresses that separate decision.

### What changes for a service that watches a chain?

* **Soft fork:** new rules tighten what counts as valid.
* **Hard fork:** old and new software may disagree on valid blocks.
* **Finality:** the point at which a block is treated as settled varies by chain.
* **Service response:** operators can upgrade, pause, or stop supporting the chain.

A soft fork can let older software keep following the chain, but it may not understand new features. A hard fork can split participants who run different software. Bitcoin Core’s guidance explains the compatibility difference; the label alone does not tell you how much disruption an application will face.

Services often wait for a chain-specific number of confirmations before treating a deposit as settled. A reorganisation—a change to the chain’s recent history—can still replace blocks before that point. After a rule change, the service must check that its node and its definition of “settled” match the upgraded chain.

For Chainflip, validators watch supported chains and report relevant deposits to its own State Chain, where the protocol records activity. Its documentation describes a confirmation window before deposits count as final. A chain upgrade can therefore affect which events validators see as valid and when they report them.

### Which response fits the upgrade?

The choice depends on the change and the cost of being wrong. Upgrading lets service continue, but requires testing and coordinated timing. Pausing deposits or withdrawals reduces exposure while operators check the new chain. Dropping support avoids ongoing maintenance, but users need another route.

Consider a service accepting deposits on Ethereum during a planned consensus upgrade. Its operators first identify the activation point and install compatible node software. They test deposits and withdrawals on a test network, then compare block hashes and finality reports across independent nodes. If those checks disagree near activation, they pause affected transfers until the chain settles.

That pause has a cost: users wait, and queued transactions may need to be retried. But continuing with a node that follows a different branch could credit a deposit that the upgraded chain later removes. Ethereum.org’s account of The Merge shows why upgrades can also change how blocks are produced and finalized, not only transaction rules.

When comparing services, ask who monitors upgrade notices, how they test new rules, and what triggers a pause. For Chainflip, also check whether the asset is still supported and whether deposits or withdrawals are temporarily restricted. I would favour a service with a clear pause and restart process over one that promises uninterrupted access.

### Two questions to ask before choosing

#### How long can transfers be paused?

There is no standard pause length. A planned, well-tested change may require only a short window around activation; a disputed fork or delayed software release can take longer. Ask whether the service gives an estimate, what evidence it needs before resuming, and how it handles transfers sent during the pause.

#### What should I check before sending funds?

Check the service’s status notice, the exact network selected, and whether deposits and withdrawals are both open. After an upgrade, verify that the service recognises the asset and address format you plan to use. If a transfer is urgent, choose a route whose upgrade policy and pause status are clear before sending.
