search

sherlock-audit / 2023-11-covalent-judging

3 stars 2 forks source link

aslanbek - Validators are incentivized to keep their validatorStake low to get more rewards #41

Closed sherlock-admin2 closed 7 months ago

sherlock-admin2 commented 7 months ago

aslanbek

medium

Validators are incentivized to keep their validatorStake low to get more rewards

Summary

maxCapMultiplier prevents delegators from staking more than 27x the validator's stake. Because validator's rewards are inversely proportional to totalStaked, validators are incentivized to keep their stake at validatorEnableMinStake, and stake the rest as a delegator, which would cut the staking cap for delegators in half, and increase the rewards for the validator by up to 100% as a consequence.

Vulnerability Detail

  1. An honest validator Alice stakes 350_000 CQT (her whole budget); her delegators stake (27)*350_000 CQT (highest limits at launch). When rewards are allocated, Alice will get:

1/28 * (rewards - validatorCommission) + validatorCommission

  1. Sophisticated validator Bob, with the same budget, instead stakes 175_000 CQT as a validator (==validatorEnableMinStake), and stakes the other 175_000 CQT from a different account as a delegator, so his delegators stake only (27-1)*175_000 CQT. When rewards are allocated, Bob will get:

2/28 * (rewards - validatorCommission) + validatorCommission

which is twice as much as Alice (neglecting the validator commission).

Moreover, Bob will be able to withdraw a half of his funds in 1 month (delegatorCoolDown), instead of 6 (validatorCoolDown).

Impact

  1. Sophisticated validators get up to twice as much rewards for the same stake.
  2. Non-validators staking cap is half as big in comparison to the "honest validator" scenario.
  3. Sophisticated validators are able to withdraw initialBalance - validatorEnableMinStake of CQT in 1 month instead of 6.

    Code Snippet

    https://github.com/sherlock-audit/2023-11-covalent/blob/main/cqt-staking/contracts/OperationalStaking.sol#L434

    Tool used

Manual Review

Recommendation

Introduce incentives for validators to keep their validator stake as high as possible.

sherlock-admin2 commented 7 months ago

1 comment(s) were left on this issue during the judging contest.

takarez commented:

invalid

sherlock-admin2 commented 7 months ago

PoC request not allowed.

nevillehuang commented 7 months ago

@noslav This seems to be highlighting a valid discrepancy in reward mechanism between validators and delegators

Is the following true?

Because validator's rewards are inversely proportional to totalStaked, validators are incentivized to keep their stake at validatorEnableMinStake, and stake the rest as a delegator, which would cut the staking cap for delegators in half, and increase the rewards for the validator by up to 100% as a consequence.

sudeepdino008 commented 7 months ago
  1. considering commission rate as 10% and rewards as r; the rewards in first case: (0.9/28+0.1)r and the rewards in the second case: (1.8/28+0.1)r; which is a ratio of 1.25
  2. there's lesser delegation room in the second case, which means in the competition for rewards among different validators, the second case earns Bob (+delegators under him) lesser reward pie compared to the first one. So the ratio will be lesser than 1.25. So the equation is more complicated for the validator.
  3. It is a PoA system and we monitor validators to operate properly. Furthermore we exercise caution in selecting values like maxCapMultiplier which can help avoid this issue.

The exploit vector is there, but is minimal/acceptable.

noslav commented 7 months ago
  1. considering commission rate as 10% and rewards as r; the rewards in first case: (0.9/28+0.1)r and the rewards in the second case: (1.8/28+0.1)r; which is a ratio of 1.25
  2. there's lesser delegation room in the second case, which means in the competition for rewards among different validators, the second case earns Bob (+delegators under him) lesser reward pie compared to the first one. So the ratio will be lesser than 1.25. So the equation is more complicated for the validator.
  3. It is a PoA system and we monitor validators to operate properly. Furthermore we exercise caution in selecting values like maxCapMultiplier which can help avoid this issue.

The exploit vector is there, but is minimal/acceptable.

This can be sufficiently mitigated by making sure the minimum stake required for a validator and the max stake required has a smaller diff while as @sudeepdino008 suggests keeping the maxCapMultiplier low. The underlying assumption is that the total pie of the rewards for an attested proof session is higher for the validator with a larger total stake with more delegations (so they are actually not incentivized to stake at a minimum - bring in more delegations by increasing your cap and get a larger chunk of the total fixed reward). How that reward is distributed among the participants or delegators is at the discretion of the delegators alone.