Vesting for the Compound protocol

Note: This post was written in collaboration with Peteris Erins @peteris and Hsien-Tang Kao @htkao

Background

Vesting COMP has been brought up recently in two forum discussions:

  1. Compound Proposal 022: Systematically Reduce Emissions Quantity
  2. Faster way to real community governance

Gauntlet has been working on designing a vesting mechanism whose parameters can be controlled by the community via governance. We started by looking at the designs used in other protocols: A number of other protocols have accrued rewards vesting, with Synthetix being the most well-known vesting mechanism. The design of cTokens provides both flexibility with regard to how vesting quantities should be calculated and presents trade-offs with regards to gas and code complexity. Given that the community will likely want to incentivize COMP for participation, liquidity, and to compensate for improvements to the protocol’s security and/or feature set, we believe in adding a vesting mechanic that can handle all of these use cases.

The liquidity provisioning use-case, pioneered by Synthetix and copied by virtually all of the new yield farming protocols, is most sensitive to the form of vesting used. In particular, if COMP holders want to supply their cTokens to a Uniswap, the accrued vested COMP impacts the value of a Uniswap liquidity provider (LP) share. Let’s walk through this before going through the different models of vesting.

Liquidity Incentives don’t commute with vesting

Should the COMP community decide to prioritize on-chain, non-custodial forms of liquidity, it will be necessary to use COMP to incentivize on-chain trading in the future. For provenance, recent (08/25/2020, 8pm UTC) Nansen data shows the following distribution of COMP at exchanges, which indicates that very little is kept on-chain:

Compare this to the exchange distribution for Synthetix (08/25/2020, 8pm UTC):

Let’s explicitly see why this complicates the math for traders and liquidity providers. In this example, we are assume that a COMP or cToken liquidity provider stakes their LP shares into a Synthetix-like rewards contract to earn the liquidity incentive. Suppose that one places 1 cUSDT and 1 cUSDC in the Uniswap cUSDT/cUSDC pool. Furthermore, suppose that in one day, the cUSDT earns 0.1% of interest and 1 COMP while the cUSDC earns 0.2% of interest and 2 COMP. Now consider two different vesting styles:

  • COMP is vested continuously: Uniswap LP share should be valued at the price of the underlying coins (USDT, USDC) plus the accrued trading fees and interest plus the value of COMP less the 95% percentile gas costs for a withdrawal transaction
  • COMP is vested discretely: Uniswap LP share should be values at the price of the underlying plus the accrued trading fees and interest plus the discounted value of the COMP less gas fees

Why do we have to discount (e.g. a la discounted cash flow) the COMP portion of the share? Since COMP is more volatile than the assets producing it (cUSDT, cUSDC), the holder of the LP share needs to discount the value of the share based on how long it takes to claim COMP. For instance, if COMP followed the weekly emission model of Synthetix and the time until the next reward claimed is T, then we would discount the COMP component of the LP share by a factor such as exp(-sqrt(volatility(COMP, USDT) * volatility(COMP, USDC))* T) [0]. In a sense, discrete vesting reduces the expected reward for LPs, even though it costs the network the same amount in terms of emissions.

Why do COMP voters have to care about this? Suppose that the community first chooses to do discrete vesting (e.g. a weekly distribution akin to Synthetix). If the community later decides to incentivize on-chain liquidity (as opposed to centralized liquidity, which dominates COMP holdings as of now), then the choice of how to distribute COMP to liquidity pools depends on the vesting structure. A vesting structure that has a number of parameters — length, vesting period, discounts – should be able to accomodate liquidity incentives. If on the other hand, liquidity incentives were given before a vesting choice was made, the protocol would have a harder time choosing what schedule is used as it would need to account for the existing implied discounting factor.

Therefore, we believe that:

  1. A vesting schedule should be flexible enough to provide future liquidity rewards
  2. No liquidity rewards should be administered until vesting has been set.

A modest proposal

Given the desire for the community to have a mechanism for vesting earned COMP, we wanted to put forth two proposals for vesting. These two proposals take two extremes:

  • Have a fixed period for vesting which saves on gas, but forces LPs to have to compute discount factors
  • Have continuous vesting, which is more expensive, but makes math for liquidity provisioning much easier

We’ve written two pseudo-code implementations (Vyper-esque pseudo-code) of these two proposals that can be found here. Hopefully the intentions are clear and one can clearly compare the trade-offs. We believe that the first implementation is similar to the description of a vesting period by @jared in a prior forum post

