Bitcoin Cash began as a separate consensus network on August 1, 2017. Since then, BCH has used coordinated hard-fork upgrades to change block-capacity policy, difficulty adjustment, transaction rules, and its scripting virtual machine.
This timeline summarizes the major changes. The Upgrade Tracker provides activation details and primary references for each entry.
2017: a separate chain and a new difficulty algorithm
The August 2017 split introduced replay-protected transaction signing and a larger block-size limit. An emergency difficulty rule helped the new chain continue producing blocks despite rapidly changing hash rate, but it also contributed to irregular timing.
The November 2017 upgrade replaced that temporary mechanism with a per-block difficulty adjustment algorithm and tightened signature-validation rules.
2018: capacity and script capability
The May 2018 upgrade raised the block-size limit to 32 MB and re-enabled several script operations. In November, canonical transaction ordering and OP_CHECKDATASIG expanded how transactions could be organized and how contracts could verify signatures over external data.
These changes established two recurring directions: more base-layer capacity and a more capable Bitcoin-style virtual machine.
2019: Schnorr signatures
The May 2019 upgrade activated Schnorr signatures for supported script paths and added a recovery path for certain coins accidentally sent to SegWit-style outputs. November extended Schnorr support to multisignature workflows and enforced minimal data encoding.
Schnorr support created smaller signatures and new construction options, but it did not automatically aggregate every multisignature or make transactions private.
2020: validation accounting and ASERT
The May 2020 upgrade replaced legacy signature-operation accounting with SigChecks, added OP_REVERSEBYTES, and adjusted mempool chain policy.
In November, BCH activated ASERT, a difficulty algorithm designed to respond smoothly to changes in available hash rate around the ten-minute target. That upgrade also coincided with a chain split involving Bitcoin Cash ABC; subsequent BCH history follows the rules adopted by the BCH network described here.
2021: fewer standardness limits
The Tachyon upgrade removed the default limit on chains of unconfirmed transactions and allowed multiple OP_RETURN outputs under standard relay policy. These were practical policy and transaction-construction changes rather than a new monetary or consensus model.
2022: native transaction introspection
Native introspection operations allowed BCH scripts to inspect transaction inputs, outputs, values, and bytecode directly. Larger script integers accompanied the change.
This made covenants and other UTXO contracts more practical because scripts no longer needed the same bulky workarounds to reason about the transaction spending them.
2023: CashTokens and P2SH32
The May 2023 upgrade activated CashTokens, native fungible-token and NFT primitives carried by BCH outputs. It also introduced P2SH32, restricted transaction version numbers, and allowed smaller transactions under the upgraded rules.
CashTokens defines protocol validation. Human-readable names and icons are a separate metadata problem commonly addressed through BCMR.
2024: adaptive block capacity
The Adaptive Blocksize Limit Algorithm, or ABLA, replaced the fixed 32 MB consensus limit with an algorithm that can change according to sustained block usage. Growth is bounded and gradual; it is not an unlimited block or a promise that node resources will always be sufficient.
2025: BigInt and targeted VM limits
The May 2025 upgrade enabled high-precision script integers and replaced several blunt virtual-machine ceilings with resource-specific limits. Stack items could grow larger, and script validation cost became more closely tied to the resources an operation uses.
The change expanded the contract design space while preserving explicit consensus bounds.
2026: Layla
On May 15, 2026, the Layla upgrade activated four proposals:
- bounded loops;
- reusable functions through OP_DEFINE and OP_INVOKE;
- Pay to Script standardness and larger standard transaction components;
- bitwise operations.
These features reduce bytecode duplication and make some algorithms easier to express in CashVM. They do not turn BCH into an account-based virtual machine or guarantee that a contract is safe.
How to interpret the timeline
A network upgrade is evidence that participants coordinated around new rules. It is not, by itself, evidence of adoption, decentralization, security, or economic value.
For each change, ask what became valid, which software implemented it, what new costs or risks appeared, and whether wallets and applications actually use it. The protocol timeline is the foundation; ecosystem results are a separate measurement.