# V1.5.0 (development) is released **URL:** \ **Category:** Announcements\ **Created:** [February 26, 2026, 9:26pm UTC](https://openfhe.discourse.group/t/v1-5-0-development-is-released/2283 "2026-02-26T21:26:37Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![ypolyakov](https://yyz1.discourse-cdn.com/flex031/user_avatar/openfhe.discourse.group/ypolyakov/32/47_2.png) [@ypolyakov](https://openfhe.discourse.group/u/ypolyakov)\ **Post date:** [February 26, 2026, 9:26pm UTC](https://openfhe.discourse.group/t/v1-5-0-development-is-released/2283/1 "2026-02-26T21:26:37Z")
- Optimizes CKKS bootstrapping and polynomial evaluation for multithreaded scenarios ([#908](https://github.com/openfheorg/openfhe-development/issues/908)) - Adds a new mode of CKKS bootstrapping that achieves a smaller latency and higher precision ([#1074](https://github.com/openfheorg/openfhe-development/issues/1074)) - Adds support of multiparty CKKS for the COMPOSINGSCALING\* modes ([#1123](https://github.com/openfheorg/openfhe-development/issues/1123)) - Updates FHEW/TFHE parameters to reduce the probability of failure ([#1098](https://github.com/openfheorg/openfhe-development/issues/1098)) - Changes the default for PREMode from `INDCPA` to `NOT_SET` ([#1108](https://github.com/openfheorg/openfhe-development/issues/1108)) - Fixes several bugs, includes several smaller optimizations, and improves the documentation The detailed list of changes is available at [GitHub · Where software is built](https://github.com/openfheorg/openfhe-development/issues?q=is%3Aissue+milestone%3A%22Release+1.5.0%22) ---
**Author:** ![sloede](https://yyz1.discourse-cdn.com/flex031/user_avatar/openfhe.discourse.group/sloede/32/198_2.png) [@sloede](https://openfhe.discourse.group/u/sloede)\ **Post date:** [February 27, 2026, 10:42am UTC](https://openfhe.discourse.group/t/v1-5-0-development-is-released/2283/2 "2026-02-27T10:42:24Z")
Thanks a lot for the update and the new release! > [@ypolyakov](#): > > Adds a new mode of CKKS bootstrapping that achieves a smaller latency and higher precision ([#1074](https://github.com/openfheorg/openfhe-development/issues/1074)) Are there any published results showing that quantitatively compare latency and precision before and after the PR? It would be great to see what kind of effect we should expect in our applications. ---
**Author:** ![andreea.alexandru](https://yyz1.discourse-cdn.com/flex031/user_avatar/openfhe.discourse.group/andreea.alexandru/32/378_2.png) [@andreea.alexandru](https://openfhe.discourse.group/u/andreea.alexandru)\ **Post date:** [February 27, 2026, 2:20pm UTC](https://openfhe.discourse.group/t/v1-5-0-development-is-released/2283/3 "2026-02-27T14:20:41Z")
The second CKKS mode is ‘folklore’ and known to the community for a while; both modes use the same core components but in a different order [openfhe-development/src/pke/examples/CKKS\_BOOTSTRAPPING.md at main · openfheorg/openfhe-development · GitHub](https://github.com/openfheorg/openfhe-development/blob/main/src/pke/examples/CKKS_BOOTSTRAPPING.md). Changing the order means that some operations are done with fewer levels remaining, and in general we want to perform the most expensive operations with fewer levels remaining. In terms of speed-up, we saw between 1.04x and 1.53x speedup for various configurations, with the beginning of the spectrum corresponding to very sparse packing and the end of the spectrum (largest speedup) corresponding to full packing. But I don’t think these benchmarks have been published. In terms of precision, some benchmarks showcasing the precision of the two modes are [here](https://docs.google.com/spreadsheets/d/1p6-ZG9rBEE9SrkKIt0JjU1aJiYHevzblKOTuhLFW27U/). ---
**Author:** ![narger](https://yyz1.discourse-cdn.com/flex031/user_avatar/openfhe.discourse.group/narger/32/420_2.png) [@narger](https://openfhe.discourse.group/u/narger)\ **Post date:** [February 27, 2026, 4:40pm UTC](https://openfhe.discourse.group/t/v1-5-0-development-is-released/2283/4 "2026-02-27T16:40:47Z")
Thank you very much!! A couple of questions/notes: > [@ypolyakov](#): > > Adds a new mode of CKKS bootstrapping that achieves a smaller latency and higher precision ([#1074](https://github.com/openfheorg/openfhe-development/issues/1074)) 1. Does this multi-thread mode require any procedure to be activated? Or is it activated by default in any multithread CPU? 2. It looks like under this new update the function that i borrowed from ([OpenFHE CKKS chooses modulus chain that doesn't guarantee 128 bits of security](https://openfhe.discourse.group/t/openfhe-ckks-chooses-modulus-chain-that-doesnt-guarantee-128-bits-of-security/405)), namely` print_moduli_chain` now only returns moduli in Q and not in the whole QP anymore… nothing crazy, for now I am using the `EstimateLogP` function in `CryptoParametersRNS`, however I was wondering if something in this new update prevents the `poly.GetNumOfElements()` function to return the auxiliary moduli or is it a wanted behavior. thank you very much as always for the hard work and keeping everything open source :))) ---
**Author:** ![ypolyakov](https://yyz1.discourse-cdn.com/flex031/user_avatar/openfhe.discourse.group/ypolyakov/32/47_2.png) [@ypolyakov](https://openfhe.discourse.group/u/ypolyakov)\ **Post date:** [February 27, 2026, 8:52pm UTC](https://openfhe.discourse.group/t/v1-5-0-development-is-released/2283/5 "2026-02-27T20:52:09Z")
I would like to add some clarifications because there are two major optimizations for CKKS bootstrapping in v1.5: > [@ypolyakov](#): > > - Optimizes CKKS bootstrapping and polynomial evaluation for multithreaded scenarios ([#908](https://github.com/openfheorg/openfhe-development/issues/908)) > - Adds a new mode of CKKS bootstrapping that achieves a smaller latency and higher precision ([#1074](https://github.com/openfheorg/openfhe-development/issues/1074)) @andreea.alexandru described the second one (issue #1074) and the speed-up she mentioned is for the single-threaded execution for the `StC-First` mode as compared to the already existing `ModRaise` mode. BTW, the updated documentation for CKKS bootstrapping is available [here](https://github.com/openfheorg/openfhe-development/blob/main/src/pke/examples/CKKS_BOOTSTRAPPING.md) (the relevant flag is `BTSlotsEncoding`). An example of the new CKKS mode is provided in [the updated simple CKKS bootstrapping example](https://github.com/openfheorg/openfhe-development/blob/v1.5.0/src/pke/examples/simple-ckks-bootstrapping.cpp#L172). The second optimization is independent and primarily affects the multithreaded execution of the `ModRaise` mode of CKKS bootstrapping and the functional CKKS bootstrapping (which both existed in v1.4.2). The speed-ups for this case are summarized [here](https://docs.google.com/spreadsheets/d/1iYrNDTx-qwYO8kvRpFfTnqOGeUK0pwc4NLwO9VTH7Lg/edit?usp=sharing). The speed-up for regular CKKS bootstrapping can be up to 2x (on a server machine). For functional bootstrapping (for larger bit sizes), it can even be larger than 2x (on a server machine). The `StC-First` mode takes advantage of both optimizations in the multithreaded setting. Regarding `EstimateLogP`, I suggest adding a new topic in the Library Questions section, and we will look into it there. This topic focuses on clarifications related to the v1.5.0 release. ---
**Author:** ![andreea.alexandru](https://yyz1.discourse-cdn.com/flex031/user_avatar/openfhe.discourse.group/andreea.alexandru/32/378_2.png) [@andreea.alexandru](https://openfhe.discourse.group/u/andreea.alexandru)\ **Post date:** [April 7, 2026, 6:41pm UTC](https://openfhe.discourse.group/t/v1-5-0-development-is-released/2283/6 "2026-04-07T18:41:12Z")
To address the question about retrieving the moduli in QP: Using the public key for that was actually not recommended; as you noticed, that information is not available there anymore in v.1.5.0. The information needed is available in cryptoParams, and can be seen in the [`advanced-real-numbers.cpp`](https://github.com/openfheorg/openfhe-development/blob/main/src/pke/examples/advanced-real-numbers.cpp) example. Here it is, for convenience: ```auto const auto cryptoParamsCKKS = std::dynamic_pointer_cast( cc->GetCryptoParameters()); auto paramsQ = cc->GetElementParams()->GetParams(); std::cout << "\nModuli in Q:" << std::endl; for (uint32_t i = 0; i < paramsQ.size(); i++) { std::cout << "q" << i << ": " << paramsQ[i]->GetModulus() << std::endl; } auto paramsQP = cryptoParamsCKKS->GetParamsQP(); std::cout << "Moduli in P: " << std::endl; BigInteger P = BigInteger(1); for (uint32_t i = 0; i < paramsQP->GetParams().size(); i++) { if (i > paramsQ.size()) { P = P * BigInteger(paramsQP->GetParams()[i]->GetModulus()); std::cout << "p" << i - paramsQ.size() << ": " << paramsQP->GetParams()[i]->GetModulus() << std::endl; } } auto QBitLength = cc->GetModulus().GetLengthForBase(2); auto PBitLength = P.GetLengthForBase(2); std::cout << "\nQ = " << cc->GetModulus() << " (bit length: " << QBitLength << ")" << std::endl; std::cout << "P = " << P << " (bit length: " << PBitLength << ")" << std::endl; ``` ---
**Author:** ![ypolyakov](https://yyz1.discourse-cdn.com/flex031/user_avatar/openfhe.discourse.group/ypolyakov/32/47_2.png) [@ypolyakov](https://openfhe.discourse.group/u/ypolyakov)\ **Post date:** [April 8, 2026, 2:29am UTC](https://openfhe.discourse.group/t/v1-5-0-development-is-released/2283/7 "2026-04-08T02:29:59Z")
I want to emphasize that `print_moduli_chain` should not be used. The proper way to access the information about auxiliary moduli is what @andreea.alexandru posted [above](https://openfhe.discourse.group/t/v1-5-0-development-is-released/2283/5).