Call for feedback

We would love to hear feedback on these proposals and whether there are other features that are missing and/or if there is another application that causes these options to be malformed.

Footnotes

[0] This factor is chosen if we assume that COMP/USDT, COMP/USDC are geometric brownian motions with well-defined drift, variance. Traders will come up with their own discount factors, but a fixed vesting guarantees that the discount factor will be less than 1, provided they are rational. We note that technically you have to discount both continuous and discrete vesting, but because the discrete vesting has to account for volatility over a long time period it always will over-discount relative to continuous.

8 Likes

I’m having a hard time following this post and I think a more simplistic explanation would be helpful.

Primarily I’m confused if we are only talking about delaying the ability to claim rewards one is owed (this is what I consider to be vesting) or if we are also talking about providing bonus incentives to a certain subset of users who choose to lock their comp? Or if we are talking about both?

4 Likes

not sure I understand this point, could you expand further? COMP’s volatility vs farming assets doesn’t seem relevant to vesting

I believe (and @tarun correct me if I’m mistaken), that the simple “fixed period” vesting would be a regularly scheduled window to claim COMP, e.g. every 60 days. So, February end, April end, June end, etc.

Users would then be forced to judge the future value of COMP (and their desire to hold it in the future) vs using the protocol today. Purely capitalist yield farmers would find this to be more unpalatable than “natural” users. Taken together, the impact of fixed period vesting might be lower usage by farmers, and more rewards for long-term holders.

Did I get that right?

1 Like

I would like a more complicated solution, a vesting contract that allows the owner to delegate/vote before he could claim the COMP in this case a longer vesting period could work.

3 Likes

I think the current model works. If the goal of this is to limit the number of people selling COMP regularly, I think it is over complicated and unnecessary. Those who are interested in a vesting solution should write out why and then think what is the best change that can be done to accomplish that is.

The COMP launch has been a huge success. Any changes at this point should be carefully considered.

Apologies if I mired the initial explanation with jargon. Here’s what I mean in hopefully simpler terms:

Assumption: A user prefers to receive COMP now rather than later

Concretely: For a user, receiving 1 COMP now is equivalent to receiving 1.1 COMP in a month if you can reinvest the 1 COMP you receive immediately and earn 10% in a month (e.g. via being a Uniswap LP, lending on a venue that lends COMP, etc.)

Analysis

  • Using this assumption, if you place a cToken in a Uniswap pool and the cToken is earning COMP every block vs. every month, there’s a value difference in the Uniswap pool share (e.g. LP shares with cTokens that vest COMP on every block are valued more than LP shares with cTokens that vest the same amount of COMP every month)
  • Owning LP shares or placing cTokens in pools means that the value of the liquidity pool share that has a cToken with a COMP / block will be worth more than the one with COMP / month -> you’ll end up w/ different amounts of on-chain liquidity based on the issuance and/or lock-up

Thus, even if COMP never has an incentivized pool (like Synthetix), the choice of how vesting works effects the value of COMP when used elsewhere on chain. If a large portion of the community wants to utilize their COMP in other on-chain financial products, the vesting effect will be quite important to analyze carefully.

Since the precise implementation of how vesting is added to the protocol will effect the time scale, frequency, and amount of user interaction needed for vesting, it is important to keep this effect in mind, especially if the community deems on-chain usage of COMP to be a high priority.

As an explicit example of what might happen if the user has to manually claim vested COMP rewards, consider the Balancer gulp() bug that led to losses due to a deflationary token. While COMP will not have losses of this form, there is an issue if claimComp() is called on cTokens in an LP share a long time post vest. Consider the following numerical example:

  • cUSDT/USDT price is $1.01 so LP share is worth $1.01 [0]
  • Earns an average of $0.01 COMP / block

If claimComp() is called every block/continuously vested, then the LP share’s value k blocks after vesting begins is $1.01 + k * $0.01. On the other hand, if the vest happens every 100 blocks, then the price of the LP share at block k is $1.01 + floor(k/100) * $0.01. And if the user forgets to call claimComp(), then there will be a bigger shock to the price of the pool share when the COMP is claimed.

We’re only pointing this out because the continuous (e.g. every block) vs. discrete (e.g. user has to claim ever week/month) vesting schedules will require different levels of COMP holder attentiveness, especially when COMP is in other protocols.

