Bitcoin Cash's Layla upgrade gave contract developers a more practical way to repeat operations, reuse code, and work with binary data. Those changes can make a complicated contract smaller and easier to write. For users, their value depends on the wallets and applications built around them.
Since the May 15, 2026 activation, some of that support has reached released tools; other work remains experimental. This review looks at what developers can use and what readers should look for when judging an application's progress. Sources and release details were checked on September 8, 2026.
What Layla changed
The upgrade specification includes four Cash Improvement Proposals, or CHIPs:
| Change | What became available |
|---|---|
| Loops | Repeat a procedure without writing a separate copy for each repetition, within the VM's resource budget |
| Functions | Define bytecode once and call it from elsewhere in the script |
| Pay to Script | Relay direct script outputs under standard policy, allow larger standard unlocking scripts, and raise the consensus limit on NFT commitments |
| Bitwise operations | Invert bits and shift numbers or byte strings left and right |
AND, OR, and XOR were already available before Layla. The 2026 bitwise changes extend that toolkit with inversion and arithmetic and binary shifts.
Together, these changes build on the 2025 BigInt and VM-limit upgrade. A contract can, for example, use a loop to total the value of its inputs instead of carrying a separate copy of the same procedure for each input. Execution still has to fit within the transaction and VM limits.
Bitcoin Cash Node v29.0.0 included activation support. BCHN v29.1.0, the latest release at this review, adds maintenance and performance improvements.
CashScript brings the changes into reach
CashScript lets developers write BCH contracts in a higher-level language and build spending transactions with a TypeScript SDK. Stable version 0.13.2 supports loops, the new bitwise operators, and P2S contracts. It also includes helpers for fees and change, with local evaluation targeting the 2026 VM. See the release notes for the exact changes.
One distinction is easy to miss. CashScript's public contract functions select a spending path, such as a payment or refund. Layla's OP_DEFINE and OP_INVOKE let a script define and call reusable bytecode internally. CashScript adds user-defined reusable functions in its 0.14 prereleases, which are still separate from the stable release at this review.
The CashScript documentation explains the development workflow. Lower-level tools such as Libauth, Bitauth IDE, and CashAssembly also let developers inspect transaction execution or work directly with bytecode.
Other tools are exploring different approaches
AlbaDsl and AlbaVm take a Haskell-based approach to writing and testing contracts. AlbaDsl uses Haskell's type system to check how a program uses the stack. AlbaVm evaluates BCH bytecode, including the 2026 instruction set.
The project's v0.0.2 announcement reports that AlbaVm passes Libauth's 2026 tests, alongside additional property tests. It also describes the tools and example contracts as experimental. That is useful progress in testing another implementation, with more validation still needed before relying on its examples for production funds.
Quantumroot explores an opt-in post-quantum vault
Quantumroot is a vault design that combines LM-OTS hash-based signatures with CashTokens and CashVM. The original July 2025 developer preview described the necessary components as possible under the 2025 rules and used the proposed Layla features to reduce transaction sizes and simplify the code.
That preview also said its initial wallet template had not yet received independent review. Before treating a particular implementation as ready for savings, readers need evidence of review, safe handling of one-time signing keys, wallet integration, and tested recovery. The preview alone does not establish those things.
Layla makes this kind of work easier to pursue. Existing BCH outputs and ordinary wallets do not acquire post-quantum protection simply because the network can run such a contract.
Wallets and infrastructure make contracts usable
A working contract still needs a way for people to find their funds, understand a transaction, and sign it. Wallets, indexers, explorers, and metadata services do much of that work.
Paytaca's Watchtower supplies BCH application infrastructure, and its BCMR indexer makes token metadata available to other products. OPTN Labs offers wallet software and hosted services, including Electrum, Chaingraph, and token data access. These are examples of the services an application can use; an integration still needs its own testing.
Consider what happens when a metadata service goes offline. A CashToken transaction can remain valid while a wallet loses the token's name or icon. The interface should still show its category ID and balance. An authenticated metadata record establishes where that record came from; it does not prove an issuer's claims about the asset.
For developers, the practical checks include API formats, pagination, rate limits, supported transaction types, and recovery when a provider is unavailable. Users should have a way to export or recover their funds if the original service disappears.
How to judge an application's progress
The CashScript showcase and Bitcoin Cash Research application discussions are starting points for exploring projects. A demo, a deployed contract, and a maintained product answer different questions about what is ready to use.
For any application you plan to use or integrate, ask:
- Is it deployed on mainnet, and can someone verify the deployed bytecode against the published source?
- Who controls administration, price feeds, bridges, minting, or upgrades?
- What has been independently reviewed, and which version did that review cover?
- Can reported use or liquidity be checked from reproducible data?
- Do maintained wallets support signing and recovery throughout the flow?
These questions help explain why a promising contract may still be awkward or risky to use. A reliable application has to handle failed transactions, unavailable services, lost devices, and user mistakes as well as its successful demo.
What to watch next
The most useful signs of progress will be concrete: libraries agreeing on shared tests, wallets explaining advanced transactions clearly, and reviewed contract templates that developers can reproduce. Published incident reports and recovery procedures are valuable evidence too. They show how a team handles the conditions its launch demo never covered.
Layla gives developers more room to build. Its longer-term value will become clearer as people use those applications, encounter their limits, and decide whether they are useful enough to keep using.