APGP 16: V1 Incentives reduction

Summary:

Proposition for progressive reduction of V1 incentives

Context:

APWine protocol V1 is currently deployed with a set number of pools and incentivisation over its liquidity (directed through the gauges). Liquidity mining was voted initially to allow bootstrapping the liquidity on the different pools, currently following the distribution voted with APGP 14 (Snapshot 1).

While the V1 was a success as it brought the primitives designed from 0 to 1, bringing up to 25m$ TVL at some point, the V1 is no longer in the user acquisition phase, as we are getting closer to V2 (in the pipeline for almost a year now, with a private beta recently announced for before xmas). The V1 represents a non-negligible maintenance cost for its app (mostly), and unnecessary complexity in terms of integrations (changing contracts’ interfaces). As such, we are proposing a plan to progressively reduce incentives.

A progressive reduction of those rewards would result in less dilution of the current holders, avoiding spending unnecessary/organic rewards for a rather low TVL atm. We believe this would represent a long term benefit for the protocol, also saving treasury reserves (which could eventually be used as incentives in the next iterations).

The distribution of LP rewards in its current state is a transition that is aiming to last until the next version of the protocol is released. The goal is to reduce token emission in the meantime while user acquisition is very low to keep as much dry powder as possible for the next release.

Note: the incentivisation of the voting escrow voted with APGP 10 (Snapshot 2) would not be affected by this proposal.

Rationale:

We are proposing a linear increase of the reduction factor:

(with x>33)

With an index of the reward weekly period (currently 33). Starting from cycle 35 (17.11.2022-24.11.2022), we will update our distribution formula to reduce the token distribution and progressively deprecate V1 liquidity while still maintaining a baseline for current LPs and stakeholders. The updated formula would results in the following:

  • Cycle 35 (17.11.2022-24.11.2022): 23’705 APW

  • Cycle 36 (24.11.2022-1.12.2022): 19’355 APW

  • Cycle 37 (1.12.2022-8.12.2022): 16’762 APW

  • Cycle 38 (8.12.2022-15.12.2022): 14’992 APW

  • Cycle 39 (15.12.2022-22.12.2022): 13’686 APW

etc.

Means

Dev & operational work

Update the rewards formula of the rewarder

EDIT: The draft was edited on 11/11/2022 taking into consideration the iterations made with the community

  • Yes
  • No
  • Abstain

0 voters

This is much more fair than what I had in mind (just straight reducing incentives to 0 immediately), ergo a slow and restrained drop in rewards is a great way to gently remove liquidity and bring an advent of the new V2 of Apwine.

2 Likes

I’m against that proposal, I want to see V2 in production before cutting V1 incentives.
no incentives = no tvl = apwine dead

4 Likes

Hi @Enerow.eth, than you for your feedback. I believe the protocol should not only rely on incentives to be able to get liquidity. High rewards are indeed a way of bootstraping liquidity / can increase the inertia of growth when generating enough revenue proportionally. We can see in this case that here

  • liquidity is decreasing despite very high incentives (V1 is getting obsolete)

  • holders will get diluted in an unhealthy as the protocol is emitting more than the revenues collected (low volume)

  • the maintenance of the v1 will be progressively discontinuated, hence the transition context explained in the proposal

In the end, emitting high incentives would just feed a limited quantity of LPs, for a liquidity that is not used/useful. Discontinuing incentives now would save funds for the long term of the project and the treasury reserve in a smooth transition to the next iteration (the opposite of killing it, given the volume & tvl I dont believe current LPs are making the project “live”), on the other hand keeping high incentives would only benefit farmers

V1 will be obsolete once V2 is in production.

Discontinuing V1 incentives makes sense once V2 is in production.

Limited number of LP because last winelisting voted by the DAO 3 months 1/2 ago hasn’t been implemented.

I understand the fact that V2 is awaited, and we are working hard to deliver it in due time and in the best way possible. In the meantime, rewards are being spread among a very small subset of LPs, which liquidity does bring much (regardless of when the V2 is out). The statement here is that high rewards on V1 would only represents a waste for the protocol and its stakeholders as it would not be/is not efficient to bring more liquidity/volume/revenue (as we can observe with the current pool regardless of high incentives).

Tell me what’s the purpose of a VE token if you don’t have gauges and boost?
+40% of the current supply of $APW has been locked for up to 2 years for that exact expectation.
You stop that, trust is gone, the APW token will be worthless and APWine protocol will be useless.

1 Like

The proposal is not about changing this mecanisms for now, but reducing the rewards. The question that we are addressing is what is the purpose of distributing that much rewards if that doesnt bring liquidity/the liquidity brought isnt efficient.

If the DAO agrees on the terms because they give a better outcome in the long-run, then I don’t see why the project would be dead, quite the opposite!

It is to better prepare for the upcoming V2, it lets the APW emission slow down a bit, it would also be more interesting to bribe when the V2 is out.

PS: I mentioned it on the APIP 6 discussion as well, but I’d be happy to organize a call to exchange ideas on the same!

2 Likes

What do you mean by “for now”?

Do you mean, let’s cut rewards & V1 pools & app and then once the veAPW holders have nothing for months (year?) waiting for an hypothetical V2, any proposal you make would be accepted in hope of get the protocol back online?

Even if it’s not your plan, that’s what’s going to happen, veAPW tokens holders locked for 2 years with no protocol to use, no gauge to vote for. V1 should not be halted until V2 is up and running!

Edited the proposal draft following discussions between team and community. Let us know if you have additional feedback!