ARC: Extend AAVE Liquidity Mining Rewards

i don’t agree that is a failure of governance, the community needs to take responsibility when discussing a topic, @Anjan-ParaFi did in this case but others could have done earlier, everybody knew the 3 months period was ending. Agree though that this topic should be discussed more thoroughly. I’m fully in support of avoiding a collapse of the fundamental market metrics (TVL and outstanding debt) at this moment of market turmoil. The proposal needs to be put on chain though, so if others community members don’t agree they can always vote against


This is Ratan, President of Blockchain at Berkeley.

Very insightful to see the discussion in the community here - we agree with @Anjan-ParaFi in that we don’t see any significant drawbacks in extending the program by a month so the community can come to a consensus. Overall, we’re supportive of extending the LM program in a way that incentivizes more liquidity and usage to come into the ecosystem, as we’re still at a very early point in Aave’s potential growth. As @ChainLinkGod has mentioned, we need to enable Aave to remain competitive to LPs and we see LM as the most effective way to do so.


I believe it’d be great to all agree on defining the safety ratio to maintain. Is it 16%? Is it 35%?
This will help us make accurate decisions for the next steps.


I personally don’t think it’s necessarily healthy to put much weight on the safety module ratio, largely because the safety module is for the most part comprised of AAVE tokens. AAVE correlates highly with its popular collateral assets, and correlates weakly with its popular debt assets. This is very bad in the case of a shortfall event which would dilute the safety module to unpredictable levels. This correlation also spills over into the relationship between AAVE and the safety ratio, which means that this ratio can fluctuate as meaninglessly as bitcoin.

And so I argue that the safety module TVL should not be viewed as a measure of security of the protocol. Rather, it should be viewed as a measure of confidence in the protocol, and a penalty mechanism for irresponsible governance. Because TVL simply fails as a metric for the ability of AAVE to cover a shortfall event.

I think a good start to protecting AAVE from shortfall events was the collection of a portion of reserve interest for the treasury, but this isn’t formally incorporated into the risk framework of AAVE. Another option is to simply outsource the risk to another protocol so that the focus of governance can be narrowed and AAVE can have the cost of their risk quantified by a third party. Of course, the safest and most capital efficient option is to simply set parameters to never suffer a serious shortfall event though. Which is all to say, I don’t think maintaining the safety module ratio should get in the way of a liquidity mining proposal.

What I wanted to stress out is that ratio lowered by a factor of 3 to 4x from almost 60% pre-LM to roughly 15% nowadays.

I’m not an actuary, but I’m already uncomfortable at 15%: it means that if we suffer a critical issue affecting more than 15% of the total borrow, the Safety Module budget will be insufficient to compensate for the loss — and we’re not even accounting for the massive and to be expected drop in price in AAVE token if that happened.

We need indeed more diversification of assets in the safety module but that’s another discussion.

Regarding the liquidity mining proposal, I’m finalizing a new proposal including several adjustments to make sure the LM plan is sustainable and synergistic with Aave’s best long term interest. I hope it will provide a better base for the discussion, and incorporates most of the most recurring feedback shared here. I’ll share as soon as possible, probably early next week.

@TokenBrice i don’t think we should stress about the ratio safety capital/outstanding debt, if the protocol grows organically (even without liquidity mining) that ratio is gonna shrink no matter what. Outstanding debt is always an excellent metric for the protocol, in terms of income generated and usage, therefore we should always aim to maximize it

1 Like

Your point is correct, indeed the coverage ratio of the safety module will shrink as outstanding debt grows if no additional deposits are made.

Yet I would contest the second part:

Outstanding debt is always an excellent metric for the protocol

Yet, using outstanding debt as a metric lead us for instance to regard single-asset-based recursive borrow-deposit loops as positive for the protocol, are they really?

So far, Aave is the only major money market that has not suffered a critical failure resulting in loss of funds for users. I’d like it to stay as such, and even better — unlike other money markets — be safe enough that we could reimburse affected users if a loss-of-funds event was to occur.

I believe it’s critical to keep growing Aave’s credibility and reputation within the space. What we have is both the safest and most innovative major money market, we need to tread carefully to keep it as such.

With this in mind, even if it’s not one of the main parameters in the decision, I believe the effective coverage offered by the safety module is still a relevant factor to look at while taking decisions related to the growth of Aave.

I’ve gathered the feedback to establish what a counter-proposal incorporating them would look like.

