Claiming in a lump sum within the lending market can cause loyal lenders' income to be diluted at the last second of an epoch. This issue disincentivizes lenders from staying invested in the lending market for the entire epoch, or even longer. Malicious actors can exploit this vulnerability by entering the market at the last moment, claiming rewards disproportionately, and then swiftly moving their liquidity to another platform. This practice leads to the unfair distribution of rewards and undermines the attractiveness and fairness of the lending platform.
Proof of Concept
// Findings are labeled with '<= FOUND'
// File: src/LendingLedger.sol
152: function claim(
153: ...
174: cantoToSend += (marketWeight * userBalance * ri.amount) / (1e18 * marketBalance); // <= FOUND: Lender's latest rewards can be diluted by late comer
179: ...
182: }
Line 174 shows that a userBalance recorded in the last second of the epoch is the same as one recorded from the epoch begin. This leads to the same cantoToSend amount to claim.
Below is the exploit scenario:
Alice, a lender, supplies 1e18 underlying tokens to the lending market.
The system takes a snapshot into the LendingLedger, recording Alice's userBalance and marketBalance as 1e18 each.
At timestamp currEpoch + WEEK - 1, Bob joins the market by depositing 10e18 tokens.
The system syncs the ledger for the current epoch, considering Alice's and Bob's balances and updating the userBalance and marketBalance.
After 1 second, a new epoch begins, and the rewards from the previous epoch are distributed.
Due to Bob's late entry, his rewards are disproportionately high, as his userBalance contribution of 10e18 tokens significantly impacts the rewards allocation.
Bob claims rewards worth 10e18/11e18 of the CANTO allocated for the market, diluting the rewards that loyal lenders like Alice should have received.
Tools Used
Manual Review
Recommended Mitigation Steps
Implement a more equitable rewards distribution mechanism. The Ledger should track the timestamp when a user joins the market, and the sync_ledger function should use this timestamp to gradually increase the eligible balance for rewards allocation. This increase should follow a slope of _delta / WEEK to ensure that latecomers' rewards are proportionate to their contributions and that loyal lenders' rewards are not unfairly diluted.
_________ ________
| /
| /
_____| ___ /
S,M epoch S M (M - S = 1 WEEK)
Lines of code
https://github.com/code-423n4/2023-08-verwa/blob/main/src/LendingLedger.sol#L174
Vulnerability details
Impact
Claiming in a lump sum within the lending market can cause loyal lenders' income to be diluted at the last second of an epoch. This issue disincentivizes lenders from staying invested in the lending market for the entire epoch, or even longer. Malicious actors can exploit this vulnerability by entering the market at the last moment, claiming rewards disproportionately, and then swiftly moving their liquidity to another platform. This practice leads to the unfair distribution of rewards and undermines the attractiveness and fairness of the lending platform.
Proof of Concept
Line 174 shows that a
userBalance
recorded in the last second of the epoch is the same as one recorded from the epoch begin. This leads to the samecantoToSend
amount to claim.Below is the exploit scenario:
userBalance
andmarketBalance
as 1e18 each.currEpoch + WEEK - 1
, Bob joins the market by depositing 10e18 tokens.userBalance
andmarketBalance
.userBalance
contribution of 10e18 tokens significantly impacts the rewards allocation.Tools Used
Manual Review
Recommended Mitigation Steps
Implement a more equitable rewards distribution mechanism. The Ledger should track the timestamp when a user joins the market, and the
sync_ledger
function should use this timestamp to gradually increase the eligible balance for rewards allocation. This increase should follow a slope of_delta / WEEK
to ensure that latecomers' rewards are proportionate to their contributions and that loyal lenders' rewards are not unfairly diluted.S: sync_ledger timestamp M: balance mature timestamp
Assessed type
MEV