2026 Layla Upgrade Lock-in CHIP Endorsements Thread

[BitcoinCashPodcast]

I don’t know if one of these has been done in the past, but it seems sensible to have a convenient place where endorsements can either be posted or linked somewhat in aggregate. Hopefully this facilitates people referencing, discussing or staying up to date with the momentum of various proposals.

Edit: Of course, individual CHIPs will be responsible for collecting their endorsements within the CHIP itself for others to review, and this thread obviously does not replace that.

Endorsement season has started it seems with @kzKallisti posting in support of Loops, Bitwise & Functions (original version), with review pending for P2S. Source

[CashDragon]

Great to see some CHIP stacking going on, no pun intended.

These three would round off the requirements to start implementing some strong privacy functionality, I hope, into BCH!

[bitcoincashautist]

CHIP-2025-05 Functions: Function Definition and Invocation Operations

With the VM limits CHIP in place finally we can safely enable functions inside our already powerful VM, and functions will serve as a great enabler and amplifier. Functions will let people structure their UTXO programs in ways that avoid errors, and will let people pack advanced contract logic into less bytes. It will simplify quantum-resistant solutions, and it will enable more privacy through MAST-like design patterns. The design of DEFINE/INVOKE is solid and all decisions have a solid rationale. I fully endorse this CHIP for 2026 activation!

CHIP-2025-05 Bitwise: Re-Enable Bitwise Operations

It was very annoying to miss basic bitwise operations present in most other programming languages, and finally it was the VM limits CHIP that opened the door to completing the set of bitwise operations. I fully endorse this CHIP for 2026 activation!

CHIP-2021-05 Loops: Bounded Looping Operations

Another fruit of VM limits CHIP, finally contracts authors can work with transaction totals without having to unroll loops or having to use other error-prone workarounds. Loops will also open the door to implementing many operations that are missing as native functions, such as EC operations and advanced math operations like exponentiation, opening the door for more financial and privacy applications. I fully endorse this CHIP for 2026 activation!

CHIP-2024-12 P2S: Pay to Script

This is very exciting! Since CashTokens upgrade the smart contract ecosystem has moved past “send to address” flow to a flow where client-side app creates the transaction for the user. P2S will fit right in, and I expect that app builders will find P2S more convenient than P2SH. I fully endorse this CHIP for 2026 activation!

I’d like to add that the gap between relay and consensus rules has been an obstacle to experimentation, and this is a great step towards closing that gap. I think what matters here is that the default is maximally permissive (consensus-limited only by DoS considerations) and then node operators & miners can further restrict it if they want, as opposed to status quo of being restrictive and then some operators may relax it and cause unexpected issues for everyone else. I hope to see OP_RETURN alignment next, as OP_RETURN outputs are a convenient place to define function bodies to be shared by many inputs.

[BitcoinCashPodcast]

@ShadowOfHarbringer endorsed Functions, Bitwise & Bounded Loops chip in my Telegram channel. With a neutral for P2S. He has also posted in the relevant threads here on BCR.

[albaDsl]

I endorse CHIP-2025-05 Functions (without Takes 2 & 3) for 2026 lock-in.

In my mind there is no doubt about the massive value that functions provide to a programming language. The Functions CHIP delivers a lot of that value to Bitcoin Cash. One of the key benefits of functions is that they provide a means of abstraction which is how complexity is tamed as contracts grow larger (albaVm HTML logs example). Abstraction allows developers to create higher-level constructs out of primitives, and then work at this higher-level without being distracted by the details. Abstraction removes a lot of code repetition and makes contract code easier to audit, increasing safety. In addition, functions allow for recursion which can be used to succinctly express certain algorithms, also simplifying review.

What risks are associated with the Functions CHIP? As with any change there is the risk of introducing bugs along with the implementation. Having implemented the Functions CHIP myself in albaVm, my view is that it is simple and not riskier to implement than other CHIPs we have delivered recently.