[0] Slightly misleading in that you have to include Uniswap/gas fees on withdrawal, so the price might differ slightly. However, in a low gas price and 0% fee world, this is true.

3 Likes

The main point of vesting is two fold:

  1. To incentivize development and security of the protocol, as @arr00 has championed in multiple posts
  2. To incentivize long-term liquidity provisioning

We strongly believe that spending the entire budget of the protocol on liquidity provisioning, as is the current status, is suboptimal. There are a number of components and facets that a protocol’s budget should be spent on, such as (but not limited to):

  • Security
  • Incentivized voting participation
  • Feature development
  • Insurance Fund / Reserve Management

There is much that DeFi protocols can learn from layer-1 communities that have faced similar issues, albeit without the consistent cash flows of DeFi.

2 Likes

I know that speaking about the COMP price is a bit taboo here, but this can’t really be addressed without bringing it up.

I think the main issue here is an irrational market. The current value of COMP is highly inflated due to speculation and limited supply. The large farmers are more likely to be rational actors and that is why they most likely dump their COMP asap.

Vesting could have varying outcomes:

  • Farmers leave, dropping the TVL massively, causing the price of COMP to plummet, shedding any remaining farmers.
  • Farmers stay, COMP becomes more scarce, driving up the price of COMP, attracting more farming.
  • Farmers leave, but COMP is more scarce, leaving the price about the same.

It’s anyone’s guess.

But the more fundamental issue is that governance and price speculation aren’t really compatible.

If you truly want COMP to be a governance token, charge a 10% fee every time it’s transferred. That way it can’t really be traded and will serve it’s real purpose of assigning voting rights to users of the protocol.

If you choose for price speculation, it’s fine to leave things as they are. Let the farmers fill the reserves and keep the TVL high. List some new assets to attracts more capital. Start talking about a way to reward holding COMP with dividends.

This is the real crossroads we’re at. And this seems to be the discussion nobody really wants to have. No need to make the contracts more gassy by adding more bells and whistles.

Anyway, my 2 cents.

relevant meme

@tarun - Vesting period is a (looking back) annoyance barrier and would only serve to delay selling, rewarding for holding $COMP is a good (looking forward) idea on the other hand.

As an example paying out $COMP dividends driven by the market conditions quarterly. Would be very interested to see in practice.

1 Like

Not sure that keeping tokens in a Uniswap pool works as a proof that the tokens are being kept “on-chain” in the long term. If there are incentives to doing so, wouldnt there eventually be a service offered by a CEX to custody your tokens while they are inside a uniswap pool earning the incentive? Likewise, if earning COMP through a CEX service, they could offer to buy off your unvested tokens, messing up that incentive too.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

As a follow-up to this, we [@peteris, @jmo, Rei] just added a PR to the Compound repository for a vesting implementation. It proposes a change to the protocol to add periodic COMP vesting, as per the discussion in this forum post. This will enable the protocol to do the following:

  • Add vesting for COMP rewards that encourages long-term holding (e.g. akin to Synthetix’s vested reward)
  • Enables governance to issue COMP grants out of the accumulated COMP (c.f. @rleshner’s post: A Call to Action)

The current implementation, which will be proposed to be added, also adds a few other features:

  • Reduced Comptroller size (the size was within 100 bytes of the EIP-170 limit after borrow caps were added) using some of the suggestions from @jared’s post A Leaner, Meaner Comptroller
  • Independent vesting module: Other projects, not only those using Compound’s governance contract, can adapt the vesting module to their contracts. Contracts that do use Compound’s governance contract (e.g. Uniswap) can take advantage of vesting sooner rather than later

