XDEFI contest - StErMi's results

Handle

StErMi

Vulnerability details

Impact

This does not exploit in any way funds/rewards but more how users could exploit this system to maximize rewards without being exposed to the lock period (or at least to the min lock period).

Because the system allows 0-time lock (you could be able to lock and unlock with any timelock but with a lower unit multiplier). In general, it all depends on how frequently the updateDistribution (I assume that it will be called after a reward transfer towards the staking contract) and if there are locking options with a timeframe lower updateDistribution timing.

In this scenario, a user would frontrun the transwer XDEFI reward amount + updateDistribution transaction, lock their tokens with 0 duration, and unlock it after the _pointsPerUnit has been updated by updateDistribution.

In this scenario, they are maximizing how much they can get from the rewards without exposing too much to the possible downside of locking (the value of XDEFI could crash).

In the case where there are no options to have 0 lock duration, the scenario could be still exploitable if the updateDistribution timing is known. If for example, you can lock at min for 1h and you know that transfer XDEFI reward amount + updateDistribution is called each day at 12 pm, I could lock it at 11 pm and unlock it at 12:01 pm.

Proof of Concept

Tools Used

Manual

Recommended Mitigation Steps

I don't have the perfect solution because I think that it's instinct with the design of the reward mechanism. Here's a list of possible options that I can suggest but needs to be validated.

• not allow having a 0 lock duration
• make the min lock duration defined in bonusMultiplierOf >= of transfer XDEFI reward amount + updateDistribution timing (if there's a timing to update the reward distribution)
• allow unlocking only after at least 1 updateDistribution since the lock period