The Bitcoin Cash Layla upgrade activated on May 15, 2026. If you hold BCH in an ordinary wallet, the upgrade did not require you to move your coins. If you run a node or a service that handles BCH, the useful question now is whether every part of that service works with the new rules.
This guide covers both situations. Protocol details follow the final upgrade specification; software release details were checked on September 8, 2026.
Holders and ordinary wallet users
Your existing BCH and ordinary receive addresses remained valid. Layla required no coin swap, replacement asset, seed migration, or payment to an "upgrade address." A message asking for one of these to complete the upgrade is a scam.
For everyday use, a few familiar checks are enough:
- Use a maintained wallet and follow its official update guidance.
- After changing wallet software or its backend, test receiving and sending with a small amount.
- Check support for the features you actually use, especially hardware signing and CashTokens.
- Keep your recovery backup complete and private.
Support for ordinary BCH payments does not imply support for every new contract type. Check that separately before funding an unfamiliar contract.
Node operators
Bitcoin Cash Node v29.0.0 included Layla support. As of September 8, BCHN v29.1.0 is the latest release, and its maintainers recommend upgrading from older versions. If you use another implementation, follow that project's release and support guidance.
A version check is the starting point. Confirm that the node is following the expected chain and serving its dependent applications correctly:
- Verify the binary using the project's published verification procedure.
- Compare a recent block's height and hash with independently operated, compatible nodes. Check that the tip keeps advancing and peers remain connected.
- Review validation warnings, including activation-era logs if the node was running then.
- Test the RPC calls, indexes, ZMQ notifications, pruning, and wallet functions your services depend on.
- Check disk, memory, and bandwidth use, then confirm the node recovers after a planned restart.
- Test alerts for a stale tip, lost peers, and unexpected reorganizations.
Back up configuration and wallet data using the implementation's documented procedure. Copying a live chain-state directory may produce an inconsistent backup. A node that never adopted the active rules is also an unreliable source for deposits, withdrawals, or mining.
Miners and pools
Every node used to validate blocks or generate templates needs to support the active rules. Check backup nodes too: an outdated failover can turn a routine outage into rejected blocks.
Exercise template generation, payout construction, monitoring, and failover together. A mixed fleet may appear healthy until it encounters a transaction that uses a new operation.
Exchanges and custodians
Follow a small deposit through crediting, then a withdrawal through signing and confirmation. That checks more than a green node-status indicator can tell you.
Along the way, confirm that:
- Deposits and withdrawals are tracked on the intended BCH chain.
- Each signing system supports the transactions it is asked to authorize.
- Indexers handle P2S outputs and the larger token commitments permitted by Layla.
- Confirmation policies account for transaction value and reorganization risk.
- Reconciliation catches previously credited transactions removed by a reorganization.
Incident messages should say which service is affected and whether funds can still be received, credited, or withdrawn. Software compatibility alone cannot establish that custody and accounting are sound.
Wallets and payment processors
Test the full payment flow: receiving, sending, fee estimation, change, payment URIs, and recovery. Include hardware signing, multisignature, and CashTokens where your product supports them.
Pay to Script (P2S) lets applications use direct script outputs under standard relay policy; it does not introduce a general-purpose P2S receive-address format. Supporting these contracts requires transaction-building and signing support. Before asking a user to approve one, show the destinations, amounts, token changes, and relevant spending conditions as clearly as possible.
Explorers and indexers
Check your software's migration notes before reindexing. After an upgrade or migration, compare block hashes with independent nodes and inspect both the raw and decoded forms of transactions using Layla features.
Pay particular attention to script fields, token commitments, API pagination, and numeric precision. Restart tests should confirm that WebSocket or ZMQ consumers reconnect and recover missed events. Missing token metadata should leave a usable category ID, rather than making a valid transaction disappear from the interface.
Keep enough raw data to reproduce a decode when the explorer and a wallet disagree.
Contract and library developers
Use the final CHIP specifications and their test vectors to check both valid transactions and cases that must fail. Focus on:
- Loop termination, function calls, and stack limits.
- Bit inversion and shifts on empty inputs, negative numbers where applicable, and boundary-sized values.
- P2S construction, token commitment lengths, and unlocking-bytecode limits.
- Fees and resource use for larger scripts or proofs.
Distinguish consensus checks from relay policy in your tests. For example, the P2S CHIP raises the consensus limit for NFT commitments from 40 to 128 bytes, while the higher standard unlocking-bytecode limit is a policy change. A transaction can satisfy consensus rules and still be rejected by a node's mempool policy.
Keep dependency versions reproducible, and review CashScript, Libauth, node, and indexer migration notes before updating them.
If systems disagree
If you suspect a validation or chain disagreement, pause the affected automated crediting, withdrawals, or block production. Record the node version, chain tip, peers, raw transaction or block, and exact error before changing anything.
Compare the evidence with an independently operated compatible node and the final specification. Preserve the original state before attempting a repair; deleting it can erase the clues needed to understand what happened.
The goal is a service you can verify and recover: one that follows the expected chain, handles the transactions it supports, and makes failures visible before they affect more users.