Churning and Node Lifecycle

Churning is the mechanism that keeps the THORChain validator set fresh, secure, and decentralized over time.

This article explains the validator-life-cycle idea. It does not prove the current churn interval, next churn height, active set, readiness state, slash-point threshold, or bond-withdrawal availability.

What is Churning?

At configured churn intervals, active nodes can rotate out and eligible Ready nodes can rotate in. Official node docs currently describe the normal cadence as roughly 43,200 blocks, or about 2.5 days, but ChurnInterval, HaltChurning, failed keygen, and migration state can change or delay what happens. Treat the quoted cadence as a documentation snapshot, not a next-churn promise.

During a churn event:

• A churned-out node moves back to standby; its bond is not automatically returned.
• A new Asgard vault is created with fresh TSS keys.
• All active nodes begin observing and signing with the new vault.

Why Churning Matters

Security through rotation: Regular key rotation limits the window for key compromise accumulation.

Economic incentives: Ready nodes can compete for selection through bond and current eligibility, while churn-out rules can consider leave requests, bans, age, bad performance, low version, and low bond. The exact selection set remains protocol-state dependent.

Fault tolerance: If a node becomes unresponsive or malicious, churn and slash-point mechanics can remove it from the active set, subject to current protocol state.

Node Lifecycle

The documented progression is Whitelisted → Standby → Ready → Active, with Disabled as the permanent-leave state for that node account:

1. Whitelisted → Bonded, but required node keys have not yet been set.
2. Standby → Bonded but not active; current requirements are evaluated during churn. Only a Standby node outside vault migration may unbond.
3. Ready → Passed current preflight requirements and is eligible for churn selection. A Ready node cannot unbond.
4. Active → Participates in consensus, observation, and signing. An Active node cannot unbond; a LEAVE request marks it for churn-out handling.
5. Disabled → A Standby node that completed the permanent-leave path; it cannot rejoin with the same node account.

Slash Points and Forced Churn

Nodes accumulate slash points for failures such as missing observations, block signing, keygen, or keysign participation. MinSlashPointsForBadValidator is one churn-out input, alongside other current criteria; slash points do not prove immediate removal or bond-principal confiscation. See the Slashing deep dive for the full breakdown of slash point types, bond-principal slashing, and common misconceptions.

The combination of churning and economic penalties is intended to reduce long-lived validator and vault risk, but exact behavior should be checked against current protocol constants and Mimir state.

Vault Migration

Churn is also a vault-management event. When the active validator set changes, new vault keys can be created and assets may migrate from older vaults to newer vaults. Official technology docs describe vault migration as a multi-round process designed to maintain service availability during validator-set changes.

That makes churn relevant to users even if they never run a node: vault addresses, signing responsibility, outbound queues, and operational pause controls can all matter during sensitive migration windows. A churned-out node returning to Standby is still not automatically free to unbond while its key remains part of a migrating vault.

Current churn claims need Network diagnostics, THORNode node/churn state, current Mimir constants, the exact node lifecycle stage, and release-dated evidence. This design does not reveal the next rotation, current eligibility, migration completion, or chain-client readiness.

Delegated Node Operations (ADR-030)

ADR-030 is a proposed design for separating node management authority from bond custody. Under the proposal, an operator could register delegate addresses with permission bits for MAINT, LEAVE, bond-provider-whitelist changes, and operator-fee updates, each with an optional block-offset expiry. Custody of bonded RUNE and fee rewards would stay with the operator key, and OPERATOR_ROTATE, UNBOND, and delegation management would remain non-delegable.

That is design context only. The develop ADR is still marked Proposed; the official v3.20 blog recap says the framework ships in v3.20 code with activation expected in v3.21, so no delegate registry is active on mainnet yet. Node-lifecycle claims should keep using current THORNode state; do not describe delegated maintenance, leave requests, or fee changes as available behavior until activation lands.

Common Misreadings

• "Churn interval is always 2.5 days." Official docs currently describe the normal cadence as roughly 43,200 blocks, but ChurnInterval, HaltChurning, failed keygen, and migration state can change or delay what happens. Treat the quoted cadence as a documentation snapshot, not a next-churn promise.
• "Higher slash points = immediate churn out." Slash points are one churn-out input alongside leave requests, bans, age, bad performance, low version, and low bond. MinSlashPointsForBadValidator is a threshold, not an immediate-trigger guarantee; the exact selection set remains protocol-state dependent.