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:
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.
What is the timeline for the lock-in process, and how long will endorsements remain open?
Lock-in happens on November 15th 2025. Activation is May 15th 2026.
For either a positive/negative/neutral endorsement to affect the consensus process, it effectively needs to be published before November 15th, and the earlier the better (gives time to discuss or react if you have any strong, valid objections or doubts).
Let’s go! Since everyone has defined the upcoming upgrades: P2S, Bitwise, Functions, and Bounded Loops. There’s no need to repeat them. I endorse all four CHIPs as well.
Thank you to all contributors and reviewers so far – I’ve frozen the Loops, Functions, P2S, and Bitwise CHIPs for lock-in, and stakeholder statements will be periodically updated through November 1. Final approval requests will go out in early October.
Please feel free to open issues in the repo for further comments, clarifications, or feedback, and please continue to publish and/or send pull requests with stakeholder statements.
These CHIP are integrated and live on the Sept. 15 public test network (tempnet) – please see that topic for details on how to setup a tempnet node and experiment with the upgrade 
I endorse “CHIP-2024-12 P2S: Pay to Script (c144f03f)” for 2026 lock-in.
The P2S CHIP relaxes some transaction standardness rules to align them with consensus. The VM Limits make sure that contracts still stay within compute bounds. It also increases the token commitment length somewhat. The CHIP has the effect of simplifying transaction validation and allowing larger contracts to be more conveniently expressed.
I endorse “CHIP-2025-05 Bitwise: Re-Enable Bitwise Operations (a432a19b)” for
2026 lock-in.
Adding the bitwise operations can be seen as an optimization of commonly occurring use cases. Such general optimization is a good idea as it can help reduce the need for tailor-made opcodes with more narrow use cases.
I haven’t yet implemented this CHIP in albaVm/albaDsl but plan to do so next and will come back if I have additional comments.
On behalf of myself (Kallisti.cash), Selene Wallet (selene.cash), bch.ninja, and xulu.tech, I fully endorse Functions, Loops, Bitwise, and P2S for the BCH 2026 Upgrade Cycle.
On behalf of myself, @zapit_io, @bitcann_org, and OpenCashDAO, I endorse the BCH 2026 Layla upgrade. Endorsement on X
BTW, how did we arrive at “Layla” this year? 
The general framework of course was:
A lot of people saw “Loops” as the “headliner” of the upgrade (especially at the point where functions was still in doubt), so names starting with “L” were discussed like “Lilia”, “Layla” or “Lola”.
I personally liked “Lilia”, a very pretty name and it has the “Li” repeated, but general discussion in a couple of Telegram groups & Twitter polls seemed to show a community response and preference for “Layla” - which then snowballed to be the name and now it’s just solidified haha.
I think it’s an excellent choice, because as well as meeting the criteria, “Layla” has a “loop like” repetition of “la”, and it has a “bitwise like” format of X_&_X (“y” is Spanish for &). So yeah that’s pretty much how it went.
Somebody coined “Layla” first, promoted it, became alpha on this topic and everybody else just followed.
The usual.
