Cluster Lifecycle

Every account in the Yellow Network is managed by two concentric rings of nodes in the DHT: a Signing Cluster for fast transaction processing, and a larger Replication Set for independent state verification.

Cluster Formation

Signing Cluster (C_sign)

The signing cluster for an account is the set of k nodes closest to the account's key in XOR space:

C_sign = FindClosest(AccountID, k)

These nodes are responsible for:

• Processing transactions (transfers, swaps, withdrawals)
• Producing BLS threshold signatures (quorum: t = floor(2k/3) + 1)
• Broadcasting state updates to the replication set

The value of k is dynamic — it scales with the value held in the account. See Elastic Security for the sizing formula.

Replication Set (C_watch)

The replication set is a strictly larger ring of nodes around the same account:

C_watch = FindClosest(AccountID, r)
    where r = max(r_min, k × f_r)

Since FindClosest returns nodes by XOR distance, the signing cluster is always a subset of the replication set — the k signing nodes are the innermost k of the r replication nodes.

Parameter	Value	Description
r_min	12	Minimum replication set size, even for low-value accounts
f_r	4	Default replication factor — a k=5 signing cluster has r=20 watchers
max	256	Both k and r are bounded by 256 NodeIDs

State Replication Protocol

After every epoch, the signing cluster broadcasts state updates to the full replication set:

1. Broadcast — C_sign sends the set of Certificates produced during the epoch and the resulting state changes to all C_watch nodes.
2. Verify — Each watcher verifies every Certificate's BLS threshold signature against the Registry's public keys. This is read-only — the watcher confirms signatures are valid and state changes are consistent.
3. Apply — If verification passes, the watcher applies the state changes to its local replica.
4. Divergence — If a Certificate's signature is invalid or state changes are inconsistent, the watcher flags a protocol violation.

C_watch nodes do not participate in the signing hot path. Their replicated state trails C_sign by at most one epoch — acceptable because the replication set is only activated during the withdrawal challenge window.

Time Windows

Node lifecycle is governed by four protocol time windows that ensure temporal consistency for cluster membership and certificate verification.

Window	Duration	Purpose
CERT_LIFETIME	25 minutes	Maximum validity of any certificate. A certificate not consumed within this period MUST be discarded. Enforced on-chain for both startWithdrawal and disputeWithdrawal.
WARMUP_WINDOW	1 hour	After registration, a node syncs state from existing cluster members before becoming eligible to sign or watch.
COOLDOWN_WINDOW	1 hour	After unregistration, a node stops signing new certificates. Any certificate signed before departure expires within this window.
EVICTION_WINDOW	7 days	After cooldown, the node remains in the Kademlia tree solely for on-chain verification consistency. Once elapsed, the node may be removed.

Critical Invariant

The time windows are designed to satisfy a strict ordering:

SubmissionRounds < CERT_LIFETIME < COOLDOWN < COOLDOWN + EVICTION
        24 min  <     25 min     <  1 hour  <    7 days + 1 hour

Each inequality serves a security purpose:

1. 24 min < 25 min — All round-robin submission attempts complete before the certificate expires.
2. 25 min < 1 hour — Any certificate produced by a departing node expires before its cooldown completes. The node remains in FindClosest results for the entire validity period of every certificate it signed.
3. 1 hour < 7 days + 1 hour — The node stays in the Kademlia tree long enough for any pending on-chain challenge period to elapse with stable cluster membership.

Node Join (Registration)

On registration, a node is inserted into the Kademlia tree but enters a warmup period:

1. The node syncs state from floor(2k/3) + 1 existing cluster members via a Merkle-verified state snapshot covering all account ledger codes.
2. The node MUST NOT participate in signing ceremonies during warmup.
3. The node MAY appear in FindClosest results, but its bitmask bit MUST be 0 (unsigned).
4. Dual enforcement — On-chain, aggregateSignerPubkeys rejects any signer where block.timestamp < registeredAt + WARMUP_WINDOW.

Node Leave (Graceful Departure)

On unregistration, a node MUST NOT sign any new certificates. However:

1. The node remains in the Kademlia tree — it is NOT removed from FindClosest results.
2. Any certificate the node previously signed remains verifiable on-chain against the same cluster membership until it expires.
3. After both the cooldown and eviction windows have elapsed, any party MAY trigger removal of the node from the tree.
4. Collateral remains in the Custody contract and must be reclaimed via the standard Escrow Certificate withdrawal flow.

Signing Cutoff Rule

The protocol MUST NOT include a node in new signing ceremonies if the remaining time before its cooldown ends is less than CERT_LIFETIME. This guarantees that any newly signed certificate will expire before the node's cooldown completes.

Crash and Timeout

• If a node misses heartbeats for 3 consecutive epochs, it is temporarily disabled (bitmask bit set to 0).
• If the node remains offline for 30 epochs, the cluster replaces it with the nearest available NodeID.

Fee Distribution

C_watch nodes outside C_sign are incentivized through fee sharing:

Recipient	Share	Description
C_sign validators	80%	Distributed equally among the k signing validators
C_watch \ C_sign validators	20%	Distributed equally among the r - k replication-only validators

On a successful dispute, 25% of total slashed collateral is distributed equally among all C_watch validators whose bit is set in the Dispute Certificate's bitmask. The remaining 75% is allocated to the protocol treasury.