This proposal expands on the first one published by Anjan to incorporate recurring community feedbacks shared in the discussion regarding the first proposal and now its extension.

Hinder recursive behavior

They currently account for almost half of the platform TVL while providing little utility to the protocol. I personally would like us to stop incentivizing borrowing, but it’s not a view shared by the broader community.

Instead, I’d suggest we move forward with Alex’s suggestion: factor the LM rewards on the basis of the net deposit per asset (= total deposited on asset X - total borrowed on asset X). This mechanism will ensure that users looping on USDC for instance are not extracting a neat APY despite providing no value to the platform outside of the fees collected.

Review the supported asset list & weighting

There are several mismatches in the assets suggested and their balance. First, I don’t think the LINK budget is appropriate considering they have been amongst the top supporters and users of Aave since launch.

→ Raise LINK budget. Adjust distribution 95% supply / 5% borrow.

Then, I’d also like us to question and discuss and eventually vote on the inclusion of GUSD in the liquidity mining program. I don’t think this discussion occurred during the exchanges for the first proposal.

→ Vote on GUSD inclusion & adjust the proposal accordingly. If GUSD is removed, we could simply redirect its budget to LINK, fixing two issues in a single vote!


Finally, if we include LINK in the mining, it’s only natural to consider also adding AAVE who is also historically one of the top collaterals used on the platform.

Account for shorter-term LM campaigns

The LM budget is voted on a yearly basis. While this is amazing to adjust the parameters and finetune the design thinking, it makes it hard to adjust it dynamically. To achieve flexibility, I suggest we reserve a share of the total LM budget to incentivize new assets or markets, 50% for instance.

Considering that such decisions are timely, I’d see this share of the budget not controlled by the community or the DAO. Instead, it should be governed by an executive committee. Their mission would be to best allocate this budget to help kickstart new markets.

Budget distribution overview

The yearly program would be funded with a total of 600K to 803K AAVE (depending on the results of the snapshot votes).

50% of which are set aside to be allocated by the Liquidity Mining Executive Committee to help kickstart new markets and assets (such as Aave’s implementation on rollups).

The remaining 50% to be distributed as follows (assuming the adoption of all proposed adjustments). It rebalances slightly in favor of ETH/BTC/LINK/AAVE to account for the new calculation method accounting for net deposits (or borrows) per assets.

Asset Anjan's Proposed Allocation Revised Allocation Split between lenders and borrowers
DAI 15.53% 19.90% 50/50
USDC 62.23% 31.00% 50/50
USDT 17.09% 18.25% 50/50
GUSD 0.42% 0.00% 50/50
WBTC 1.93% 12.00% 95/5
ETH 2.62% 14.50% 95/5
LINK 0.18% 2.10% 95/5
AAVE 0.00% 2.25% 95/5




Soft-incentivizing farmed StkAave holding

Since our LM program distributes tokens as StkAAVE, I think it would be wasteful to not be intentful about designing a plan that optimizes for their retention as StkAave. Instead of penalizing people who withdraw early, I’d like us to go the other way around by rewarding users who farmed StkAave, claimed them, and held them as such for several months.

We could for instance add a long-term twist to the farming by saving a share of the budget to be distributed as an airdrop to users who did not withdraw the StkAAVE they received from the liquidity mining program.

Envisioned Snapshot votes

We have yet to reach consensus on several parameters, so here are the snapshot votes I’d like the community to take part in:

  1. Liquidity Mining Budget: What should be the plan yearly budget? A - 803k stkAAVE (~27% of the ecosystem reserve) B- ~600K StkAAVE (~20% ER)
  2. Should we switch the LM reward calculation to the basis of net deposit per asset? A - Yes. B - Keep the current mechanism
  3. GUSD was included in the first liquidity mining and then intended to be renewed, but is that relevant: should we keep expanding StkAave to include GUSD in the liquidity mining program? A - Yes. B - No.
  4. Should we also include the AAVE token into the liquidity mining program? A - Yes. B - No.

Recursive behavior
Is the recursive behavior actually bad for the protocol? I don’t do it myself, as I prefer to use the protocol in a different manner, but is it actually hurting anything? I don’t claim to have as deep an understanding of this as you, so please take this with a grain of salt, but if I deposit x funds, and borrow y funds, and remove y from the protocol to use elsewhere, it seems ostensibly worse than if I deposit x, borrow y, and deposit y, as the funds never actually leave AAVE.

