For a user to receive rewards for supplying cNote in a lending market (LM), he only needs to have supplied the cNote at the end of an epoch.
Users staking for the whole duration of an epoch get 0 benefits, compared to users who supply only at the end of the epoch.
Therefore evRWA provides no incentive for users to supply cNote long-term in a specific LM.
Since there is no incentive to stick to one LM, this significantly reduces the incentive to lock cNote for evRWA - there is no need to vote for an LM because the user can choose the LM with the highest weight and redeem the rewards for it with 0 commitment.
This will create an unhealthy dynamic of reward-hunting without long-term commitment to the protocol.
Even if a LM provides good incentives for the user to keep tokens supplied, it is a reasonable assumption to make that protocols with even better incentives will exist.
I believe this to be a high issue because it can be detrimental to the success of the veRWA system.
In order to prevent the issue from manifesting, the protocol will have to rely on the LMs to over-incentivize or to enforce long minimum deposit durations.
No such requirements for the LMs have been described in the audit docs, which leads me to believe that no such requirements have been considered.
function sync_ledger(address _lender, int256 _delta) external {
address lendingMarket = msg.sender;
require(lendingMarketWhitelist[lendingMarket], "Market not whitelisted");
_checkpoint_lender(lendingMarket, _lender, type(uint256).max);
uint256 currEpoch = (block.timestamp / WEEK) * WEEK;
int256 updatedLenderBalance = int256(lendingMarketBalances[lendingMarket][_lender][currEpoch]) + _delta;
require(updatedLenderBalance >= 0, "Lender balance underflow"); // Sanity check performed here, but the market should ensure that this never happens
lendingMarketBalances[lendingMarket][_lender][currEpoch] = uint256(updatedLenderBalance);
_checkpoint_market(lendingMarket, type(uint256).max);
int256 updatedMarketBalance = int256(lendingMarketTotalBalance[lendingMarket][currEpoch]) + _delta;
require(updatedMarketBalance >= 0, "Market balance underflow"); // Sanity check performed here, but the market should ensure that this never happens
lendingMarketTotalBalance[lendingMarket][currEpoch] = uint256(updatedMarketBalance);
}
Manual review
To encourage supplying tokens over the whole duration of an epoch, changes to the reward calculation mechanism can be made.
An alternative would be to enforce a rule for minimum LM deposit duration of 1 Epoch in order to be whitelisted. But this might not be viable due to the varying natures of the different lending markets.
Protocol changes could look like:
Instead of using the absolute balance of the user to calculate rewards, the protocol can use a linearly increasing average balance.
This can be employed with simple math as in Example_1 or by using the already familiar slope of a line (increasing).
Example_1:
epoch = 100 seconds
Starting totalSupply = 1000 tokens
Alice average supply is 95/100_10 + 5/100_1010 = 9.5 + 50.5 = 60 tokens
Average total supply = 1010_95/100 + 2010_5/100 = 959.5 + 100.5 = 1060 tokens
Aliceβs share = 60/1060 tokens = 5.66&
Example_2:
epoch = 100 seconds
Starting totalSupply = 1000 tokens
Context
The text was updated successfully, but these errors were encountered:
All reactions