Users may avoid gauge loss penalty by frontrunning the LendingTerm notifying loss

[c4-bot-5]

Lines of code

https://github.com/code-423n4/2023-12-ethereumcreditguild/blob/2376d9af792584e3d15ec9c32578daa33bb56b43/src/loan/LendingTerm.sol#L725-L825
https://github.com/code-423n4/2023-12-ethereumcreditguild/blob/main/src/loan/LendingTerm.sol#L695-L722
https://github.com/code-423n4/2023-12-ethereumcreditguild/blob/main/src/governance/ProfitManager.sol#L292-L405

Vulnerability details

In case of LendingTerm.onBid(), or LendingTerm.forgive(), ProfitManager.notifyPnL() is called to signal loss. If the loss is signalled, any holder of losing gauge has to apply the loss. Currently, the loss may be very bad for the user, because all guild tokens voted on the gauge are burned with even slightest loss. Naturally, noone wants that happening to them, hence anyone can watch the mempool for transactions incurring losses and frontrun it, saving all their GUILD tokens.

Impact

Users are able to game gauge loss penalty by frontrunning the LendingTerm notifying loss.

Proof of Concept

1. Transaction signalling loss to the protocol is put into mempool.
2. User observes it and frontruns the transaction to withdraw their stake.
3. The user backruns the transaction and stakes again.
4. The user skipped the punishment completely.

Tools Used

Manual analysis

Recommended Mitigation Steps

Consider introducing lock time for gauge staking and unstaking.

Assessed type

Error

[c4-pre-sort]

0xSorryNotSorry marked the issue as sufficient quality report

[c4-pre-sort]

0xSorryNotSorry marked the issue as duplicate of #906

[c4-pre-sort]

0xSorryNotSorry marked the issue as duplicate of #877

[c4-judge]

Trumpero marked the issue as unsatisfactory:
Invalid

[c4-judge]

Trumpero marked the issue as unsatisfactory:
Invalid

[c4-judge]

Trumpero marked the issue as unsatisfactory:
Invalid