Metaprogramming has been brought up as a risk. But it is also a useful feature that allows the Functions CHIP to offer run-time-created immutable tables with cheap lookups (Windowed EC scalar multiplication example). I don’t view metaprogramming as a downside. Even today it is possible to do very limited scale metaprogramming using evaluators like TurtleVm. And the Loops CHIP (2026) will make such evaluators a lot more practical.

There is a risk that we will discover a better design for functions down the road. This risk has been mitigated by all the hard work that has gone into this CHIP, and I think we have a really good design. I don’t think that delaying this CHIP for another year would be productive. The main contender to the Functions CHIP, OP_EVAL, was investigated thoroughly by the community. I implemented it in albaVm & albaDsl and wrote contract code using it. In my view the Functions CHIP better solves for the common use case of having functions that are globally available from any part of the contract at little cost. It also provides a better compilation target for CashScript. OP_EVAL on its own does not solve as well for this, but could still be a useful construct for other use cases. So it is worth keeping on the radar. Also note that the Functions CHIP does solve for immutable lambdas.

I think we have great momentum as a community right now and that we should capitalize on this moment and release functions in 2026. It will be a huge boost for Bitcoin Cash!

[MathieuG]

I support the 4 CHIPs proposed by Jason Dreyzehner for activation on Bitcoin Cash May 2026.

Below are my support statements for each of the CHIPs where I elaborate on my reasoning.

These statements are for myself personally, but can also be considered support statements for Cashonize and ParityUSD! For any other team projects where I am not the sole-lead, I will logically first have to discuss any separate CHIP statements.

CHIP-2024-12 P2S: Pay to Script

The ‘Pay to Script’ CHIP bundles a few small related changes which are low-hanging fruit for improving contract development on BCH. The CHIP removes the non-standardness restrictions for custom locking scripts which improves usecases like Cauldron DEX contracts or ZCEs by not forcing these usecases to use P2SH for standardness. Further, the CHIP improves the ease of contract development by removing the 1650 input bytecode standardness limit and by increasing the maximum commitment length. The CHIP does not introduce any novel concepts but instead removes or relaxes current constraints. I fully support this CHIP for activation in May 2026!

CHIP-2021-05 Loops: Bounded Looping Operations

The ‘Bounded Looping Operations’ CHIP got first proposed in 2021, now with the targeted VM limits activated in 2025 the groundwork has been laid to finally incorporate loops into the BCH VM by accurately measuring and limiting script resource usage. Loops are a very elementary concept for programming languages so now that they can be enabled in a straightforward way, we absolutely should. The Bounded loops CHIP research had been completed for years already and represents BCH overcoming dogmas and misconceptions on loops in Bitcoin. Fully support the CHIP and look forward to incorporating loops into CashScript to empower contract developers to create more advanced contracts!

CHIP-2025-05 Bitwise: Re-Enable Bitwise Operations

The ‘Bitwise’ CHIP is long-desired restoration of some of the remaining missing bitwise operations. After the VM Limits CHIP of the previous upgrade it has become straightforward to introduce new opcodes without any custom limits and in a way that nicely integrates with the existing test framework. BitcoinCashAutist and myself had even done some prior draft work for proposing to re-activate bitwise ops is a similar fashion. Fully support the CHIP for activation in May 2026!

CHIP-2025-05 Functions: Function Definition and Invocation Operations

The ‘Functions’ CHIP is a modern adaptation of an old but very powerful idea for improving the scripting language. With CashScript we had already run into the need for macros/libraries to make the high level language developer friendly & powerful. The idea to enable data-as-code by evaluating as bytecode is general concept but the devil is in the details of the implementation. With the benefit of a much better understanding of the evolution of the VM we’re able to look at these old ideas through a new lens.

The first iteration of the proposal, OP_EVAL, made strides in arguing against any kind of ‘stack isolation’ which is an anti-feature in practice. After great discussion with many back-and-froths, the proposal changed its approach to using 2 opcodes: OP_DEFINE & OP_INVOKE. The main reason being that stack juggling whole functions is actually a big drawback for creating compilers and optimizing contract code. With the 2nd iteration of the proposal, the discussion focused on possible dangers of allowing “function factories” and adding “mutation tracking” safety rails. The whole process thoroughly explored the solution space with multiple variations. With the current (unrestricted) functions CHIP coming out as the best solution.

