The Persistence Core-1 Chain is preparing a major upgrade of its core software to Cosmos SDK v0.53.x. This upgrade will be rolled out in multiple carefully planned phases instead of a single big jump.
In this blog, we’ll break down why this upgrade is needed, what each phase involves (in simple terms), and why we will be implementing a step by step approach.
Table of Contents
- Why the Upgrade is Needed
- Overview of the Phased Upgrade Plan
- Phase 1: Upgrade to v0.50.x with LSM enabled – Estimated ~3–4 weeks
- Phase 2: Upgrade to v0.50.x with LSM disabled (Transition to “Gaia/Liquid”) – Estimated ~2–3 weeks
- Phase 3: Upgrade to v0.50.x Vanilla (no LSM, official SDK) – Estimated ~1–2 weeks
- Phase 4: Upgrade to v0.53.x (latest version, plus Babylon integration) – Estimated ~3–4 weeks
- Why Not Do It All at Once?
- Final Thoughts and Next Steps
- About Persistence One
Why the Upgrade is Needed
Outdated Software (End-of-Life)
The Persistence chain currently runs on a customised version of Cosmos SDK v0.47 (with a special feature called LSM enabled). While this version is still supported, it is not part of the upcoming Long-Term Support (LTS) roadmap, with Cosmos development efforts shifting towards newer versions like v0.52 and beyond.
Running on an EOL version can be risky; critical bug fixes or security patches are no longer provided. Upgrading ensures the chain stays secure, compatible with other projects, and benefits from the latest improvements in the Cosmos ecosystem.
Cosmos SDK and New Features
Cosmos SDK is the modular framework that the Persistence chain is built on. Newer SDK versions (v0.50 and v0.53) bring performance improvements, bug fixes, and new capabilities.
By moving to v0.53.x, Persistence will align with the current Cosmos tech standards and be able to integrate new modules (for example, the Babylon module for added security, explained later).
LSM (Liquid Staking Module)
The current chain uses a custom Liquid Staking Module (LSM). LSM allowed users to “tokenise” their staked assets into liquid tokens that could be transferred or used in DeFi while still earning staking rewards. This was a custom feature on Cosmos SDK v0.47. However, maintaining this custom LSM on newer SDK versions is challenging.
In short, the upgrade will also involve shifting how liquid staking is handled, moving from the old approach to a more standard one.
Overview of the Phased Upgrade Plan
The outlined phased upgrade plan is to move from v0.47 to v0.53 in gradual steps. Breaking the upgrade into phases helps isolate changes, test each step thoroughly, and reduce the risk of errors or downtime.
Here’s a high-level summary of each phase:
Phase 1: Upgrade to v0.50.x with LSM enabled – Estimated ~3–4 weeks
The first step is upgrading the chain from v0.47 to v0.50.x (a major new version of the Cosmos SDK) while keeping the Liquid Staking Module active. In this phase, nothing changes for end-users feature-wise; the LSM continues to function as before. The goal is to get on the newer base (v0.50) and ensure all existing modules and features (including LSM) work correctly on that version. We will conduct thorough testing of all modules on v0.50.x to make sure the chain runs smoothly with the new codebase.
Phase 2: Upgrade to v0.50.x with LSM disabled (Transition to “Gaia/Liquid”) – Estimated ~2–3 weeks
In this phase, the chain will still be on Cosmos SDK v0.50.x, but the Liquid Staking Module will be turned off. Disabling LSM at this stage is a precautionary move to detach the chain from the custom LSM before moving forward. The phrase “move to Gaia/Liquid” refers to aligning with the Cosmos Hub’s standardised approach to liquid staking. For the end user, there will be no impact on features like stkXPRT.
By the end of Phase 2, the chain will be running on v0.50.x without any custom staking modifications, a stepping stone to a fully “vanilla” (unmodified) Cosmos SDK.
Phase 3: Upgrade to v0.50.x Vanilla (no LSM, official SDK) – Estimated ~1–2 weeks
Now comes upgrading the chain to use the vanilla Cosmos SDK v0.50.x, meaning the official, unforked version of the software with no custom patches. Essentially, the Persistence chain’s code will remove the LSM-specific code fork entirely and run the same SDK code that any other project on v0.50 would run. This is a crucial cleanup step: by removing the forked (custom) dependency, the chain’s codebase becomes cleaner, easier to maintain, and ready to accept future updates.
Because we already disabled LSM in Phase 2, moving to the vanilla SDK in Phase 3 should be straightforward; no special migrations are needed aside from standard data migrations that Cosmos SDK provides.
After this phase, the Persistence chain will be on a fully supported v0.50.x release of Cosmos SDK, with all the stability that brings.
Phase 4: Upgrade to v0.53.x (latest version, plus Babylon integration) – Estimated ~3–4 weeks
Finally, with the chain stable on v0.50, the last step is to upgrade to Cosmos SDK v0.53.x, the latest long-term supported version. This brings Persistence chain up-to-date with the newest features and improvements in the Cosmos SDK family. In this phase, we also plan to integrate the Babylon SDK module to enable BSN integration.
Throughout all these phases, we will likely use testnets or other testing processes to validate each upgrade step before it goes live on the main network. The estimated durations (in weeks) include time for development, testing, and addressing any issues that come up in each phase.
Why Not Do It All at Once?
In short, while merging steps might save a bit of calendar time, the risks far outweigh the benefits. The phased approach is designed to protect the chain and its users, ensuring data integrity and network stability at every step.
Even if some steps seem straightforward, we will only merge phases if we are absolutely confident that it will not compromise safety.
Final Thoughts and Next Steps
For the community and users, this upgrade should ultimately enhance the robustness and longevity of the Persistence chain. By moving to supported SDK versions, Persistence will receive upstream improvements and security updates. Disabling the old Liquid Staking Module and potentially adopting the new standard liquid staking approach means the chain stays aligned with Cosmos ecosystem best practices.
Looking ahead, integrating with Babylon’s technology could enable Bitcoin-powered security and position Persistence as one of the chains actively leveraging these advancements.
About Persistence One
Persistence One is building the BTCFi Liquidity Hub, enabling fast, near-zero-slippage swaps for BTC, BTC-variants, and LSTs on Persistence DEX.
BTCFi’s rapid growth has created multiple BTC-related assets, making fragmentation a big challenge. Persistence One will provide a single liquidity hub, simplifying value transfer across the Bitcoin ecosystem.
Twitter | LinkedIn | Telegram | YouTube | Reddit | [email protected]