Incentivizing borrowing
Isn’t borrowing good for AAVE? I’d think that many people come to the protocol specifically for the incentivized borrowing.

Executive committee controlling 50% of LM rewards
Respectfully, I think a significant portion of the community (myself included) would be very opposed to the idea of an executive committee controlling 50% of the LM budget. It feels like centralization.

Incentivized stkAAVE holding
I really like this idea. Would it be possible to work that into the individual rewards rates? For instance, let’s say my WBTC LM reward rate is 1.25%, could it be changed to 1% + a .25% bonus done as an airdrop after x months/1 year? For those who removed their stkAAVE earlier, they aren’t so much getting a penalty as wasting potential, and the uncollected rewards from these people could be returned to the safety module.


Hello everyone, I have not been directly involved in discussions on this ARC until now for various reasons. However, I have been discussing the LM program extension a lot with various members of the community. So now is the time to take part in this discussion.

TokenBrice counter-proposal
Concerning snapshot votes:

  1. B - I would lean more towards the second annual plan with a 600k stkAave distribution. However, I think it is still a lot to squander 20% of the ecosystem reserv in 1 year. Many community members express their wish to be there for the long term, to be there for the protocol. However, from the messages I’ve read in the last few weeks, I have the impression that the goal of some people is to empty the ecosystem reserv as quickly as possible in order to get the maximum return in the short term. If we believe in AAVE in the long term, we must at least see it over 10 years, or even 15 years. Even if the ecosystem reserv diversifies as time goes by (see the latest alliance proposal between AAVE and Curve here). At the current rate of distribution, in 5 years the AAVE ecosystem reserv will be empty (I know that we can revote a modification of the LM in 1 year if the counter proposal of tokenbrice is approved). I think that a distribution of 400k stkAAVE per year (13,4% ER) will be already much more reasonable.

  2. A - This new reward calculation for the LM will avoid loan loops that bring nothing to the protocol except maximum rewards extraction for the users (I even took advantage of this technique for several weeks, it brings a lot of gains to the users but none to the protocol). If I saw this from a user’s point of view then I wouldn’t change it but I don’t think we are there for that.

  3. B - To my knowledge GUSD has not brought anything special to AAVE compared to Chainlink which is a long time partner of AAVE. I think it is better to allocate the 2.10% allocation to LINK and not share with GUSD.

  4. A - Many people are foregoing (direct) rewards from the SM to collateralize their AAVE, I think it would be interesting to reward them a little. 2.25% of the allocation seems correct to me.

Incentivize new assets or markets
I totally agree with this point. Setting aside 50% of the LM budget for new assets or markets seems to me essential.
However I don’t agree that an executive committee should have control over this. This should be included in the ARC for new assets or markets. At that point the community will decide whether or not to allocate it and if so how much.

Incentivize stkAAVE holding
I’m all for this idea. However I think this discussion doesn’t belong here and should have its own thread. So I won’t go into it here.

Security Module
I would like to comment on @pakim249 comments. You say that the security module should not be considered as a measure of the security of the protocol but as a measure of trust in the protocol. The SM was created (to my knowledge, and tell me if I’m wrong) as a security blanket for the protocol. AAVE stakers are rewarded for their risk taking (just like Unslashed, Nexus, etc.). But if they are not there to cover the protocol in case of loss but as a confidence measure, shouldn’t it be removed (with the rewards) and redirect the rewards to the LM. After all, those who trust the protocol first are the users, so we might as well reward them.


Hello @FatherMalice and thanks for taking part in this discussion!

Regarding recursive behaviors

Aave follows a pool-based logic to match the lending and borrowing. The recursive usage means a user is using its own liquidity, so it does very little in helping the protocol to grow available liquidity for others. Yet with liquidity mining in its current state, such users are more rewarded than a user actually growing the liquidity of the protocol.

Think about the following:

  • User A deposit 100 000 USDC without looping => simple mining yet this user is bringing a lot of liquidity in high demand (USDC to be borrowed by others)
  • User B deposits 100 000 USDC and loop it to 300 000 => maximized mining, but effective liquidity brought to the protocol close to 0

My point about the recursive usage is not an ideological one but more practical: users going for recursive loops currently extract half if not more of the LM rewards: is that really an effective spend of the Ecosytem reserve AAVE tokens?

Saving LM rewards for new markets