The Functions CHIP represents a major unlock in the power of the VM, enabled by the prior work on VM limits. We can expect to see permissionless innovation for a much more advanced class of contracts including quantumproof cryptography, zero-knowledge usecases, cross language compilers. This will move out the frontier of innovation, allowing for exploration of very exciting new ideas. I fully support the Functions CHIP for activation in May 2026!

[Jonathan_Silverblood]

For the sake of clarity I will also go ahead and provide my endorsements for the following chips well ahead of the lock-in date. The following endorsements are my personal opinions, and apply to any chip where I am personally a stakeholder, or where a project I own is a stakeholder:

CHIP-2024-12 P2S: Pay to Script

While not ideal to bundle separate changes, each of the change listed here is either clear step towards bridging the gap between standardness and consensus enforcement, or is a reasonable adjustment to existing limits. As such, I endorse the CHIP-2024-12 P2S: Pay to Script for activation in May 2026.

CHIP-2021-05 Loops: Bounded Looping Operations

Loops have a clear value and their omission in the original VM was, in hindsight, a clear blunder. With the VM limits in place we are in a good position and can safely add loops. I fully endorse CHIP-2021-05 Loops: Bounded Looping Operations for activation in May 2026.

CHIP-2025-05 Bitwise: Re-Enable Bitwise Operations

The addition of bitwise opcodes reduces development cost and, like loops, is something that we should have had from the very start. I fully endorse CHIP-2025-05 Bitwise: Re-Enable Bitwise Operations for activation in May 2026.

CHIP-2025-05 Functions: Function Definition and Invocation Operations

Functions is the chip most difficult for me to be confident about and it has the potential to impact practically every aspect of using the BitcoinCash scripting language. I do not come from a technical enough background to fully evaluate all aspects of this CHIP.

However, through the discussion that have happened since the May 2025 upgrade, I have come to the conclusion that there is a significant risk of infrastructure and other projects in the space investing in non-trivial workarounds. Having seen first-hand the amount of work that can go into commiting to using clearly non-ideal solutions, and the additional difficulty in verifying safety for such work-arounds, I have decided that simplicity is the better trade-off.

Furthermore, previously, I had preferred a wait-and-see approach and that it would be fine to hold off on functions for May 2027, but this would give a full year of active development of potential workarounds, so I am somewhat reluctantly endorsing CHIP-2025-05 Functions: Function Definition and Invocation Operations for activation in May 2026 in the hope that we will avoid cementing such workarounds in popular infrastructure tooling.

[BitcoinCashPodcast]

@Fiendish has endorsed the 4 CHIPs. Source

[BitcoinCashPodcast]

I have published The BCH Podcast CHIP endorsements on the Podcast blog. Reproduced below:

---

The Bitcoin Cash Podcast is adding its support & approval for all 4 of the Jason Dreyzehner proposed CHIPs to lock-in November 15 2025 & go live May 15 2026 as the “Layla” upgrade. I will also be advocating as such regarding my involvement internally in Selene, BLISS & BLAZE and don’t anticipate any difficulties there, but this statement is not on behalf of those entities.

• CHIP-2021-05 Loops: Bounded Looping Operations

Github commit hash: bd3ebc76bfa2190255fd3b5fcd84ec8910652f4e

• CHIP-2024-12 P2S: Pay to Script

Github commit hash: c144f03fe11b6de0e924b2285b355370d0e658b8

• CHIP-2025-05 Bitwise: Re-Enable Bitwise Operations

Github commit hash: a432a19bcbc597391d0f0a29ae62a902b575d1dd

• CHIP-2025-05 Functions: Function Definition and Invocation Operations

Github commit hash: 26e22566a18f2f3b542ff46a70d258d5da585cd8

Note: Functions CHIP is the unaltered version, not the “Take 2” or “Take 3” proposals.

