Automatic Failover from Long-Term Inactive Validators

Proposals
1

Per-Delegator Choice: Redelegate or Unstake (Testnet Development Approval)

TL;DR
Too much stake sits on inactive (jailed/tombstoned) validators earning 0% and weakening decentralization.
I’m proposing we develop and test on testnet an automatic failover system where every delegation must choose:

  • Auto-Redelegate (spread to low-power active validators; smallest get most), or
  • Auto-Unstake (start the normal 21-day unbond).
    Each delegator also sets a Jail Threshold (e.g., 7–90 days) for when the action triggers.

Why now?

  • Idle stake = 0% rewards and lower real security.
  • Abandoned wallets can trap stake for months/years.
  • This makes the set self-healing and nudges stake toward smaller, reliable validators.

What’s being proposed (for TESTNET first)

  1. Per-delegator settings (stored on-chain):
  • Failover Action (required): Redelegate or Unstake
  • Jail Threshold (required): N consecutive jailed days (between min/max set by governance)
  1. Trigger:
  • Tombstone: immediate failover
  • Jailed ≥ threshold: failover at next block
  1. Redelegate rule: pick K lowest-voting-power active validators that meet filters (uptime ≥ 99% over last 10k blocks; commission ≤ 10%; not recently slashed), allocate by inverse voting power (smallest receive proportionally more).
  2. Scope: This proposal authorizes design + testnet rollout only. Mainnet would require a separate upgrade vote after results.

Initial testnet parameters (tunable):

  • min_threshold_days = 7, max_threshold_days = 90
  • auto_failover_k = 4
  • auto_failover_min_uptime = 99%
  • auto_failover_max_commission = 10%

Benefits

  • No idle stake: every delegation either redelegates or unstakes after the chosen threshold.
  • Decentralization: flow toward smaller active validators.
  • User control: delegators choose both how and when.
  • Security: higher effective active stake.

Safeguards & anti-churn

  • Threshold floor/ceiling (e.g., 7–90 days) to avoid hyper-reactive churn.
  • K kept small (e.g., 4) to limit state bloat.
  • Per-block processing caps to handle very large validators safely.
  • Event logs so explorers/wallets show exactly what happened and why.

What this is not

  • Not an immediate mainnet change.
  • Not custody of user funds by a contract.
  • Not forcing everyone to redelegate—Unstake is equally available.

Open questions for feedback

  1. Preferred min/max for jail threshold? (e.g., 7–90 vs. 14–60)
  2. K destinations = 3, 4, or 5?
  3. Filters: uptime window (10k blocks OK?) and commission cap (10% OK?)
  4. Weighting: inverse voting power vs. simple cap-fill to median?
  5. Any exclusions (e.g., recent governance abuse) validators want considered?

Proposed timeline

  • Week 0–2: Community feedback on parameters & design
  • Week 3–6: Implement staking module changes, wallet/CLI hooks
  • Week 7–10: Public testnet: run scenarios (tombstone, long jail, mass failover)
  • Week 11–12: Publish report + recommended parameters
  • After: Separate mainnet software upgrade proposal if community is satisfied

Ask

Please share:

  • Whether you support testnet development of mandatory failover (choose Redelegate or Unstake)
  • Your preferred parameters (threshold range, K, filters, weighting)
  • Any red flags we should address before coding

If there’s broad support, I’ll open a PR draft and coordinate with wallet devs for a basic UI (dropdown for action + numeric threshold when staking).

Thanks for reading—looking forward to your feedback!

2 Likes
2

I see this is already in deposit stage. You will likely need to add the rest of the deposit, as the community might not see this as urgent/game changing proposal and add their own deposits. :+1:

3

Will do, once my pay check hits~ Haha

4

Why not just leave those “dead” delegations where they are? I don’t really see the downside of having locked stake on inactive validators. The real issue would be “dead” locked liquidity on active validators, since that stake still earns rewards but isn’t actually contributing.

5

Simple answer from me: Do NOT force-move ANY user tokens. So this would get a hard no from me.
There is no benefit to this.

6

User funds on-chain must remain sovereign to that user and should not be interfered with under any circumstances imho, so automatic redelegation is a ‘no’ from me.

However, I do see that it might be considered to be an improvement to the delegation system to automatically undelegate funds that are delegated to jailed validators after a certain amount of time (governance configurable) has passed since the jailing occurred. If a validator is tombstoned, automatic undelegation could be immediate since the validator cannot be recovered in that scenario.

1 Like
7

You say too much stake is sitting on inactive validators earning 0% rewards. But to be real honest with you: I quite like that.

It’s TVL for free. Oracle pool doesn’t pay a dime for these lockups. If we changed that we would be pretty dumb ass stupid, IMHO.