Initially, I proposed the committee so we can have an agile and quick-to-respond body to allocate rewards to upcoming markets such as Arbitrum, Optimism, or even eventually the AMM markets. Yet indeed it would centralize the control over the LM quite a bit. I guess @JeanBrasse’s approach is preferable here - the budget for each market should go through the ARC process.

Finally, regarding the budget, I share your concerns @JeanBrasse I offered 600K as an acceptable middle ground for the community but I still think it’s excessive as it amounts for 1/5th of the ecosystem reserve as you noted. If our concerns are shared, we could envision a lower basis for the budget, such as ~400K AAve (~14% of the ecosystem reserve)


Thanks for explaining that @TokenBrice , and glad to be a part of the discussion.

I was stuck in my thinking of the security of the funds not leaving AAVE (people not walking away, losing interest and not repaying), but I see what you mean about how recursive behavior really diminishes the liquidity available. I see now why the idea of a net deposit model could be more beneficial.

1 Like

Great to see some solid community debate around the LM program

My observations are in line with the points shared above, below I compare the data from Aave Weekly 16 (pre LM) and the last Aave Weekly 30 (shared in; as well as from some blockchain transaction analysis.

  • The LM has succeeded in increasing supplied (from $7.4b to $18.8b) and borrowed (from $1.9b to $8.2b) liquidity on Aave; with the overall utilisation increasing (from 25.4% to 43.6%) showing more capital efficiency

  • As a result, the Safety Module coverage of just V1 and V2 borrows has decreased from 26.1% to 5.9%. One thing to keep in mind is that same asset on same asset borrowing holds little risk compared to borrowing against less correlated assets (about half of the current borrows)

  • The current LM program encourages recursive user behaviors which drive 32% of the total liquidity on the V2 Pool

  • 57% of StkAAVE received via LM is held rather than redeemed (@Dydymoon I have observed many users unstaking the AAVE to deposit on the Polygon Market which had high yields)

  • 12% of the stkAAVE LM was distributed to users who had never staked AAVE which is good for decentralisation

Given the high budget dedicated to the LM program, I agree that more works need to be done to make the distribution harder to game. We also need to continue asking ourselves, what do we want to achieve with this liquidity mining program?

My risk-focused view believes this LM can help attract high-quality assets’ liquidity granting more liquidity for the Protocol’s users as well as liquidity that is more resilient to market movements. For this we need to focus on the most robust and stable assets: stablecoins + blue chips (not sure it makes sense to add AAVE as it would compete with the Safety Module but could be good to consider additional stablecoins).

In parallel, it also makes sense to favor the assets that contribute the most to Protocol Revenue

I’m not convinced about using LM to launch new markets; but rather favor a progressive bootstrapping phase that allows more flexibility to adapt risk parameters as has already been required. Would make more sense if the launch LM program comes from the listed asset like what Polygon did

Not sure about the idea of the committee feels the community could directly review regularly via snapshot or gov

Also a fan of the idea of increasing the LM risk mitigations benefits by focusing rewards on users with a high health factor >2 as per @TokenBrice gamification idea (also big fan of the soft-incentivize StkAAVE idea)

From my perspective, the recursive behavior does not significantly increase risks, given it’s mostly done same asset on same asset. However it does game the liquidity mining program, costing about half of the distributed rewards. This means that even with the generous distributions of $50m a quarter, its hard to compete with the yields of other platforms

As @pakim249 mentioned borrowing is the key activity on Aave so it makes sense to incentivise user to pursue it. Considering only net deposits or net borrows would limit this kind of behaviors increasing yields for honest borrowers. Though it might encourage users to adapt their strategy accross different assets generating more risk


Wouldn’t this encourage users to do the same recursive lending but just use different assets for their recursive activity? Exemple: deposit USDC, borrow DAI, swap DAI to USDC, deposit that USDC, borrow DAI, etc…
Could actually increase risk overall I think.

Yep. Not sure why we would have GUS but not sUSD, BUSD, PAX, etc. Perhaps this is a good use of the snapshot to decide what should go into the LM program.

Your earliers comments that the LM program is too big and taking too much of the LM reserve resonated a lot with me. Can we explore a gradual decrease in the LM incentives instead of keeping close to the same amount that ParaFi proposed? I think there would be merit to gradually scaling down to a signficantly smaller amount that would take less of the AAVE Ecoststem reserve.

I believe what the right approach here would be to treat this program as the ‘‘Aave v2 LM program’’, make it significantly smaller, and explore other smaller LM programs for other markets in the future as they come along. For example, I would be quite interested in small LM proposals for the AMM market, the future arbitrum market, etc

The LM program could also be planned to continue for 1 year as you say, but I would make it clear that there can be amendments along the way for adding new assets to it, removing some assets, etc… What do you think?


Hey all, great to see the engagement here! There are two topics that have been discussed that I would like to chime in on with some potential improvements:

Deposit vs Borrow Incentives

Solving the deposit vs borrow allocation is a chicken and the egg problem. Borrowers produce yield for depositors, but you can’t have borrowing power without deposits. A 50/50 split seems like a reasonable compromise, but I think we can do better.

An unintended consequence of the program has been that deposit volume has outpaced borrow volume for stablecoins leading to a drop off in utilization and deposit rates.

Each asset in AAVE has a optimal utilization rate (Borrow Interest Rate - Risk). By targeting an optimal utilization rate with the rewards program we can dynamically set the ratio of deposit/borrow rewards to push interest rates towards a stable equilibrium. Given that the optimal utilization for non-stablecoins is set to be much lower, I think this same model would be beneficial to implement for these assets as well.

Here is the model which I am proposing:

Hinder Recursive Behavior

Let’s take an example and analyze the impact:

User A - Deposit 100000 USDC

User B - Deposit 100000 USDC, recursive borrow up to 500000 USDC collateral and 400000 USDC debt

Protocol Risk

Very little difference, see Alex’s response


User B will slightly increase borrow utilization compared to User A resulting in more yield for other depositors

Protocol Revenue

User B will generate increased revenue from the reserve factor

Reward Program Efficiency

With a 50/50 deposit and reward split, User B will earn 9x the rewards of User A

In my opinion, if the program goal is to achieve organic adoption then the massive increase in efficiency outweighs the gains in utilization and revenue and we should try to discourage this behavior. However, I disagree that the solution for hindering this behavior is to distribute rewards based on net deposit or borrow per asset for a few reasons. First, this could easily be gamed by just switching the borrowed asset (borrowing DAI instead of USDC in the example I gave). Second, this would encourage mixing collateral and borrow assets which would increase risk to the protocol and to the user. Keeping the same asset as collateral and borrow is a strategy used to mitigate liquidation risk. By encouraging users to move away from this we could be pushing users towards riskier borrowing strategies.

I think a better approach would be to implement the incentive for safe borrowing. This should probably be a separate proposal as it would be a different allocation from the ecosystem reserve, but I could envision it working something like this:

safeBorrowingRewards = userCollateral * rewardFactor where reward factor is a normal distribution centered at a health factor of 2

Here are some snapshot polls to gauge community interest for both of these ideas:


This is a very interesting discussion!
Personally, I am happy to see that this time, the proposal is discussed at least.

The first LM on Polygon was a very good way to bring liquidity back to this new side-chain and the rewards were also in Matic so it was a great success for Aave and also for Polygon.
The second LM on Aave Ethereum, first of the name was a simple and efficient way to recover new liquidity and also other protocols like Compound at a lower cost for the protocol.

This second edition of the LM on Ethereum and for one year this time raises new questions.
Indeed, I will not come back to the points already stated but I will add, for my part, a question which concerns us all.
Loops allow as we know to extract a lot of Stkaave with a single deposit. A factor of 3 or 4 approximately.
We see that the proposal comes from an entity with large financial means and we can therefore safely say that the extraction of liquidity therefore benefits those who have the most money. So far nothing surprising.

I now ask the angry question.

Is it desirable for large portfolios to be able to benefit from such ease in accumulating Aave without this having repercussions on the price for the smallest investors and get bigger and bigger in the DAO ?

Small investors who I am sure represent a lot of holders.
I will let you judge above all on what this means in terms of decentralized governance…

Of course, the big portfolios will always weigh more than the small ones in the decisions to be voted but is it desirable to accentuate these differences even more by letting hundreds of thousands of Aave be distributed in this way for no other purpose than that of accumulating in the early phase of a protocol that we want to see grow and evolve and occupy its rightful central place in the future crypto economy.

I am not sure.

I will add to finish, that if other large portfolios were to want to invest in the protocol, it could be that they find that the distribution is too disadvantageous for them and we could attend forks and therefore a potential loss final value of our beloved Aave.

We have to choose wisely what we want for now and for the future of the protocol.


If there is a sentiment against recursive activity and loops then it makes sense to decrease LM stkAAVE incentives for USDC which is the most loops producing asset due to the highest Maximum LTV = 80.00% and let in 15 loops create 482 USDC out of 100 USDC deposit.

And direct saved stkAAVE to other assets, not just LINK, but other DeFi blue chips like UNI, MKR, CRV attracting hodlers of these assets to benefit from AAVE not just in material way but also by bringing talent and sharing ideas from these new AAVE depositors.

1 Like

I see this discussion evolved a lot, really happy to see the community in action !

Actually, you missed a few points on the feedback brought by other community members and myself, and the some of the ones mentioned are not fully accurate :

I agree with @Alex_BertoG on an incentive for users keeping a HF > 2. It would motivate users to keep a safe position which can lower a bit the SM risk. Someone made a snapshot vote for this :

We could make another one with this solution, the net deposits one, and also the current way for the community to decide which way is better

I definitely think we should add AAVE if we add LINK too, however, we discussed that the rate should obviously be lower than the SM, so it doesn’t compete with StkAave yield and @Alex_BertoG said it too.

I fully agree on using a considerable part of the LM program to bootstrap new markets/assets, and personally, I’d allocate 40-50% of the LM program, but both the reward split between V2 and other markets and the modification of the allocation, should be voted by the community on Snapshot.

Special thanks to @state btw for building this amazing tool that finally allows all the community to have a voice in the governance.

This should also be decided by the community, and I believe there should be more voting options (for example 700/600/500/400K )

We’ll try to propose a new distribution in the coming days with some community members.

I shared with you my opinion about the inefficiency of the cooldown to avoid selling pressure and this was showed by the LM program, either because people can wait 10 days to sell it as it’s not any random token, or because some sell it with a slippage on a DEX.

My point would be to stop reward in StkAave and use Aave instead, or maybe even other tokens if we can get some from other projects as mentioned below.

From what i understand, 43% of StkAAVE have activated the cooldown, which means almost half of the rewards were either sold it or moved their AAVE on polygon, but the high rewards on polygon only lasted a month, so this can’t explain it all. Moreover, I assume these stats don’t take into account the StkAAVE sold on the market, meaning part of the 57% that did not called the cooldown could have sold too. Not later than yersterday, you could sell 1 stkAave for 0.984 aave, against 0.996 the day before.

Also, not sure if all the rewards for the LM are deposited on the SM and then distributed but i guess so, and in this case this also dilute the StkAave holders which already have a very low return.

As mentioned on our discussion, adding some vesting mechanism on the rewards with exit penalty could be very positive, as the penalty could be sent to the Safety module, solving two problems : reduce the dump and increase the safety module rewards (which is a pretty important point, we need to re balance the rewards between the SM and the LM)

A more detailed proposition on this will be shared in the coming days, working on this with a few community members.

Can you explain why you don’t think using LM to kickstart other markets like the AMM market is a good idea ?

Agree about the ability to adapt the LM and I believe a review every 3 months was mentioned above, but it could be much more often like every 2weeks or month, bot not sure this is what you meant by progressive bootstrapping phase with flexibility

This could be really great, but not sure if a lot of projects would agree to just give rewards for Aave, or the one that might agree could be some new/dangerous projects that what to be listed imo

@state Agree with everything you said, but I wonder, is it mandatory to have the LM running for 1 year ? Why couldn’t we vote on it every x month like the previous LM programs ?

These are some interesting ideas and i fully support the one about rewarding users with HF > 2, but the other seems a bit complicated and maybe it needs more discussions ?

No, it’s not imo, we don’t need VCs deciding every proposal.

I definitely agree with you on this, the protocol is still early and needs an active community.

Thanks for reading my comments !


Hey guys!

Love seeing this heated discussion around the very pertinent topic of liquidity mining. This is what DeFi is all about!

I wanted to give my two cents on some of these points, but before that let me echo @Emilio’s statements during the community call: we need to keep in mind that whatever mechanism we choose to implement should be technically feasible on-chain.

Okay, here we go!

Health Factor Incentivization

Let’s generalize this to just “incentivizing healthy behavior somehow” because of the technicalities. At the end of the day, I’m fully against this idea, and here’s why:
The protocol, by design, already has risk parameters set in place. These should be enough to maintain the protocol in a healthy state. This aspect of the protocol is, in my eyes, not connected to liquidity mining, but to proper risk parameter management.

The protocol should have no problem with users borrowing at near 1 HF, in fact, it technically benefits most participants via interest income and treasury income.

Incentivizing New Markets

This is interesting! However, I really believe the core aim of liquidity mining (in general) is to distribute ownership to active system participants away from passive participants.

With that in mind, I think it makes sense to place incentives in established markets, but using funds to bootstrap a new market may not be ideal. I think markets should develop around demand first, not incentives. I’m against this too.

Diverging from a 50/50 Split

I’m almost certain maintaining a 50/50 split is not the most efficient way forward. However, with that said, I don’t really have much backing to support that claim, it’s just a gut feeling.

I do have a few thoughts though:

  • Borrowers technically provide more value to the protocol by
    a. Increasing depositor interest and
    b. Increasing reserve factor earnings
  • Incentivizing borrows more than deposits reduces the maximum earnings from a “leverage loop”

Furthermore, if we incentivized borrows more than deposits, is it safe to say that the earnings for passive depositors wouldn’t actually be heavily negatively impacted, since more borrows would need to occur to reach equilibrium between borrow rate and incentive rewards?

My intuition says “yes,” and my conclusion would be that it may actually benefit the protocol to a greater extent to actually incentivize borrows more than deposits. Conceptually, incentivizing borrows already increases deposit rates, so passive depositors still benefit significantly. Do we really need to incentivize depositors more? I’m not sure. Leave your thoughts, let’s discuss!

Lastly, I wanted to bring up an idea that nobody really mentioned…

Raising Reserve Factors

In particular if we remain with a 50/50 split, I think it’s reasonable to increase reserve factors on major stablecoins. Here’s my reasoning:

  1. Depositors are already receiving “double counted” increased yield due to two-sided liquidity mining boosting borrow demand while also providing direct depositor incentives
  2. I believe the increase of ~$7MM in the V2 reserve is great, but I think we can do better, the Ecosystem Reserve did spend $82MM after all (of course, growing the treasury is not the main goal here, but still an interesting statistic)

Building up a strong treasury is an essential component to growing Aave into an even more self-sustaining DeFi protocol.

Also let’s not forget that an increase of a reserve factor from 10% to 20% essentially turns a 3% yield into a 2.67% yield (a reduction of 0.33%) all the while doubling the treasury’s earnings in that asset.

If we’re using up this much of the reserve (~27% per year) then I think we’d better shift some focus towards making the protocol self-sustaining.

I think it’s worth considering raising reserve factors, in particular if we maintain the same 50/50 split. What do you guys think?

Laaaaast thing! I just want to bring a little correction to the original post:

This is actually not true! Governance has not decided whether to use the ecosystem collector (which I believe is what is being referred to here instead of Aave reserves, right?) as a first line of defense. The first line of defense, by default, remains the Safety Module.

Thank you guys for the great discussion! Let’s keep it going, I’m curious to hear your thoughts going forward. Let’s design the best LM campaign we can!


Hey @Zer0dot. I agree with all of your points on : health factor, the borrower-depositor split, and the reserve factors.

I disagree with this in particular. New markets are notoriously hard to kickstart without incentives in DeFi, but once they’re big enough, if they’re fundamentally sound, they can maintain themselves pretty easily even once incentives stop. I think using LM programs for to kickstart new markets is a super powerful tool we shouldn’t ignore. For example we’ve seen how well $MATIC rewards helped the polygon market get a good start. We could for example boostrap the AMM market or the Arbitrum market using LM.

But I think this brings up what @Alex_BertoG said, we need to define what we want with this LM program. For me it’s not that much about distributing the token or rewarding active participants. We already incentivize AAVE holders to be active via stkAAVE or stkaBPT.
For me the main goals of liquidity mining on Aave are:

  1. Increasing liquidity for existing markets
  2. Making Aave the best place in the industry to borrow with lower rates.
  3. Kickstarting new markets

But i’d recommand this program to be specifically about Aave v2, so for this one it would be:

  1. Increase liquidity on Aave v2 markets
  2. Keeping the borrow rates attractive (low) on Aave v2.

I think the first program achieved those goals, so now we could look at maintaining this achievement, while trying to do it more efficiently (@spartan’s idea to target the optimial utilization is an exemple) while reducing the cost of the program ( lower amount of stkAAVE per day).