60429 sc high double decrease of effective stake prevents delegators from unstaking

Submitted on Nov 22nd 2025 at 14:34:56 UTC by @Dliteofficial for Audit Comp | Vechain | Stargate Hayabusaarrow-up-right

  • Report ID: #60429

  • Report Type: Smart Contract

  • Report severity: High

  • Target: https://github.com/immunefi-team/audit-comp-vechain-stargate-hayabusa/tree/main/packages/contracts/contracts/Stargate.sol

  • Impacts:

    • Permanent freezing of funds

Description

Brief/Intro

A critical accounting error in the unstake() function causes the validator's total effective stake to be decreased twice when a user requests delegation exit while their delegation is ACTIVE, waits for the delegation to become EXITED, and then unstakes after the validator has exited. The double-decrease occurs because unstake() checks if the validator is EXITED but fails to verify whether the effective stake was already decreased during the exit request. This results in incorrect accounting of the validator's total delegation effective stake, which can prevent the last remaining delegators from successfully unstaking their tokens, effectively causing a denial-of-service condition that locks their funds.

Vulnerability Details

The Stargate protocol uses an effective stake tracking system to calculate reward distributions among delegators. Effective stake is managed through checkpoint-based storage (delegatorsEffectiveStake) that tracks changes at specific periods. When delegators exit or unstake, their effective stake must be properly decreased to maintain accurate accounting.

The vulnerability stems from the interaction between two functions: requestDelegationExit() and unstake(). Both functions decrease the validator's effective stake, but under certain conditions, both decreases can occur even though only one is warranted.

When a user calls requestDelegationExit() while their delegation status is ACTIVE, the function performs the following operations:

The _updatePeriodEffectiveStake() function uses upperLookup() to retrieve the current effective stake value for the specified period and then decreases it:

After the exit request, the delegation remains ACTIVE until endPeriod is reached (when currentValidatorPeriod > endPeriod), at which point the delegation status becomes EXITED. If the validator also exits during this time, the validator status becomes EXITED.

When the user subsequently calls unstake(), the function checks if the validator is EXITED and decreases the effective stake again:

The check currentValidatorStatus == VALIDATOR_STATUS_EXITED does not verify whether the effective stake was already decreased during requestDelegationExit(). Since _updatePeriodEffectiveStake() uses upperLookup() which retrieves the already-decreased value from the checkpoint system, subtracting the effective stake again results in a double-decrease.

Impact Details

The vulnerability has multiple severe consequences:

Primary Impact: Denial of Service for Last Remaining Delegators

The most critical impact occurs when multiple users delegate to the same validator. When the first user(s) exploit this vulnerability by requesting exit while ACTIVE and then unstaking after the validator exits, the validator's total effective stake becomes incorrectly reduced. As subsequent users unstake, the accounting error accumulates. The last remaining delegator(s) may find that the validator's total effective stake has been reduced below their own effective stake, causing their unstake operation to fail or encounter underflow errors. This effectively locks their funds in the protocol with no way to recover them.

Secondary Impact: Incorrect Reward Distribution

The double-decrease of effective stake causes the validator's total delegation effective stake to be lower than it should be. This affects reward distribution calculations, as rewards are distributed proportionally based on each delegator's effective stake relative to the total. The incorrect total leads to inaccurate reward calculations for all remaining delegators.

Tertiary Impact: Protocol Accounting Corruption

The checkpoint system's integrity is compromised, as the effective stake values stored do not reflect the actual state. This corruption persists and affects all future operations that rely on accurate effective stake tracking, potentially causing cascading accounting errors throughout the protocol.

https://gist.github.com/Dliteofficial/336c5d14121945cb74deae3af287cc54

Proof of Concept

Proof of Concept

Was this helpful?