> For the complete documentation index, see [llms.txt](https://totochain.gitbook.io/totochain/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://totochain.gitbook.io/totochain/toto-chain-faq/governance-and-upgrades.md).

# Governance and Upgrades

## **How are runtime upgrades and protocol changes managed on the Toto Chain?**

Toto Chain uses **forkless upgrades** to implement runtime changes without requiring a hard fork. This is managed through:

* **The Tech Committee**, which is currently composed of initial validators.
* **Governance Mechanisms**, where proposals for upgrades are reviewed and approved.
* **Automatic On-Chain Deployment**, allowing updates to be applied to the runtime environment without disrupting the network.

Changes include:

* **Protocol adjustments** (e.g., transaction fees, block validation rules).
* **Security improvements** inherited from the **Substrate framework**.
* **Feature additions** such as NFT rewards, referral enhancements, and node reputation tracking​.

***

## **Do node operators have a role in governance decisions?**

Currently, **node operators (validators/block producers) do not have direct governance control**, but a **reputation-based system is under development** that may:

* Allow **highly-rated validators** to have a say in governance.
* Influence the **selection of tech committee members**, ensuring that upgrades align with the interests of active and performing nodes.
* Potentially allow future **staking-based governance mechanisms**​.

At present, the **Tech Committee handles governance**, but future iterations might introduce more **decentralized decision-making**.

***

## **What is the process for testing and implementing updates to the chain?**

The Toto Chain follows a **structured update process** to maintain network stability:

1. **Proposal & Review:**
   * Changes are proposed and discussed within the **Tech Committee**.
   * Validators and key contributors may provide feedback.
2. **Testing on a Dev/Testnet:**
   * Proposed changes are **first deployed to a test environment**.
   * The test environment simulates **real-world transaction loads** and **block production**.
   * Bugs, vulnerabilities, and performance issues are addressed.
3. **Approval & Forkless Upgrade:**
   * If testing is successful, the change is **approved by the Tech Committee**.
   * The upgrade is **pushed as a forkless runtime upgrade** to all nodes.
   * Nodes **automatically update** their software without needing a hard fork.
4. **Post-Implementation Monitoring:**
   * The chain is monitored for stability, and any unexpected issues are addressed.
   * Future improvements are iteratively planned and proposed​.