Governance Fundamentals

KUB network relies on community-driven governance. A broad set of stakeholders must approve and adopt any protocol upgrades. These include validators, full node operators, developers, infrastructure providers, and token holders. Without alignment, a change can result in a split of the chain, known as a fork.

Forks

There are two primary forms of protocol upgrades: hard forks and soft forks. A hard fork introduces changes that are not compatible with previous versions of the node software. Nodes that fail to upgrade by the designated activation block will no longer recognize new blocks, causing them to diverge from the main network. The network may experience a temporary halt or a full chain split if enough validating power is split between versions. In contrast, a soft fork is backward-compatible. Nodes running older software can continue validating transactions under the new rules, provided those changes are restrictive or additive rather than conflicting. This allows for gradual adoption and less risk of fragmentation.

Upgrades on the KUB Network

In the early stages of upgrading the consensus mechanism on the KUB network, we started with changing the consensus from Proof-of-Authority (PoA) to Proof-of-Stake-Authority (PoSA) by doing a hard fork called Erawan Upgrade. Since the transition of consensus is running smoothly on the KUB network, we have upgraded the consensus from PoSA to Proof-of-Stake (PoS) called Chaophraya Upgrade. The PoS consensus was designed to reduce the restriction of PoSA that the validator node still needs permission or approval from the existing authority. The PoS on the KUB network includes the mechanism to randomly select the validators and the staking contract. The consensus uses KUB Coin, which is staked in the staking contract as a signer’s power. In every period of selecting validators, the PoS mechanism will randomly target numbers from the total stake of the available validators in the PoS contract. All the numbers will transform into the list of authorized validator addresses and be committed to the PoS contract.

The recent upgrade of the KUB network, known as the Lausanne Upgrade, has introduced several parameters and features governed directly on-chain. Staking and slashing thresholds have been adjusted, including the solo node slashing amount and the minimum KUB Coin required for staking with pool nodes. Validators also benefit from the ability to reactivate themselves if they meet the necessary staking requirements after being removed for issues like missed conditions. Additionally, a new partial unstaking feature allows validators to partially withdraw their staking funds while maintaining operations, offering greater financial flexibility as thresholds evolve.

Roles in Governance

• Validators are responsible for confirming blocks and enforcing consensus rules. They play a critical role during upgrades, as their collective stake determines which version of the protocol becomes canonical.

• Full nodes, while not responsible for block production, validate all network activity and serve users, dApps, and service providers. These nodes must also be updated during upgrades to ensure compatibility.

• Core developers research, propose, and implement protocol changes. Meanwhile, token holders and end users participate by voicing support or concerns, often through delegated voting or off-chain feedback systems.

Upgrade Testing and Deployment

Once approved, upgrades go through several technical stages. Developers implement changes and test them in private environments. When stable, the upgrade is deployed to a public testnet, where it operates under real-world conditions without affecting actual assets.

If the testnet phase shows no critical issues, a mainnet deployment is scheduled. Validators and node operators are given a timeline or block number by which they must upgrade. Widespread adoption ensures the new version becomes the official continuation of the KUB network.