More notes:
[PUBLIC] Gauntlet Compound Governance Notes
Possible implementations for Compound vesting implementation to draw discussion about tradeoffs.
In short vesting periods, we don't need rewards to vest in the same speed that they accrue. Instead we can vest all accrued rewards with a frequency of vest_period. Rewards accrued right after last vesting cliff will vest the longest.
Pros:
Cons:
Low-gas repeating cliff vest - vesting at market level
Storage: 1 x uint per market
# Existing accrual array
comp_accrued: Dict[address, uint] # comp_accrued now gets accrued after a vesting period
# Existing market accrual array
comp_accrued_market: Dict[address, uint]
# New storage per market that stores amounts that **have vested**
comp_vested_market: Dict[address, uint]
# Block when last vesting event occured
last_vest_market: Dict[address, uint]
@internal
def refresh_comp_speeds_internal():
# ... existing code
for each market:
if vesting_event_just_happened(block.timestamp) # check if between this block and the previous recorded block for this market was a vesting event
comp_vested_market[c_token] = comp_accrued_market[c_token]
comp_accrued_market[c_token] = 0
last_vest = block.timestamp
# This is a simplified version that doesn't calculate exact vesting block, full version will calculate exact block
# where COMP was vested and calculate the vested amount fraction.
@public
def claim_comp():
# Same as claim_comp now just calculated against comp_vested_market, not comp_accrued_market
# Also, instead of using the latest accrual snapshot, it will use last_vest for the market
Lets assume the vesting period is long enough such that we don't want there to be an incentive to liquidity mine only ahead of the vesting time. Thus, our goal is that rewards vest continuously in the same way they accrue. Downside of these implementations is that they require the user to explicitly start vesting the tokens (and potentially also explicit claiming).
Pros:
Cons: