ARC-0049 - Introduce Redelegation and Extend Unbonding Time

[raychu86]

arc: 0049
title: Introduce Redelegation and Extend Unbonding Time
authors: @raychu86
topic: Protocol
status: Draft

Abstract

This ARC proposes two coordinated staking mechanism updates:

• Increase the unbonding period from 360 blocks to 403,200 blocks (1120 epochs or ~14 days).
• Introduce a new redelegation function to credits.aleo, which allows delegators to instantly reassign stake from one validator to another without passing through a full unbonding period. This function is subject to a 403,200 block cooldown between uses.

Motivation

The current unbonding period of 360 blocks provides limited economic finality and relatively weak protection against short-term stake volatility or coordinated validator behavior. As the network matures and total economic value increases, stronger alignment between validator accountability and stake lock duration becomes increasingly important.

Key concerns under the current model include:

• Short withdrawal window, reducing economic security
• Rapid stake mobility, enabling opportunistic validator hopping
• Limited penalty horizon, constraining deterrence for malicious behavior

Extending the unbonding period to ~21 days strengthens:

• Economic security guarantees
• Validator accountability
• Network stability during volatility

However, increasing lock duration introduces capital inefficiency for honest delegators who wish to move stake between validators.

To address this, this ARC introduces a new instant delegation reassignment mechanism that:

• Preserves stake continuity (never leaving bonded state)
• Enables immediate validator switching
• Applies a 21-day cooldown to prevent abuse

Specification

Unbonding Period Extension

The protocol will increase the unbonding period from:

360 blocks to 403,200 blocks (~14 days).

This applies to:

• Delegator-initiated unbonding
• Validator self-unbonding
• Any staking position exiting the bonded state

After submitting an unbond request, stake remains locked and subject to protocol rules until the full 403,200 block period elapses.

This is done by changing one finalize command in credits.aleo/unbond_public:

    // Set the default unbonding state.
    add block.height 360u32 into r3;

Becomes

    // Set the default unbonding state.
    add block.height 403200u32 into r3;

Note that the circuit and VK are unchanged because only the finalize scope is changed.

Instant Delegation Reassignment

This ARC introduces a new staking function to credits.aleo that allows a delegator to immediately reassign stake from one validator to another without entering the unbonding state: redelegate().

Stake is immediately redelegated from the old validator to the new validator. The stake remains bonded at all times and no unbonding delay is triggered. However, a redelegation cooldown period begins for the delegator.

Inputs:

• New validator address

Requirements:

• Called by the original delegator
• Old validator address and new validator address must be different
• New validator address is open to new delegations
• The delegator has not already redelegated within the cooldown period
• Withdrawal address is not changed

Cooldown Mechanism

After using redelegate(), the delegator must wait 403,200 blocks before it is able to call redelegate() again.

The cooldown duration matches the unbonding period for symmetry and predictability.

Reference Implementation

aleo-labs-protocol/snarkVM#3228

Backwards Compatibility

This ARC changes credits.aleo with new finalize-only changes to credits.aleo/unbond_public and a new redelegate function. This will require a Stack swap at a new ConsensusVersion to allow support for the feature after a certain block height.

[mwyatt896]

Quick thoughts on first read through:

1. This proposal creates duration risk now for anyone staking -- market swings for any various reasons now expose stakers and provers as a result.

2. I believe this proposal is a good forcing function to commit others on the network to strengthen their commitment as a result of the duration risk. It also creates surface area for builders to innovate and bring products to market that absorb some of this newfound duration risk which is good for the network as well.

3. It would be great to have some numbers/heuristics behind the key concerns as a best practice so we can go to market with these changes instead of a hand-wavy "this strengthens the network". The concerns for this are listed are:
   "Short withdrawal window, reducing economic security" --> what does this mean quantifiably? Has this had any occurances in practice today for Aleo or other chains?
   "Rapid stake mobility, enabling opportunistic validator hopping" --> why does this matter quantifiably? I believe the redelegate function actually continues to enable this if its a concern. For Aleo users -- I imagine this is actually nice. For Aleo the network -- I imagine the worst scenario is opportunistic validator hopping to other ecosystems (ie capital/stake flight). Do we see any concerns for this in practice today for Aleo or other chains? I'm confident we have on other chains (and uncertain on case with Aleo) but nonetheless -- clarity and heuristics to cite/justify would be good.
   "Limited penalty horizon, constraining deterrence for malicious behavior" --> again, why does this matter quantifiably.

Just as a quick example of what I'm thinking --> we just witnessed the LZ-KelpDAO-Aave hack cause a capital flight exodus of >$10B out of the crypto economy and the ETH. The idea of stake in a network is that you have shared incentives in the network to keep it live and useful and fix any issues as they occur. Proof of stake limits the shared incentive in the network to keep it live when that stake is not truly at risk. With short exit windows, you can't stomach volatility and network resilience is low as outlined here: https://www.blockdaemon.com/blog/ethereum-exit-queue-surge-network-resilience-and-stakeholder-implications?utm_source=chatgpt.com

Would be helpful to have something like this for GTM -- but lgtm on surface!

[riquelima805]

I like the redelegate function. I think the 14-day period is valid for nodes—or even longer, as seen in other networks and LSDs could be used to mitigate this wait time for users. That way, we wouldn't have to wait 14 days.