We are excited to get community feedback on this! :pray:t5:
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEEJAuhmVduSEVN8uPKIPJySxksQ8FAl+HGPgACgkQKIPJySxk
sQ+U5w//bpdGale1/7nGNvCuSNzzoUFuJ9/IaadrZCxRHf6j+rkZpQs/1Nxbge+K
iW+qrU5c6JKNiA4dKuX9yDKlL/Bo93Wo3vcSeFbn/2xSohJcSV9bqq1FyDRx9xi6
oq+vU5nSFX1VMTPgw/8Odxcvw325ZlZOnF0rB1RLWj5LqvzmwsOQNTy+WHNRlJ73
sDubBHHuqMnPJzS4JIIhoUmUS5q2Z31dQ40zjMufR58PEMSAwHeOA7iXuKJVTMjD
nwGfhbB/YanXH5d2PkOkxvkMNIMxnpVOfh/2x1eSK5MKFsrF7pftmStu0B5tzPBL
VGyPJho/2qqZKDcxnyZ9yWY3z3TB5kRxqNgUdNbE5UXZjO2Qf6fLBmTUPQ7CBJfY
cYoC07WvAz7yI/SKhaxB3y5+QchU5ooYiDswfQE1047dKxTOLX3Dt73Psjh6pYLm
OKitbZO0XQdi7Sw0DHjIzvxwyBHf4W+E1n+vIcqRrE8GqaAAQw20pWNT03DneT5S
2SZWObSZlVJHYwA7I8pNrx+X16t+XtiiBjubfYUfVEHAQm245ECAsSo7YDljcFZC
H2pIQiRfwdK1Iv4GqsgSAUvpJuDuuj/7xwQQOFSQScnYOhOa1TgfCnsj57wkdZZr
r+hRBIBty9s0MWozl8oRXMqapvK+S47+CBkmLXG2hVBsZ11HAFk=
=TvOa
-----END PGP SIGNATURE-----

2 Likes

Something I believe is very important, but I don’t see any new function actually allowing for this.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Indeed — that’s the next piece of code we’re working on! Just needed to get a little space in the comptroller…
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEEJAuhmVduSEVN8uPKIPJySxksQ8FAl+HIIgACgkQKIPJySxk
sQ9Ktw//cUpzLu3rTngxzsjHX+/RLT9/WgQ4SsZYxJeYjs2MSqxcVcgCXYOlLmpa
DDg75U/kxiv605Kht4nc6rOpl8hoC8eYWT+o++dSN/OwAUSV9UDMZdAg9RwGO7mC
Xeo1VQK9obV+vEO7AfSUzg92JhRfRMlidun9ik6pM0WwJPmhOKtiyXE77rncT6t3
jvPNjLPpyt2B8munTjEVceH5ZSw9g0s+Hg1cLDWChnDYAJtrv3GU0ckGmbscIpuS
l7bBSp7+HsZN/+iM+WNewkusyMX/Wp9HORVxzsLUakjm3NJM/ICmI/8PFNUzZ/iJ
Osy3AKadXNZnX0GBGHAVcCBqr0E5/NzmbzNKMD8kkYIk+2X5wK/UmvRnHXnpowsR
p2Y39+rCNbvdQe+UKzWNNgqIDLZQ//B/ko6ctDKfrs9egdq0P8IJLXjmSs9CBrKW
461KANTHLgKEaBTPXYsCW35FwRVaGWij2AZt6r/amvZDeesiNhbVgF81h7B1cmYE
EAUAc+NmSMQHdGq54hqWacsoubT7rcrUu+QVWdDmDLL846oGf/NVougOKY/pAZxq
EJfG3LF9+jG/Va9r4IdNAPvocaUiT6j1Uj1lr/lYSBByPrGsa2/G7u01LAkYyPfq
Ld/SzVDvpgdqHd8VNlIKKxvXO+K4ctmVRjN0/XxPIVY3cKvQrEY=
=A/Ab
-----END PGP SIGNATURE-----

This may encourage long-term holding, but it will likely drive users towards trading COMP derivatives to manage their risk. I am not convinced this fixes a problem or if there is a problem here.

So if you mint COMP two days before general claim schedule, you basically did not vest your tokens.

This system looks inelegant to me because it does not apply the same vesting period for everyone.

I propose a bonding curve to distribute the COMP farmed on a 23 day basis.
Capture d’écran 2020-11-23 à 11.14.21

Smooth and time constraining.

1 Like

Logically, the vesting structure should be refined first, my opinion is that the users of the project then have more control, and with that come security advantages (it is easier to simulate possible attacks and manipulation). Continuous vesting is a better solution if the main argument against that model is gass costs. However some parameters for vesting factors need to be defined, does not need to go to extremes.

Don’t mind if I missed something and criticism of my opinion is of great importance to me as I am new to the forum.

I like the idea of fixed vesting periods. I would prefer quarterly as it would simplify tax accounting. It could potentially work like this. COMP earned from Dec-Feb would vest in Mar, Mar-May would vest in Jun, Jun-Aug in Sep, Sep-Nov in Dec.

1 Like