As discussed on The Bitcoin Cash Podcast Episode 157, community polling indicates a high appetite for protocol innovation & upgrades - presumably built on the confidence of previous upgrade quality & results. It is very noticeable how the CashTokens upgrade in 2023 is living up to expectations in late 2025. There has been no problems really to speak of & impressive traction/uptake of CashTokens technology. I have a biased favourite project in the BLISS NFT ticket collections, but the success of CashTokens is widespread and compelling. One excellent recent example, congratulations to the Riften Labs team on recently passing $1M USD TVL on Cauldron! The mounting success of the CashTokens ecosystem speaks to the quality of both research & implementation of BCH upgrades and the community’s ability to make powerful investments in those upgrades without expecting instant gratification. The trend is set to continue in 2026.

Loops, Functions & Bitwise operations are all standard issue features of essentially every programming language ever so I’m glad to see the BCH VM catching up to that standard. Loops demonstrates that yet again the BCH community is able to bypass propaganda & misunderstandings (“Bitcoin VM has no loops”) in a way that other cryptocurrency communities severely struggle to. I was also impressed by the community debate that produced the final products (including iterating Functions from OP_EVAL, different function variations & the removal of lowering base-instruction cost). It is critical for the CHIP process & the work produced to be evaluated & critiqued without contention becoming unresolvable.

I would also like to note I see an underrated value in the P2S CHIP specifically - moving P2S from non-standard relay policy to standard. Especially given the current drama in BTC over policy/consensus gap exploitation (aka “Node wars” between “Knots/filters” vs “Core/spammers”), I see a strong opportunity for BCH to once against front-run potential problems by a research effort (& possibly CHIP) to unify policy/consensus where appropriate or document the status/reasoning and reflect on alternative solutions where not. For instance, perhaps an ABLA/DAA style approach - either by consensus or policy - could be used for minimum fee rates? Needs investigation. BitcoinCashAutist (notable CHIP contributor) also mentioned this in his 2026 CHIP endorsement. I encourage readers interested in this initiative to read or contribute to my Bitcoin Cash Research thread about this topic of non-standard transactions.

In any case, the four endorsed CHIPs combined make a very powerful upgrade. I’m thrilled to see BCH making bold strides forward to accelerate our growing momentum & industry-leading presence in UTXO DeFi. I am also glad to be a part of the momentum around endorsements (my own endorsement in 2024 was not published until late October) & developer tooling/education (sign up to BCH BLAZE!).

There is also great stuff on the horizon with the 1 minute blocks proposal continuing to be discussed. I would love to see UTXO Commitments start to be focussed on in more detail & the relay policy ideas mentioned above but that’s simply my wishful thinking - as always, a /someone problem!

Finally, a big thank you to Jason Dreyzehner for his tireless work on these proposals & anyone who has been involved in feedback, review, implementation, testing or assistance of any kind. It’s a team effort and testament to a decentralised community but Jason also deserves specific recognition for his ceaseless effort here. Delivering two enormous upgrades back-to-back is an effort that will resonate through BCH history in perpetuity.

Layla follows CashTokens & Velma in bringing BCH to the forefront of cryptocurrency scriptability and will draw in ever more interested parties as a result. I’m enthused & anticipating activation already!

Jeremy

[lucasmcducas]

Lets

Fucking

GO

https://x.com/thelukepryor/status/1964726679357767944

[jimtendo]

CHIP-2024-12 P2S: Pay to Script

This CHIP helps align Standardness Rules with Consensus Rules, reducing edge-case complexity in BCH contract development and simplifying certain constructs.
With this proposal, locking bytecode is no longer required to match specific patterns (P2PKH, P2SH20/32, P2PK, etc.). It also makes length requirements consistent across Standardness and Consensus, and increases the Token Commitment length from 40 bytes to 128 bytes.
In my view, these changes are both sane and sensible, and I give this CHIP my full support and endorsement.

CHIP-2025-05 Bitwise: Re-Enable Bitwise Operations

Some of these operations already exist but were disabled in the past due to safety concerns stemming from loose specification.
This CHIP proposes to re-enable them under a tightened and unambiguous specification. Jason has already demonstrated the practical utility of these operations in his Quantum Root Vault proof-of-concept (Quantumroot: Quantum-Secure Vaults for Bitcoin Cash).
I believe this proposal is valuable and robust, and it has my full support and endorsement.

