bughuntoor - If the multiple calls to `writeStakingRewards` cross a week's end, it will result in unfair distribution of rewards about 2023-11-convergence-judging

[IAm0x52]

Escalate.

This should be a dupe of #178, since it is the same root cause of CVG cycles length drift.

It also requires that at least 7 days has passed since this update to roll the cycle forward in [L205](https://github.com/sherlock-audit/2023-11-convergence/blob/main/sherlock-cvg/contracts/Rewards/CvgRewards.sol#L205). The result is that the cycle can never be exactly 7 days long and the start/end of the cycle will constantly fluctuate.

#178 (quoted above) describes the result of these longer cycles on LockingPositionService and this issue outlines the impact it has on gauge rewards.

Note: since the requirement on calling checkpoint is that at least 7 days have passed since the last distribution, it would mean that the delta of the checkpoint and the end of the week will gradually decrease every week

This issue describes the exact same root cause behavior of cycles that are too long. Ultimately the root issue is the same and these should be considered dupes.

[walk-on-me]

Hello,

Thanks a lot for your attention.

After a deep review of the issues, we have to consider all of your issues as valid.

We indeed noticed that if we don't synchronize our CvgCycle with the WEEKS, we could have some issues of desynchronization in the long term if the CVG cycle is not triggered immediatly after 1 week.

For example :

• #10 && #193, mention that if the distribution of $CVG occurs just before a WEEK and finished just after, some gauges will have less CVG distributed.
• #14, mention that some user can get some free mgCVG for 1 WEEK less than other users
• #101, mention that in the last cycle of a lock, an user cannot extend his lock during the time between the last WEEK and the nextCvgCycle.
• #136 && #215, mention that in the last cycle of a lock, an user is locked for 1 more cycle than he planned
• #178 , mention that extending a lock can be impossible
• #59 , mention that during the mint of a position, the lock is done for one extra cycle on the veCVG

We are going to implement the solution for all of these issues that is to round our CVGCycle on the WEEK like veCVG is doing.
Regards,
Convergence Team

[sherlock-admin2]

Escalate.

This should be a dupe of #178, since it is the same root cause of CVG cycles length drift.

It also requires that at least 7 days has passed since this update to roll the cycle forward in [L205](https://github.com/sherlock-audit/2023-11-convergence/blob/main/sherlock-cvg/contracts/Rewards/CvgRewards.sol#L205). The result is that the cycle can never be exactly 7 days long and the start/end of the cycle will constantly fluctuate.

#178 (quoted above) describes the result of these longer cycles on LockingPositionService and this issue outlines the impact it has on gauge rewards.

Note: since the requirement on calling checkpoint is that at least 7 days have passed since the last distribution, it would mean that the delta of the checkpoint and the end of the week will gradually decrease every week

This issue describes the exact same root cause behavior of cycles that are too long. Ultimately the root issue is the same and these should be considered dupes.

You've created a valid escalation!

To remove the escalation from consideration: Delete your comment.

You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.

[nevillehuang]

@IAm0x52 agree, should be duplicate of #178, given also, the fix implemented for all this issues are the same indicated by sponsor.

[10xhash]

there are scenarios possible where even if week/cvgCycle is synced the rewards distribution issue can occur although at low likelihood ( see #193 )

[Czar102]

Planning to make it a duplicate according to the escalation.

[Czar102]

Result:
Medium
Duplicate of #178

[sherlock-admin2]

Escalations have been resolved successfully!

Escalation status:

• IAm0x52: accepted

[IAm0x52]

Same root cause and fix as #178