@jmo, the work that you @tarun and the Gauntlet team have done in exploring / proving a number of vesting/cooldown approaches is fantastic and deserves recognition.
Last week’s community call walked through the cooldown codebase, and gathered lots of new feedback from the community. Everyone seems fully aligned with the goal of getting more COMP in the hands of loyal users - while dissuading purely exploitative farming.
In Discord, @lay2000lbs raised the issue that a cooldown will degrade / complicate the user experience (for normal users, farmers, and integrated products), which I agree with. Additional steps, delays, and flows is a “stick”, that hits farmers harder than organic users. While this will likely tilt usage towards organic users, it might still sting.
Extending @johndoh 's idea a bit, I wanted to take a moment to explore the “carrot” path, to make the COMP Distribution as uplifting as possible.
Upgrade: Distribute cCOMP
Instead of distributing COMP, the claim() and grantCompInternal() functions can be upgraded to distribute cCOMP to users. This would convert the uncollected COMP, into COMP supplied to the protocol, earning interest and increasing borrowing capacity (if collateral is enabled). At any time, users can withdraw COMP from the protocol. If users are looking for liquidity, they can borrow any asset (like a stablecoin) instead.
To a user, the status quo (post-claim) switches from a decision on “what to do” with COMP (supply it, or sell it), to a decision on “whether to withdraw it”.
This can be paired with significantly reducing the gas costs of the claim() function (by moving compAccrued to the end of the function to run/distribute once, instead of looping over a transfer function multiple times).
Note: this wasn’t possible when the Distribution first launched (cCOMP didn’t exist yet).
Upgrade: Enable cCOMP voting
The Governor Bravo (a modernized Governance framework) in development could be upgraded to allow cCOMP voting alongisde (or eventually, instead of) COMP voting.
All COMP earned by users would be able to immediately vote, further reducing the incentive to withdraw COMP from the protocol, and increasing participating in governance.
Note: this might require modifying the cCOMP implementation with a balance checkpoint first.
After releasing these upgrades, the community could monitor whether participation in the governance process has increased. If it hasn’t, the cCOMP contract could be updated with the Cooldown logic – locking users into a longer (but more useful) commitment.
Ideas / thoughts / counterarguments are very welcomed.