The Bitcoin Cash network's next consensus upgrade is scheduled for May 15, 2026 at 12:00:00 UTC, activating when the Median Time Past (MTP) of the most recent 11 blocks reaches 1778846400. On chipnet, the upgrade activated six months earlier, giving wallets, nodes, and contract developers a live test environment ahead of mainnet.
This upgrade continues BCH's yearly upgrade cadence and focuses on making the VM more expressive without giving up predictable validation. For everyday users, the change should mostly be invisible. For builders, it expands what can be done with BCH smart contracts and CashTokens while keeping the network's low-fee, on-chain design intact.
Activation at a Glance
| Item | Detail |
|---|---|
| Mainnet activation | May 15, 2026, 12:00:00 UTC |
| Activation method | MTP of the most recent 11 blocks must be >= 1778846400 |
| Chipnet activation | November 16, 2025, 12:00:00 UTC by MTP |
| BCHN release | Bitcoin Cash Node v29.0.0 |
| Focus | More expressive, more efficient, and more practical BCH contract design |
The Four CHIPs in the May 2026 Upgrade
- CHIP-2021-05 Loops: Bounded Looping Operations
- CHIP-2025-05 Functions: Function Definition and Invocation Operations
- CHIP-2024-12 P2S: Pay to Script
- CHIP-2025-05 Bitwise: Re-Enable Bitwise Operations
Loops: Bounded Looping Operations
This CHIP introduces OP_BEGIN and OP_UNTIL, allowing contract authors to express repeated logic without manually duplicating the same bytecode over and over.
Why it matters:
- More powerful and flexible contract logic, such as efficient Merkle proof validation and aggregation tasks.
- Simpler, shorter contracts that are easier to audit and less error-prone.
- No increase in validation risk: strict density-based limits ensure loops cannot be abused for denial-of-service attacks.
Bounded loops are especially important because the 2025 VM limits work laid the foundation for safe, predictable iteration. Together, those changes reduce bytecode bloat and make advanced BCH contracts more practical.
Functions: Function Definition and Invocation Operations
This CHIP adds OP_DEFINE and OP_INVOKE, making it possible to factor reusable logic into functions rather than repeating the same instructions in multiple places.
Why it matters:
- Smaller, more auditable contracts by eliminating duplicated bytecode.
- More advanced contract patterns, including cryptographic protocols, privacy-preserving logic, and complex DeFi primitives.
- Improved privacy and operational security, as contracts can hide internal logic and reduce information leakage.
Functions make BCH contracts feel less like hand-packed script puzzles and more like maintainable programs. That should help developers ship richer applications with fewer workarounds.
P2S: Pay to Script
This CHIP makes Pay to Script outputs standard, raises the token commitment limit to 128 bytes, and aligns the standard unlocking bytecode length limit with the 10,000-byte consensus limit.
Why it matters:
- Safer wallet ecosystem: reduces the risk of users accidentally sending funds to unspendable contracts.
- Simpler and smaller contracts, especially for vaults, covenants, and multi-party applications.
- Larger token commitments and unlocking scripts, supporting more complex token and contract use cases.
P2S is one of the most directly useful changes because it improves contract ergonomics and wallet safety at the same time.
Bitwise: Re-Enable Bitwise Operations
This CHIP re-enables a set of bitwise operations, including OP_INVERT, arithmetic shifts for numbers, and logical shifts for binary data.
Why it matters:
- Efficient implementation of cryptographic protocols, such as signature schemes and zero-knowledge proofs.
- More expressive DeFi and token contracts that require bitwise logic.
- Simpler and more direct contract code for tasks that previously required complex workarounds.
Bitwise support fills in another missing piece for advanced cryptographic applications, including some post-quantum and proof-heavy designs.
What Users Should Expect
- Regular BCH holders: if you use a custodial service or a mainstream self-custody wallet for simple sends and receives, you may not need to do anything beyond keeping your wallet current.
- Businesses, exchanges, processors, and node operators: you should be running upgrade-compatible software ahead of activation.
- Developers: you should test on chipnet, review assumptions around script templates and policy limits, and make sure your tooling understands the new patterns introduced by the upgrade.
For most end users, this is not a "move your coins immediately" event. It is mainly an infrastructure and capability upgrade.
BCHN v29.0.0 and Operational Readiness
The reference BCHN release for this upgrade is v29.0.0. In addition to implementing the four consensus changes, it adds several useful operational improvements:
- A new
upgrade_statusfield ingetblockchaininfo, which can help services track activation status. - A
patternsflag forgetblockandgetrawtransaction, plus matching REST endpoints, which expose script pattern metadata useful for analytics and contract recognition. - A new
coinstatsindexoption for richer UTXO-set statistics. - Network-layer optimizations and a new per-peer bandwidth control option,
-peerratelimit.
These details matter for explorers, analytics tools, and any service that wants better visibility into how BCH contract activity changes after activation.
Why This Upgrade Matters
The May 2026 upgrade is less about headline-grabbing marketing and more about completing important building blocks:
- Smaller contracts through loops and functions
- Safer and more flexible contract interactions through P2S
- Stronger cryptographic expressiveness through bitwise operations
- Better developer ergonomics without moving to an account-based model
That combination should make BCH more attractive for CashTokens, vaults, covenant designs, post-quantum experiments, and other advanced applications that still benefit from low-fee L1 execution.
Summary
Bitcoin Cash's May 2026 upgrade activates on May 15, 2026, with four CHIP changes that improve contract expressiveness, efficiency, and safety. For most users, the upgrade should be mostly invisible. For node operators, wallets, exchanges, and builders, it is a meaningful infrastructure event that expands what BCH applications can do and how efficiently they can do it.
For a practical checklist, see our companion guide: BCH May 2026 Upgrade Readiness Guide.
