The Meepo hard fork strengthens CKB-VM in key ways, making it safer, more reliable, and ready for more capable dApps. 🛠️
Here's what we addressed:
✓ Nervos DAO occupied capacity vulnerability
✓ Error code handling in memory protection
✓ ELF loading edge case
✓ x0 register overwrite in macro-operation fusion
A big thanks to community member phroi for reporting the DAO vulnerability—your contribution made this fix possible. 🙏
We're committed to listening, involving, and strengthening CKB together, and we're always happy to share more about our work with the community.
Read the full article 👇 View Article →
Here's how it works:
2/ Protocol-Level Flexibility: Fork Without Split
CKB is built on the UTXO Cell model, where each user's assets are stored in the discrete Cells—each with its own versioned Lock Script.
After a hardfork, each Cell continues to use the VM version it was deployed with, where:
- Existing Cells remain on the old VM version.
- Users are not forced to upgrade the Scripts.
- They opt in new features — if and when they want to.
This is made possible by introducing multiple hash_type variants (type, data, data1, data2, ...), each pointing to a different version of the code.
🤝 Multiple versions of Scripts and VMs coexist on the same chain.
⛓️ Upgrades won't split the network.
🔐 Users keep full control over both the assets, and the rules that govern them as well.
3/ Why It Matters 💡
Most chains treat a hardfork as a reset — override old logic and force everyone to upgrade.
CKB avoids this.
Multiple versions run side by side on the same chain. This eliminates the tension between network evolution and asset preservation.
4/ Script-Level Upgrade Workflow: Type ID + Lock Script
CKB provides Type ID + Lock Script model for managing script upgrades:
1️⃣ Initial Deployment: A Script developer deploys Scripts with upgrade plans in mind: Using Type ID to assign a stable identity but allows future updates.
2️⃣ Iterative Upgrade: Fix bugs, add new features, and change rules—the deployed code may undergo several upgrades using Type ID.
3️⃣ Code Freezing: At any point, one can freeze the code by modifying the Lock Script to be immutable.
5/ Script Developer & dApp Developer: Separate Roles
CKB separates two responsibilities:
- Script Developers: Deploy the Script and decide if it is upgradeable, via Type ID + Lock Script.
- dApp Developers: Choose how to reference a Script in their applications—fixed or upgradable.
Their options:
🔹Reference by type hash → Auto-follow the latest upgrades
🔹Reference by data / data1 / data2 hash → Stay fixed to the trusted version, ignoring the new one
Either way, dApp devs don't need to fear upstream changes breaking their logic or being kicked out of the network.
6/
This separation enables:
- Reusable Scripts across multiple dApps
- Opt-in upgrades — no forced coordination
- Long-term stability where needed, flexibility where desired
7/ Example: UDT Script Upgrade
Suppose someone deployed a UDT (User-Defined Token) Script using Type ID and created two tokens:
- UDT A uses type as hash_type
- UDT B uses data2 as hash_type
Later, the UDT Script is upgraded from Version 1 to Version 2:
- UDT A automatically adopts Version 2
- UDT B keeps running on Version 1
8/
Even if Version 1 is no longer present in a live Cell, it's not lost.
You can retrieve it from chain history, redeploy it, and use it again.
Old logic remains accessible—by design.
9/ A Better Forking Philosophy
CKB doesn't follow the rigid "hard vs. soft forks" binary. Instead, it offers:
✅ User autonomy
✅ Developer control
Assets stay protected.
Scripts remain stable—or upgradeable.
No one is forced to choose between safety and progress.
It's a better way to fork. And it works.
10/ Reference Links
Rethinking Forks: The Philosophy Behind CKB's Network Upgrade Design: 