# 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). ## 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 changed the consensus from Proof-of-Authority (PoA) to Proof-of-Stake-Authority (PoSA) via a hard fork called the Erawan Upgrade. Since the transition to PoSA has run smoothly on the KUB network, we have upgraded the consensus from PoSA to Proof-of-Stake (PoS) via the Chaophraya Upgrade. The PoS consensus was designed to reduce the restrictions of PoSA, so that the validator node no longer needs permission or approval from the existing authority. The PoS on the KUB network includes a mechanism to randomly select validators and a staking contract. The consensus uses KUB Coin, which is staked in the staking contract as a signer’s power. In each period for 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 be transformed into a list of authorized validator addresses and committed to the PoS contract. The [Lausanne Upgrade](/node-upgrade-instruction/lausanne-v2.3.0-bkc.md) has introduced several parameters and features governed directly on-chain. 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. The recent [Basel Upgrade](/node-upgrade-instruction/basel-v2.4.0-bkc.md) significantly boosts KUB Chain’s performance by reducing block times from `5` to `3` seconds while maintaining stability through new system-owned Failsafe Supernodes. This strategic upgrade streamlines the ecosystem by merging Official Nodes into a unified Pool Node structure and halting new Solo Node registrations to prioritize scalability, though existing Solo operators remain the same. ## 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.kubchain.com/governance/governance-fundamentals.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.