Emergency Validator Set

Once emergency validators are set, the owner can no longer update the absent decrease factor, the below minimum weight decrease factor, the non-attestor decrease factor, or the non-consensus decrease factor. To update these factors, it must either be completed before setting the emergency validator set, or removing the validator set with owner_revert_emergency_validator_set while the subnet is still paused, and setting the factors. See Timing and Expiration.

In the event of a takeover, exploit, or other critical failure, a subnet owner can initiate a pseudo-fork on-chain to restore control of the subnet through a temporary and emergency validator set.

This feature can be used for pivots that have unavoidable breaking changes.

While subnets are decentralized networks, they also operate as independent ecosystems — often similar to organizations — and may require limited owner intervention to recover from emergencies.

Owners cannot directly remove nodes from a subnet. Instead, by performing a pseudo-fork, the owner can introduce a temporary validator set to regain control and restore network integrity.

Overview

A pseudo-fork is an on-chain event that creates a temporary "branch" of validator nodes while the subnet is paused. Once the subnet is called to unpause, this branch allows a subnet to resume consensus safely with a trusted validator set for a limited period.

• When to use:

  • Subnet compromise or exploit

  • Malicious validator takeover

  • Validator inactivity or failure preventing consensus

• Goal:

  • Allow the subnet owner to deploy a new, trusted validator class

  • Enable consensus to remove untrusted or inactive nodes via the normal reputation and consensus process

  • Return the subnet to normal operation automatically after a fixed number of epochs

---

Fork Lifecycle

1. Subnet requires recovery The subnet encounters an issue (e.g., exploit or validator failure).

2. Pause the subnet The owner pauses the subnet to halt all consensus activity.

   pub fn owner_pause_subnet(subnet_id: u32)

3. Create an emergency validator set The owner calls owner_fork_subnet, specifying:

   • The subnet ID

   • A list of current validator classified node IDs forming the new temporary validator set

     • Only these nodes are able to be elected as the validator and attest.

     • The remaining nodes can still be included in the consensus data and receive rewards.

   pub fn owner_set_emergency_validator_set(subnet_id: u32, subnet_node_ids: Vec<u32>)

   • Once this is called, the function will calculate how many epochs are needed to get a subnet node under the minimum reputation for it to be removed. See Timing and Expiration.

4. Redeploy the subnet (off-chain) The owner or coordinating service redeploys a new subnet instance off-chain, configured for the new validator set.

   • This may require recoding the subnet to prevent malicious nodes from participating in consensus and or ensuring they are absent from consensus submissions.

5. Unpause the subnet The subnet is unpaused on-chain, and the temporary validator set begins operating immediately.

   pub fn owner_unpause_subnet(subnet_id: u32)

   • Once called, and there is an emergency validator set, it will calculate the maximum epoch the emergency validator set can be active for. See Timing and Expiration.

6. Temporary validator control

   • Only the validators in the forked set can be elected.

   • They run consensus normally and can remove inactive or malicious nodes through reputation decay (e.g., falling below the subnet’s minimum reputation threshold).

7. Automatic reversion

   • The pseudo-fork automatically expires once the required number of epochs have passed — enough for reputation-based removal to complete. See Timing and Expiration.

   • After expiration, the subnet returns to its normal election process by removing the temporary validator set.

   • Any nodes removed during the time of the fork stay removed.

Timing and Expiration

After this time window, control reverts automatically to the standard validator election mechanism.

There are two primary windows:

• target_emergency_validators_epochs: The active duration of a pseudo-fork is calculated dynamically based on the number of epochs required for node reputation to decay from 100% to the subnet’s minimum threshold.

  • For each epoch, a validator submits consensus data; whether successful or not, it will increment the total_epochs value by one. One total_epochs is greater than the target_emergency_validators_epochs, the automatic version takes place.

• max_emergency_validators_epoch: This is the maximum epoch a forked subnet can use the temporary validator set. This is double the target_emergency_validators_epochs.

  • If the current subnet epoch is greater than this value, the automatic reversion takes place.

Summary

Phase	Action	Description
1	Pause Subnet	Halt consensus while initiating fork
2	Fork Subnet	Create temporary validator set on-chain
3	Redeploy	Reconfigure subnet off-chain with new validators
4	Unpause	Resume consensus under temporary control
5	Recover	Temporary validators remove malicious/inactive nodes, via consensus
6	Restore	Return to normal validator elections

Developer Notes

• owner_fork_subnet can only be called while the subnet is paused.

• The temporary validator set is enforced only for the fork duration.

• No permanent state changes occur to registered nodes — only their eligibility is restricted.

• Reputation decay logic determines how long the temporary set remains active.

• After reversion, the subnet continues from its prior epoch index, ensuring continuity of epoch-based logic.

This is an on-chain event that requires off-chain (in-subnet) coordination.