Bitcoin Cash activated the "Layla" network upgrade on May 15, 2026, when Median Time Past reached the specified activation time. The upgrade bundled four CashVM and standardness proposals.
The network upgrade specification is the primary reference. This article explains the practical effect without treating every possible application as a delivered product.
What changed for you?
| Role | Practical effect |
|---|---|
| BCH wallet user | Ordinary funds did not need to move for activation. New contract features depend on wallet and application support. |
| Node operator, miner, exchange, or indexer | Validation software needed the new rules. Continue following supported releases from your implementation. |
| Contract builder | Loops and reusable functions can reduce repeated code; P2S and bitwise operations expand the available designs within resource limits. |
Layla changed Bitcoin Cash (BCH). It was not an upgrade to Bitcoin (BTC). The Upgrade Tracker keeps the two networks' timelines separate and links each change to its sources. For examples of what builders can do with the activated rules, read Bitcoin Cash after Layla.
Loops
Bounded loops let a script repeat logic without copying the same bytecode for every iteration. The loop operations are constrained by CashVM resource limits, so they provide compact expression rather than unbounded execution.
Loops are useful for algorithms that process a list, repeat hashing steps, or verify a variable number of items. They also create new review obligations: developers must prove the exit condition, maximum work, and behavior at every boundary.
Functions
OP_DEFINE and OP_INVOKE let scripts define and call reusable function bodies. Factoring repeated logic can reduce contract size and make generated bytecode easier to reason about.
Functions do not introduce persistent global state or dynamic package imports. They are a CashVM code-reuse mechanism within the validating script.
Pay to Script
Pay to Script, or P2S, made direct locking scripts standard for relay and mining within the proposal's length limit. The locking program is in the output itself, rather than hidden behind a P2SH script hash. The P2S specification also increases the token-commitment limit and the standard unlocking-bytecode limit.
This can reduce indirection for some larger contracts and post-upgrade constructions. Consensus validity and standard relay policy remain distinct: a transaction can satisfy consensus while still depending on node and miner policy for ordinary propagation.
Bitwise operations
The Bitwise specification enables bit inversion (OP_INVERT), arithmetic shifts (OP_LSHIFTNUM, OP_RSHIFTNUM), and binary shifts (OP_LSHIFTBIN, OP_RSHIFTBIN). These operations let contracts manipulate bits and packed data more directly within the VM resource limits.
The benefit is expressiveness and byte efficiency, not a new cryptographic assumption.
Node and infrastructure status
Bitcoin Cash Node v29.0.0 introduced the activation rules; v29.1.0 is a subsequent maintenance release. Operators should follow their implementation's supported-release guidance rather than treating either version as permanently current.
Wallet users did not need to move ordinary funds solely because of Layla. Exchanges, miners, indexers, and node operators did need compatible validation software before activation.
What Layla does not establish
The upgrade makes some contracts smaller or newly practical. It does not:
- convert BCH to an account-based execution model;
- make contracts safe without testing and review;
- provide trustworthy off-chain data without an oracle design;
- guarantee wallet adoption or application demand;
- remove block, transaction, or VM resource limits.
The useful post-activation question is no longer whether the rules will activate. It is which applications use them, how their risks are documented, and whether independent implementations agree on the resulting transactions.