CHIP-2021-05: Loops (Bounded Looping Operations)

Looping is a fundamental programming construct that will significantly simplify many contract systems and provide the BCH VM with powerful new capabilities.
With the activation of the BCH VM Limits CHIP in 2025, we now have the safeguards needed to enable looping safely, preventing issues such as infinite loops or resource abuse.
This proposal is both practical and well-timed, and it has my full support and endorsement.

CHIP-2025-05 Functions: Function Definition and Invocation Operations

Over the past several years, the Bitcoin Cash Virtual Machine has undergone significant upgrades (such as Introspection and CashTokens), greatly expanding its capabilities. These improvements have enabled the development of advanced smart contract systems - comparable to those on EVM-based platforms - while still preserving the efficiency of Bitcoin’s original UTXO model. True to Bitcoin’s founding vision, this ensures BCH remains both affordable and scalable as a peer-to-peer electronic cash system.

Jason’s Functions CHIP (2025-05) manages to improve this efficiency even further by allowing compression of BCH Contract Systems, thus reducing the transaction costs for many Smart Contract use-cases. At scale, these compression benefits become very beneficial towards BCH’s goal of reaching mass adoption. Just as importantly, the CHIP’s simple, non-constrained, approach also allows for many future discovered/undiscovered use-cases (e.g. Quantum Proof Vaults, MAST-like constructs that also allow code-execution) to be implemented optimally without requiring additional, specialized, changes to the BCH VM itself - or incurring technical-debt that might need to be undone later.

For these reasons, the Functions CHIP (2025-05) has my full support and endorsement.

[BitcoinCashPodcast]

GP Endorsement for CHIPs published

General Protocols has been convinced that in the space of possible alternatives, including EVAL, modified versions of Functions and doing nothing, define/invoke is the best choice for BCH and endorses CHIP-2025-05 Functions (Commit 26e2256) for 2026 activation.

General Protocols also endorses the following CHIPs for 2026 activation:

• CHIP-2021-05 Loops (Commit bd3ebc7)
• CHIP-2024-12 P2S (Commit c144f03)
• CHIP-2025-05 Bitwise (Commit a432a19)

[BitcoinCashPodcast]

Minisatoshi endorsement

[albaDsl]

I endorse “CHIP-2021-05 Loops: Bounded Looping Operations (bd3ebc76)” for 2026 lock-in.

In my view the Loops CHIP makes the Bitcoin Cash VM “Turing-complete within VM limits” (Linear Bounded Automaton might be the more correct term). This is very important as it greatly increases the number of useful computations that can be conveniently expressed using the VM. Together with the Functions CHIP, Loops really complete the VM. There is some overlap between these two CHIPs, but they also complement each other and should go in together.

Having implemented the Loops CHIP (in albaVm) my view is that the implementation risk is not higher than other CHIPs we have delivered recently.

Metaprogramming has been brought up as a risk (especially in the context of Functions). Loops also enable metaprogramming by making evaluators like TurtleVm more practical. Such evaluators can now be made universal and able to evaluate any size program within VM limits. And as VM limits are relaxed evaluators become more practical. Metaprogramming is evidence of the VM’s growing capability. Turing’s original machine was also capable of hosting Turing machine evaluators, with simulated tapes.

By combining Loops and our existing conditional operators it is possible to implement Functions (in an inefficient & convoluted way). One could even establish TurtleVm as such a function and call out to it from various parts of the contract without having to duplicate the evaluator at every call-site. So with Loops we can have both Functions and OP_EVAL but in an inefficient and hard to audit way. Better to establish an efficient and standard way of doing Functions (the Functions CHIP) and roll out Loops & Functions together. Also note that Loops can be expressed via the recursion provided by the Functions CHIP, but less efficiently.

With Loops and Functions the Bitcoin Cash VM becomes much more capable which opens up for more permissionless innovation. This means that we can have solutions like Quantumroot already in May 2026, instead of having to implement quantum resistance via the CHIP process.

[BitcoinCashPodcast]

@cculianu endorsement.