Lines of code

Vulnerability details

Mitigation of M-05: Issue NOT mitigated

Mitigated issue

M-05: Reward sandwiching in VotiumStrategy

The issue was that exposure to the benefits of the VotiumStrategy might be unfairly time-weighted.
There were two aspects mentioned: voting power and rewards. I do not think being able to get voting power without the usual 16 week commitment is an issue as this is equivalent to just temporarily lending tokens, which is made possible by CVX itself. The rewards aspect is that VotiumStrategy distributes rewards based only on shares owned at the moment of rewards distribution, such that an instant of exposure can claim the same share of rewards as a prolonged exposure, which is unfair towards other users.

Mitigation review

VotiumStrategy might have some funds available for immediate withdrawal. Previously, an attacker could in this case deposit and immediately withdraw up to this amount of funds at the same instant as rewards are distributed. The mitigation attempts to prevent this by making withdrawal requests finalizable at first in the next epoch. This does not fully resolve the issue. It only implies that the exposure time required is increased from an instant to at least one block but less than an epoch. This may still be unfairly time-weighted.

Recommended correction

A particular reward is intended to reward exposure during some specific time interval. So to fully resolve this issue we should only distribute that reward in proportion to exposure time within that time interval. I don’t now how the CVX rewards scheduling work, but it seems fair to assume that rewards are neither paid in advance nor delayed, in the sense that in the limit of continuity the reward rate at time $t$ is intended for exposure at time $t$. In the discrete this should be interpreted as follows: suppose a reward $r_1$ is made available at time $t_1$ and that the next reward, $r_2$, is made available at time $t_2$, then $r_2$ is intended for an exposure during $[t_1, t_2]$.
As long as Asymmetry whenever it distributes rewards always distributes all rewards available, the same holds for Asymmetry’s reward distribution (otherwise a delay is implied).

Note here that adding time between withdrawal request and finalization is not the same as adding time between deposit and withdrawal request. The amount to be paid is set on the time of the withdrawal request, so this forces exposure only for a certain amount of time, but not the time interval for which the reward is intended. For example, if the withdrawal request is placed at $t_2$ and can then be finalized at $t_3$, then $r_2$ can be obtained by exposure to $[t_2, t_3]$ rather than $[t_1, _2]$.

If rewards are distributed irregularly in time, I think the only way to completely resolve this issue would be to distribute rewards according to the exact time exposed, which is complicated.

So rewards should be distributed regularly, e.g. at the start/end of each epoch.

Ideally a first possible withdrawal request time should be set on deposit, otherwise the required exposure time interval is shifted from before withdrawal request to after withdrawal request. However, if the rewards are distributed sufficiently often and are sufficiently even in value this should hardly matter. Also, storing the deposit time for each deposit implies a significant overhead.

In any case, the minimum time commitment must be at least the period of rewards distributions.

So I recommend that rewards be distributed regularly, let’s say at the start/end of each epoch. And that on requestWithdraw() a minimum delay of this period be enforced, in this case at least one epoch. This means that currentEpoch + 2 must be used rather than currentEpoch + 1. The minimum of currentEpoch + 2 must also be enforced in the case where funds are not immediately available, in which case they may become available the next epoch (which may be a single block away).
However, do note that this assumes rewards are fairly even in value, as otherwise one can decide to enter just before a massive reward distribution.

---

The text was updated successfully, but these errors were encountered:

All reactions