Unable to clear expired power that has already been used for free.

[hats-bug-reporter[bot]]

Github username: -- Twitter username: -- Submission hash (on-chain): 0xbeb4a0ecba733f733ff048f2b43cb4c12355e39f4290a20399985fadc3c46e20 Severity: medium

Description: Description\ Some of the user's votes are for proxied voters, while there are also available free votes that the user can utilize. All votes have expiration dates. If the user wishes to clear expired free votes, there is a unique method to cast 0 free votes to that gauge. This affects future voting.

Attack Scenario\ Suppose User A has 20% of their votes as free votes, while the remaining 80% are for proxied voters.

• User A casts 10% of his free votes to Gauge G1 and another 10% to Gauge G2. These votes expire at the lock end time of this user.

  function _voteForGauge(address user, address gauge, uint256 userPower, address caller) internal {
  vars.userLockEnd = IHolyPalPower(hPalPower).locked__end(user);
  
  VotedSlope memory newSlope = VotedSlope({
          slope: (convertInt128ToUint128(vars.userSlope) * userPower) / MAX_BPS,
          power: userPower,
          end: vars.userLockEnd,   // ===> @audit here
          caller: caller
      });
  }

• User A may increase lock time or lock new tokens after the expiry.
• Even though the already used free votes have expired, the usedFreePower of User A remains at 20%. If the proxied votes are allowed for a longer period, User A may no longer be able to cast free votes.
• To cast free votes for Gauge G3, User A must clear the expired free votes associated with G1 or G2. The only way is to cast 0 free votes for those gauges.

  function _voteForGauge(address user, address gauge, uint256 userPower, address caller) internal { 
  if(user == caller) {
          uint256 usedPower = usedFreePower[user];
          vars.oldUsedPower = oldSlope.caller != user ? 0 : oldSlope.power;   // => @audit 
          usedPower = usedPower + newSlope.power - vars.oldUsedPower;  // ==> @audit, we remove the used free power
          if(usedPower > (MAX_BPS - blockedProxyPower[user])) revert Errors.VotingPowerExceeded();
          usedFreePower[user] = usedPower;
      }
  }

• The issue is that this action is also considered as votes, and the lastUserVote is updated accordingly. Consequently, users cannot cast votes to these gauges for 10 days (VOTE_COOLDOWN).

  function _voteForGauge(address user, address gauge, uint256 userPower, address caller) internal {
  if(block.timestamp < lastUserVote[user][gauge] + VOTE_COOLDOWN) 
  revert Errors.VotingCooldown();   // ==> @audit, here
  }

  1. Proof of Concept (PoC) File

2. Revised Code File (Optional)

   Add a function to clear expired free votes.

   function clearExpiredUsedFreePower(address user, address gauge)  external {
       VotedSlope memory oldSlope = voteUserSlopes[user][gauge];
   
       if (oldSlope.caller == user && oldSlope.end < block.timestamp) {
           usedFreePower[user] -= oldSlope.power;
           delete voteUserSlopes[user][gauge];
       }
   }

[Kogaroshi]

I think this is invalid, as you only think that to replace a vote a new vote with userPower == 0 is needed. But the user, once the lock is expired, and the cooldown to vote for that gauge is through, the user can vote with a new userPower (lower than the one there is to free a part of the votes if needed, and higher if the user has free voting power available too). The internal calculations will account for the votes being expired, and now to 0, but in practice the usedPower is still 20%, simply 20% of 0 is 0.

[GTH1235]

@Kogaroshi , Thanks for your comment.

Let me try to break down the example.

• User A has 20% free power, while the remaining 80% are blocked for their proxied voters. Proxied voters are allowed for a long period.
• User A casts 20% to the Gauge G1, which expires approximately one month later. It is always possible to increase the lock time at any time. The new expiry date is set to 6 months.
• After one month, User A wants to cast all free votes to Gauge G2. At this point, usedFreePower is still 20%, and 80% are reserved for proxied voters. To cast 20% free votes to G2, User A should clear the expired free votes. These 20% free votes have already expired and did not contribute to the weight of G1.
• Unique approach to achieve this is by casting a vote to G1 with 0 free power, effectively clearing the expired power. After that, User A can cast free votes to G2. (Of course, any of the proxied voters can assist by casting some votes, but this falls under outer functionality)
• However, after this action, none of the users, including User A and proxied voters, can cast votes to G1 for 10 days.

If the user decides not to cast free votes to G1, does that mean that none of the proxied voters will cast votes for 10 days?

I think the suggested solution is straightforward and easy to implement.

Further comments would be greatly appreciated.

[Kogaroshi]

The reason I said I thought it was invalid is because the scenario you described is normal. Even in the case no votes expire, the proxies can't vote on gauges the user voted for, which is indeed makes the flow for votes a bit harder to manage for the users and their proxie(s), but also required so the proxy system is not bypassed (by having the user remove proxy casted votes, or offering a possibility to override the cooldown that could then be used to bypass it when it should not be).

[GTH1235]

Using the suggested solution helps us avoid an undesired situation. By clearing the expired free votes instead of casting votes to G1, we can freely utilize the cleared free power for G2, and proxied voters can still vote for G1 as their choice. I believe this can be marked as at least low priority, but I will respect your decision.

Thanks, @Kogaroshi

[Kogaroshi]

I understood the solution you proposed, but it also introduces a system where users make the lowest duration of locks, and use the new system for reset their votes for free, without any consideration for the cooldown, for them (or their proxie(s) to cast any desired votes without caring about the flow all other users that Lock long time and change their votes when they need go through. Imo that introduces an unfair system, that will also incentivize to make small duration locks rather than long term locks, which means create unfairness towards less-aligned users in the system, which does not make sense to us in the context of tokenomics.

[GTH1235]

What about this? Of course, I also agree that we should not permit clearing previous free votes before the cooldown time, even though those votes have already expired.

function clearExpiredUsedFreePower(address user, address gauge)  external {
        VotedSlope memory oldSlope = voteUserSlopes[user][gauge];

        if (oldSlope.caller == user && oldSlope.end < block.timestamp && block.timestamp >= lastUserVote[user][gauge] + VOTE_COOLDOWN) {
            usedFreePower[user] -= oldSlope.power;
            delete voteUserSlopes[user][gauge];
        }
}

[Kogaroshi]

Even for proxy votes, it stays the same flaw, as I can just proxy all my vote to my 2nd address for the whole duration of my small locks, and use that feature to bypass the cooldown.

[GTH1235]

Seems like I am misunderstanding your point.

Let me think more.