PGT Part 2: Redefining Validators and Governance on Kaia

TL;DR:

• The Shift: Validator access is moving from "Permission by Application" to "Qualification by System."
• Decoupling: The roles of Validator (Network Operation) and Governance Council (Decision Making) are now structurally separated.
• Open Access: Any entity meeting the 5M KAIA stake and technical requirements can register to become a validator automatically via Kaia Square.
• Strategic Direction: By decoupling operational roles from governance and automating the onboarding process, Kaia aims to lower barriers to entry, foster a more scalable ecosystem, and align network participation with long-term growth.
• This article details changes in Validator and Governance functions. A full article with an updated Tokenomics proposal will be revealed separately.

1. Introduction: Structure Follows Strategy

In Part 1 (the PGT Framework), we outlined Kaia’s vision to transition from a stability-focused Public Permissioned Chain to a performance-driven Public Permissionless Chain. To achieve this, we must dismantle the structural barriers that limit participation.

The Kaia Network Policy is the blueprint for this transition. It solves a critical dilemma: How can we open the network to everyone while maintaining Kaia’s existing high performance and security?

The answer lies in decoupling roles and automating quality control.

2. The Great Decoupling: Validators vs. Governance

In the current Permissioned model, being a Validator and a Governance Council (GC) member is the same thing. This bundles technical operation with political responsibility, limiting the pool of participants.

The new policy separates these roles to optimize for specialization:

• Validators (The Engine):
  • Role: Focus purely on node stability, block production, and consensus.
  • Change: You no longer need to be voted in to run a node. If you meet the criteria, you can validate.
  • Lower Overhead: Because nodes no longer need to run a proxy node, infrastructure costs will drop by roughly 50%. This makes it highly capital-efficient for new technical experts to enter, and significantly increases profit margins for existing operators.
• Governance Council (The Steering Wheel):
  • Role: Focus on ecosystem direction, major decision-making, and growth.
  • Change: The core role of the GC remains the same as before. All GC members must operate as Validators, but not all Validators need to be GC members.

This allows technical experts to focus on infrastructure while ecosystem leaders focus on governance.

3. From "Approval" to "Automation"

Previously, joining Kaia required manual evaluation, reputation checks, and voting. This was effective for early stability but is a bottleneck for scalability.

We are shifting to a "Qualification by System" model:

• Automated Onboarding: Registration will occur via the Kaia Square portal. If an entity meets the minimum stake (5M KAIA) and technical specs, the process starts automatically.
• The Challenge Window: To prevent Sybil attacks and ensure security, a 7-day "Challenge Period" allows the community or Foundation to flag risks. If no valid challenge is raised, the node is confirmed as a Confirmed GC/Validator automatically.

4. Accountability: Contributions are Crucial

A permissionless system requires strict automated penalties to maintain quality. The new policy introduces clear consequences for underperformance:

• Validator Demotion: Nodes are monitored for VRank (Validator Rank). If a node fails to meet the VRank requirements, it will be excluded from participating in the consensus protocol and moved to an inactive validator status. If this status continues for approximately 30 days, the validator will then be demoted to 'Candidate' status, providing a grace period for node maintenance and staking adjustments.
• Governance Revocation: GC members are expected to actively participate. If a GC member misses 5 consecutive votes, the case will be brought forward as a governance agenda item, and the GC members will vote on whether to revoke that member's status.

5. What’s Next?

We have now defined the Permissionless expansion and the Governance automation. We have built a machine that is open to all but optimized for the best.

But a machine needs fuel. How do we incentivize Governance to do more than just run a node? How do we ensure they bring liquidity and users? 

The next component in our PGT framework is Tokenomics reform. 

We encourage the community to share their views in the upcoming third part of our PGT series, where we will lay out the mechanism behind Contribution Rewards and the shift to performance-based tokenomics.