Kaia has asked Kairos testnet node operators to upgrade to version 3.0.0 before a permissionless validator hard fork scheduled for November 18. The change introduces a new validator lifecycle and modifies network connectivity. It does not set a date for the same changes on Kaia’s live mainnet.
The November 12 release notice sets the activation point at testnet block 233,366,400, with an estimated execution time of 11:06 p.m. Korea time. Kaia warned that version 3.0.0 is incompatible with older nodes and that the mainnet hard fork number will be published separately.
Kairos testnet prepares to change validator admission
An important change is the validator lifecycle handled through AddressBookV2, based on KIP-286. It defines how validators join, pause, resume and leave. The new VRank mechanism evaluates performance according to KIP-227, bringing a formalized scoring component to validator operations. These are testnet features being introduced under the permissionless upgrade.
Networking also changes. Kaia is retiring the proxy node role and moving endpoint node connections directly toward consensus nodes. Operators running the old kpn and kspn binaries must replace those arrangements; legacy node-type flags will fail at startup in the new software. The changes affect deployment architecture and monitoring, not merely a software version string.
Network roles and RPC responses change for operators
The project warns that a previously edited kcnd.conf file can survive a package upgrade. Operators may need to set MAXCONNECTIONS to 103 or remove a custom setting to use the new default. Changes to reserved connection slots can also cause startup failures when configured limits are too small.
Application developers should examine the RPC differences. The web3 namespace is being removed, with kaia_clientVersion suggested in place of web3_clientVersion. Fee-history fields, staking information methods, pending-block behavior and validator state queries also change. Such differences can affect wallets, dashboards and applications that expect earlier response formats.
Mainnet upgrade will require a separate announcement
Kaia also identified metric renames and removals that may require alerting-system updates. A node that is running but no longer exporting expected measurements can create blind spots for an operator. The project’s official release notes and technical documentation should be treated as the source of truth for implementation details.
The notice explicitly states that the mainnet hard fork number will come in a later release. That means this week’s announcement should not be framed as a completed network-wide move to permissionless validation. The next milestones are successful Kairos activation, testing under the new validator model and a separate mainnet deployment plan.
The testnet release also modifies monitoring and configuration requirements. Operators should verify peer limits, retired node binaries and API responses against the official technical notice. A working executable does not guarantee that a custom deployment or external monitoring service remains compatible after the fork.
Validator participation also involves operational keys and responsibilities that differ from holding a token in a wallet. BlockBriefing’s guide to private-key control provides that background; its report on Injective’s mainnet upgrade illustrates how exchanges and operators can face service interruptions during network changes. Kaia has yet to announce the equivalent mainnet schedule.
