Komodo

Komodo Upgrades to "Draco Typhon" v0.9.2, Sunsetting dPoW for a New Era of Consensus

Decker

— 3 min read
Komodo Upgrades to "Draco Typhon" v0.9.2, Sunsetting dPoW for a New Era of Consensus

The Komodo ecosystem is on the verge of a significant transformation with the recent release of Komodo v0.9.2, codenamed "Draco Typhon." This update, available for both the original Komodo Core Daemon and the enhanced KomodoOcean client, introduces a mandatory hardfork that will redefine the platform's consensus mechanism.The update is scheduled to activate at block 4,771,595 for the main Komodo (KMD) chain, anticipated around January 5, 2026. Assetchains on the network (such as CCL, CLC, and GLEEC) will fork approximately a day earlier, around January 4, 2026, at 12:00 UTC. All node operators must upgrade their software before these deadlines to remain on the canonical chain.

From dPoW to Auto Checkpoints: A Fundamental Shift

The centerpiece of the Draco Typhon release is the replacement of the long-standing Delayed Proof of Work (dPoW) consensus mechanism with a new system called Auto Checkpoints. This marks a pivotal change in how the Komodo blockchain secures itself against reorganizations and 51% attacks.The outgoing dPoW system relied on a set of 64 Notary Nodes to periodically notarize the KMD blockchain onto the Litecoin network, creating immutable checkpoints. While effective, this process involved a complex selection of 13 nodes from the larger group to form and broadcast the notarization transaction.

The new Auto Checkpoints system, ported from the Gulden (Munt) codebase - which itself was an adaptation from Peercoin (PPCoin) - streamlines this process significantly. Refining the industry-standard practice of manual developer checkpoints common in the UTXO world, the new system introduces a sophisticated 'dPoW 2.0' automation. Rather than relying on manual updates, this mechanism digitizes the process, allowing the project's trusted core to broadcast dynamic checkpoints seamlessly. With the master key shared among the project's most trusted developers and members, this approach maintains the network's decentralized governance integrity while delivering a robust, production-hardened and automated security solution.

Here’s how it works:

  • For each new block it receives or creates, the master node generates a checkpoint. This checkpoint is the signed blockhash of the block at a depth of 10 (i.e., current block height - 10).
  • This signed checkpoint is broadcast to the network.
  • Nodes validate the checkpoint, ensuring it exists in their block index and is a descendant of the previous checkpoint, before saving it.
  • If a node receives a checkpoint for a block not yet in its index, it marks it as "pending" and fetches the required headers.
  • Crucially, when processing new blocks, nodes verify that the latest checkpoint is an ancestor of the new block. If a node falls out of sync or onto a minority fork, it will reject blocks that do not build upon the checkpointed chain, forcing it to switch back to the canonical chain.

This mechanism effectively limits the maximum possible blockchain reorganization to a depth of just 10 blocks, providing robust protection against deep reorgs and 51% attacks.

A Community-Driven Fork: The Emergence of Komodo Classic (KMDCL)

Adding another layer of intrigue to this hardfork is the launch of a community-driven project, Komodo Classic (KMDCL). Timed to coincide with the mainnet activation block, KMDCL positions itself as a return to the original vision for Komodo, promising to "Revive the Essence of Komodo."

The Komodo Classic team plans to re-enable features that were previously deprecated, including:

  • Privacy: Reinstating shielded transactions (z-transactions).
  • Rewards: Bringing back the 5% Active User Reward (AUR) and increasing the block reward to 3 KMDCL.
  • Hardfork: All KMD holders at the time of the fork will receive an equivalent amount of KMDCL, provided they control their private keys.
  • Security: The project will implement Replay Attack Protection to ensure transactions on one chain are not valid on the other.

The KMDCL team has already launched a countdown website and has been actively developing its codebase, forking the KomodoOcean wallet as a foundation. While independent, their technical engagement with existing developers suggests a competent team is behind the initiative.With a major consensus upgrade on the main chain and the birth of a new, community-led fork, January 2026 is shaping up to be a pivotal month for the Komodo ecosystem.

Links:

Block diagram explanation:

Node 0 on diagram, protected by a checkpoint referencing block 123 (01e3...2d53), cannot be reorganized by Node 1 despite its longer chain of 137 blocks; when Node 1 attempts to reorg, the daemon rejects the alternative block at height 123 with the error:

CheckSync: nHeight 123 hashBlock 00b80df34806c8de763750588b2aee13483a4d2e48b2fb1b0faaebf6e07acb67 vs pindexSync->nHeight 123 syncCheckpoint=01e3f8443011dfa653e507c37d69a9ddf03d99adef0c1d2b651df8a2f6102d53
CheckSync: returning false (same height with sync-checkpoint)
ERROR: ContextualCheckBlockHeader: rejected by sync checkpoint lock-in at 123
AcceptBlockHeader ContextualCheckBlockHeader failed

Because the block hash (00b8...acb67) conflicts with the locked-in checkpoint hash (01e3...2d53), preventing the chain reorganization and ensuring checkpoint finality.

The same checkpoint protection mechanism applies to any fork attempt at blocks below the checkpoint: if Node 1 attempts to reorganize Node 0 at any block height lower than the sync checkpoint at block 123, the daemon will reject the alternative chain with the error "CheckSync: returning false (lower height than sync-checkpoint)", preventing any reorganization of blocks protected by the checkpoint lock-in mechanism.

Read more