The beauty of crypto is that value can now be programmed. This idea of programmable value has also unlocked the idea of time-aligning incentives between a protocol and stakeholders via time-locked or vesting tokens. As a result, we’ve seen many protocols begin to adopt different variations of this design with varying success.
Some well-known examples of vote-locked, staked, or vesting tokens include:
Curve (veCRV) and also the initial airdrop which was linearly vested over one year. CRV can be locked for up to 4 years and the longer your lock, the higher your veCRV balance. 50% of all trading fees on the Curve protocol go to veCRV holders.
Balancer (veBAL): veBAL is locked for a one-year period and linearly unlocks. 75% of all fees generated by the protocol are proportionally distributed to veBAL holders. Interestingly, veBAL is an LP token consisting of 80%/20% BAL/WETH.
Aave (stkAAVE): requires a 10-day cooldown period before one can withdraw AAVE from stkAAVE. stkAAVE receives inflation rewards of AAVE.
Redacted (rlBTRFLY): revenue-locked BTRFLY is a newly designed system from Redacted Cartel which allows BTRFLY holders to lock their tokens for 16 to 17 week epochs to earn revenue generated by the prortocol’s products and treasury. rlBTRFLY holders also earn inflationary rewards of BTRFLY.
CowSwap (vCOW): Although COW does not have a protocol revenue sharing agreement currently, vCOW was the token distributed for the initial airdrop which has a 4 year linear vesting period to be converted into COW.
- …and many more
- Reward recipients of liquidity mining incentives, grants, and other $HOP rewards with partially locked or vesting tokens which should prevent mercenary yield farmers from earning HOP just to sell the token. A locked token rewards long term support instead of short term speculation.
- Create a time-aligned token variant to direct protocol revenues/transaction-fees if the DAO ever decides to turn on a “fee switch” of any sort (this RFC is not for discussing a fee switch, only for a vesting/staked token equivalent of HOP).
- Redirecting developer time to a non-core protocol function
- Being locked into a token design that we may want to change in the future
I believe that this is at least worth the discussion to gauge early opinions. Should Hop adopt a vote-locked, staked, or vesting token? If so, what design makes the most sense?
HOP currently suffers from limited liquidity. It’s important to remember that staking or locking would at the margin remove liquidity from the market. That doesn’t mean don’t do it, but you may want to include that under Pros and Cons. Removal of liquidity can be either, but at the moment, there’s not a large amount of HOP liquidity to begin with.
VE models, while pursued elsewhere (as well outlined in the Examples section), may not fit every protocol.
We have seen in the past new token models come and go and caution the haste adoption of this voting escrowed model. There is a chance a better model may be born soon.
As is, it places operational costs on the dev team and is new smart-contracts and complexity.
While this sometimes translates to more rewards (via Governance), added complexity and fragmented token holders may affect participation in the long-term.
Speculation isn’t fun but it leads to better price discovery, volumes, and liquidity.
Vesting/locking would only be introduced for newly issued tokens, so at the margin it would not remove liquidity from the market. Instead, any new liquidity entering the market would happen at a more steady pace. Yes, staking could potentially remove liquidity from the market and so I think vesting tokens should be a higher priority than staking anyway for the liquidity mining rewards that are currently being discussed.
I think I generally agree with this in that it’s probably too early to adopt something and there likely isn’t enough developer bandwidth anyway. In any case, I think this thread should stay open and continue to develop the conversation around vesting, staking, fee distribution, etc. as it inevitably ebbs and flows in interest.
@lito.coen mentioned in Discord to take a look at SNX and GMX vesting rewards contracts which could solve the issue of developer bandwidth and also deprioritizes staking in favor of a near-term vesting implementation. I think this could be the optimal route.
I share a similar sentiment with the comments above, and looking at some of these examples, ‘ve model hasn’t exactly proven itself to be a successful model so far.
It adds an extra layer of complexity when we aren’t exactly sure if it’s helpful to the protocol. There is also a misalignment between ‘ve token holders and the protocol.
Locked tokens don’t necessarily help with price in any way, as those who want to sell are unlikely to lock their tokens, so I don’t necessarily agree here.
Why is there a misalignment between ve token holders and the protocol? I would say the exact opposite is true.
The goal here isn’t necessarily to have people stake/lock their tokens, but to reward liquidity mining with pre-locked tokens (e.g. SNX, AAVE). The goal also is not to support the price in any way. It’s to time-align liquidity mining participants with the protocol. Attracting longer term oriented liquidity is significantly more valuable than attracting mercenary liquidity that will leave the protocol as soon as liquidity mining is sunsetting.
've token holders will boost pools that favor them → large ve holders can target emissions towards ‘their’ pools. That might not always necessarily favor the protocol and can cause inequality amongst emissions.
There are no “their” pools here with permissioned bridges with a small/select group of assets. In any case, I don’t think anyone would advocate for a system as complex as voting and boosting for this initial scoping out of a locked token system. That is certainly not needed for Hop.
At it’s simplest level, this is about starting a locked/vesting token equivalent to reward liquidity mining in its early days. This is not about a fee switch (way too early for that, although it’s certainly a step toward that) and it’s not about boosting pools. It’s simply about time-aligning liquidity miners with the protocol.
I meant in the case of the 've model in balancer not specifically for Hop in this case.