VE-System for Minswap - Temp Check

Temp Check Discussion
1

A vested token approach for minswap

A. Introduction

Cardano’s DEFI ecosystem is still relatively young and under development whereas the landscape on Ethereum is more diverse and feature rich. One of these features is a vested governance token that allows to vote on incentives. Most prominently mentioned here is curve ($CRV) and balancer ($BAL). This proposal aims to start a discussion for such a system by the MinLabs Team and Community.

B. Scope

This proposal does not aim to start the development. If it is voted for a discussion about the different topics of this proposal should take place. First what kind of staking would benefit min most, how voting should take place, how incentives are distributed. After those discussion concluded a new proposal would handle the development and the scope of the development.

C . Implementation

There are several reasons to pivot to a VE-system. Yield-Farming in its current state is neither decentralized nor easy to use and should therefore be automated. Any project will be able to buy $MIN and lock it to vote every round for their pool.

Also a vested system allows others to build on top of it. Convex has build on Curve whereas Aura has build on Balancer and both offer services which are easy to use and improve the overall expierence for liquidity providers. Besides that it also created a bribes market to buy votes, i.e. Hidden Hand and others.

I. Locking Min Tokens

There are basically two different approaches. One is to lock only $MIN similar to current staking. This wont expose the holder to impermanent loss (IL) and is easier to implement but can cause a liquidity problem if most of the token is locked. The other approach locks $MIN / $ADA pool tokens but is prone to IL. The advantage is that the locked token still serves as liquidity for the token. A mixed system would probably bring the best of both worlds together but this proposal doesnt propose any specific locking mechanism. This is subject of any Follow-up proposal.

II. Voting

The voting process should consist of a single transaction that involves the pool you are voting for. Ideally the minswap website would offer a frontend for this. The vote should be repeated automatically similiar to the ada delegation process.

1. Intervall

Everyone should be able to vote any time for their pool but changes will usually only take place every two weeks. The frontend could display current incentives and future incentives for every pool.

2. Issues

There are problems that can arise from voting mechanism. If an entity owns the majority of a pool and also owns huge amounts of $MIN this entity is able to delegate the $MIN incentives to this non-performing pool. The incentives wont increase liquidity of this pool nor create volume and will be a drag on the value of $MIN. Therefore it requires safeguards to prevent this kind of value extraction.

3. Safeguards

One way is to limit the maximum incentives per pool to a certain percentage. The entity is still able to drain incentives but its limited. Having more than one pool bypasses this again.

Another way would be to „meassure“ usefulness of the incentives and limit the amount of incentives allowed for this pool. Some variables could be volume, TVL, centralization, etc.

Intervall and safeguards are subject of any Follow-up proposal.

III. Incentives

Currently projects have to write a proposal to get listed as farms. This process should be decentralized to safe time and made easier to include anyone. From my understanding current yield farms want first to increase TVL which then increases volume which then increases income from fees. If the focus is to maximize TVL then 100% of available incentives should be up for vote. A mixed approach where parts of the incentives are given to pools that provide high volume would offer advantages for popular projects. They could decide if they want to further increase the APR of their pool or not and give smaller projects the chance to buy incentives for their pool. The distribution and amount of incentives should be also subject of any Follow-up proposal.

D. Conclusion

Further decentralization and automation would be the result of a VE-System whereas the disadvantages are the development cost and the risk of voting mechanism.

There are definitly important steps left on the way to a VE-System but this is the first step towards it. A discussion should take place about the details pointed out in this proposal which acts as a temperature check if the team and community is willing to explore this further

2 Likes
2

Hi Funky, this is an interesting proposal. Venomics is something we have talked for a long time about.

My worry with venomics has always been that they have very little impact on fundamentals. First lets align on something: what should be the priority of Minswap as a protocol? My opinion–> to maximise Volume. Because that is basically similar to revenue in a traditional company and a part of it goes to MIN Holders.

Now, If you look at the MIN token as an expense that the protocol incurs, it should then be allocated in a way that maximizes the Volume.

What you do by implementing venomics is you disrupt that. If implemented, MIN is allocated according to what MIN holders vote, which may not always be in the best interest of the protocol/Volume. It honestly becomes a game of whales trying to game the system and squeeze as much rewards as possible for themselves.

You can see historical excamples of how this went wrong with Solidly ve(3,3), or, Id argue Sundaeswap as well…they have a similar system. Do you think their implementation has been successful/should be mirrored?

I do think you are onto something here though. The key in an ecosystem with low and sticky Liquidity like Cardano is earning the trust of big projects/MMs and having them put their LP on Minswap. How do we leverage venomics to achieve that?

I think what we need is a deeper dive into how venomics have been successfully implemented in the past (perhaps Aerodrome is a good example?), and how it could be applied to Minswap.

1 Like
4

Thank you for this proposal Funky, I think this is a good idea. Unfortunately, I think it would be easier if there were some form of implementation plan, such that we could understand how it’s done and what problem the proposal aims to solve.

I’m responding to Purrito’s comment because I agree with the need for such a token to aim for an increase in revenue. In my research on MIN Staking, I have found that $MIN would favour from such an implementation as a yield bearing collateral asset.

This means:

  1. Stake your MIN and obtain veMIN/stMIN or whatever name you want to give it.
  2. Use your veMIN as collateral on other DeFi platforms, such as Fluid Tokens.
  3. Redeem your veMIN for your MIN and accrued rewards.

This would effectively unlock an amount of liquidity that would favour Minswap in terms of revenue and DeFi in general.

I wonder if this idea sounds attractive