Compound Contributor Grants

Proposals
1

@jmo @tarun @peteris, and Rei Chiang

Our first proposal, Reduce COMP emissions by 20%, focused on providing a healthy amount of COMP for governance to utilize. Previously, the protocol was spending 0.5 COMP / block on liquidity incentives to borrowers and lenders. However, after our proposal (and proposal 10), the protocol’s Comptroller contract now holds a treasury that grows by 0.148 COMP / block and spends 0.352 COMP / block on liquidity incentives. But how exactly can governance spend this treasury? The answer to this question is a bit more complicated.

Currently, the Comptroller doesn’t have a particularly clean way for governance to grant COMP to a specific address. This means that the barrier to making payments is higher than it needs to be, especially for less technical proposal authors. Moreover, it would be convenient for Governance to be able to stream payments to participants, akin to a subscription. For instance, Governance may vote to pay for development of new features via quarterly payments.

Robert’s post a few months back describes a plethora of new ways the community can contribute to Compound. The post details how COMP grants will enable a number of improvements for both smart contract changes and risk management. Recent events, such as the Dai liquidations, have increased the urgency for a COMP grant feature, as the community has proposed a number of items that require such grants. These items that have come up since Robert’s post include:

As part of our work on adding vesting to the protocol, we added these features in a pull request. Given the recent increase in urgency for a simple mechanism for governance to make payments, we will split this pull request into three:

  • Proposal to add one-time and streaming grants (PR)
  • Proposal to add vesting within the protocol (PR)
  • Proposal to set the vesting parameter based on community feedback

We wrote a high-level specification that goes through the technical components added. Furthermore, we commissioned an audit of both the grant and vesting related changes by Quantstamp. There are no major issues with the changes, in spite of the relatively large surface area touched by the vesting changes. Given that the vesting changes affect economic behaviors within the protocol, especially for those building on top of the protocol, we are taking a more cautious approach and testing these changes on testnet over the coming weeks. We request that community members who integrate Compound within their products, such as wallets and exchanges, try out vesting and provide feedback, should this change cause any disruption to your product.

We are going to test out this feature by paying Gauntlet for the development costs associated with this change. This grant will cover:

  • Development costs for CP030
  • Audit costs
  • Development costs for the future vesting proposal (which we have already implemented and is linked above)

We hope this will be the first of many COMP grants to community contributors.

You can expect to see this proposal on the Compound governance portal shortly.

18 Likes
2

I believe you previously linked somewhere on estimated gas costs with this upgrade. Could you share that again?

2 Likes
3

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

The current proposal (grants only) doesn’t affect gas consumption, but the gas
estimates for vesting can be found below


-----BEGIN PGP SIGNATURE-----

iQIyBAEBCAAdFiEEEJAuhmVduSEVN8uPKIPJySxksQ8FAl/L8I8ACgkQKIPJySxk
sQ+Enw/2K69sSM2wYiZoycS90mmisdOthcdkG2JYY4A5T01MV5Y6x+nW1jhFwJtH
YRVq3Zu8REjHHL5i/vYVcw7VF9rIaCCc05wiNvXRR69HHOOv4sElj9cpCykwVQUg
Y19vW9wni5y6GEZ8fLJuxG6vUlClNHi+3AdOJ1vfpBho+gbDSNf1Ck31HES/kngi
M6EtBPJ5RrdwfkpLeQFtbOy8+NxedezP+ZXUuNngLZYsU/6gKtPXgRnsPlOfizkU
95Oox56TDMTSz1NUFzNowc4RmNOVr41qIhjjkRZeRUtgClXzDPVkc1X4CfUMltrh
+rC+j9PFgWAQb0E/EVT2wGhllyKdCTlhCZuKIsYntagstSY4GJzqdh2ldGHS9oIc
chxcIcgOiyfFa8Yn0mOuOIePW/ZYzy7nJxkQU0Pht0p6/7UjFGpCATOxdPtLjUuS
raCUzPwrkXcG6tmG8HTkknQsB9ucxYKXtLyH2QLCSxB+6w+Kn9iNqKEe5E6bW6XO
K8jt41fuBIZxacxTzoyUweylF8MLVPwiPhrvDJCo6ZTFaImN7cY194QMzB9Ad4kQ
EiWW6XomnsyCvt8aMIvoDTwQIncaA8NVgW1Dd5uDx1hwEE7xkwyBXSFRBz4DqL+d
7wrltCgJPu7BaWr0mGRrk24fTSv21LwRHXusCMEXwYrZQsNIAw==
=q2hp
-----END PGP SIGNATURE-----

4

The proposal is now live: https://compound.finance/governance/proposals/30! Looking forward to continuing the discussion, please post any questions here, we’ll work to answer them as soon as we can.

5 Likes
5

In the spirit of community governance, could you please provide a breakdown of where the 1000 COMP grant will be going and how you got to that number? When a significant sum of community funds are involved, I believe the community should demand transparency.

3 Likes
6

I can definitely provide more info - the two main costs were:

  1. Audit - ~$50k
  2. Development - ~2 FTE equivalents, for 3 months

These changes included:

  1. Extensive edits of the Comptroller.sol contract to make room for the new functionality.
  2. Adding vesting, the grant functions and other core functionality
  3. Responding to the audit and development community feedback

You can see the details in the PR’s linked above.

6 Likes
7

There is a mistake in the code being implemented in Proposition 30, which is currently being voted in as the mainnet comptroller implementation, and can be found at 0x7d47d3f06a9c10576bc5dc87cefbf3288f96ea04

Overview:

Lines 1317-1320 of Comptroller.sol do not achieve their intended purpose, due to a missing else-statement that should surround the code on line 1321 of Comptroller.sol.

Intended Effect:

The comment states that if compSpeed is 0, the lastContributorBlock storage slot should be released so that gas can be saved.

Actual Effect:

Since line 1321 of Comptroller.sol sets lastContributorBlock to getBlockNumber() regardless of whether compSpeed is 0 or not, no gas savings are achieved. Deleting a storage slot and then immediately filling it again does not yield a net gas refund. As such, lines 1317-1320 currently do nothing useful even if compSpeed is 0; in fact, they slightly increase the gas cost of the function in all cases, due to the ‘compSpeed == 0’ comparison.

Solution:

Change this:

    if (compSpeed == 0) {
        // release storage
        delete lastContributorBlock[contributor];
    }
    lastContributorBlock[contributor] = getBlockNumber();

To this:

    if (compSpeed == 0) {
        // release storage
        delete lastContributorBlock[contributor];
    } else {
        lastContributorBlock[contributor] = getBlockNumber();
    }
6 Likes
8

@jvaqa, great catch!

Indeed, if we were to set up and then release a contributor reward, this would leave an extra storage slot in play and waste gas.

For the benefit of governance, important to add that the recommended fix is preferrable but non-urgent:

  • Consequence is low (one off storage slot paid for executing a _setContributorCompSpeed proposal)
  • It would require at least 2 additional patches to come to a situation where a contributor would both be receiving and then stop receiving a streaming grant. In practice we probably won’t see this in a while.
  • Even if that happened, the above fix could still be used to retroactively reset the storage slot by calling _setContributorCompSpeed again for that contributor and releasing the storage slot.

Governance can decide to just leave this in for the moment to be fixed in the upcoming vesting patch (or the first accepted Comptroller change thereafter).

For reference, this is the line in question: https://github.com/compound-finance/compound-protocol/blob/3244eed6beefd589f6e9ef640b822c6c615e2433/contracts/Comptroller.sol#L1320.

3 Likes
9

This observation seems to be correct to me and should have been caught prior to the proposal during community reviews. @jvaqa thank you for you time reviewing this new patch! This is what the community is all about.

I believe that this highlights a major issue in the process taken here. For such extensive code changes, a significant amount of time should be given for the community to review the changes prior to proposing. I am aware that these contracts were developed in the open and constantly had some community feedback; however, many people in the community do not have the time to constantly review code. For future proposals involving extensive protocol changes, please post on comp.xyz with the proposal intentions linking a stable PR and allow for community feedback at least a week before proposing.

8 Likes
10

Given some comments we’ve received, we wanted to clear up a few things regarding the initial grant payment. Firstly, the 1000 COMP payment covers the development expenses and the audit for the entire set of changes:

  • grantComp (PR #79)
  • Vesting (PR #71)
  • Distribution improvements

We plan to see the remaining proposals through and do not plan to request any additional grant.

Also @arr00 - as far as communication processes go, I think this 1 week policy is a great rule of thumb for future proposals. The changes have been discussed on the recent developer calls and the code has been available for review on Github for a few weeks now, but posting on the forums more frequently in the future is an obvious improvement to community involvement. We had a strong bias towards pushing this one out because we wanted to enable the community to decide how to compensate users affected by the recent DAI liquidation incident.

Hopefully, the existence of the grant function will help spearhead the discussion about how grants should function and the procedure around them. From our perspective, we wanted to set the following precedents:

  1. People who take on larger development projects, like those requiring audits, can be compensated for those changes
  2. Not all work needs to be done speculatively. Currently, anyone contributing needs to make changes on the off-chance those are later accepted by the protocol. In this case, we’ve completed all of this work ahead of time. However, hopefully by requesting payment before all of the changes are deployed, we can take a small step in direction that is more appealing to contributors.

Also - great catch by @jvaqa! We’ll send a bug bounty for identifying the issue in _setContributorCompSpeed.

5 Likes
11

Thank you @jmo , here is my address for the bug bounty reward:
0xEcb66CC9e366aF7351DbAA52Fa0b290200eC7532

I like @arr00 's suggestion for a week-long “open bug bounty” on this forum prior to code changes, I will certainly keep an eye out for future posts and help however I can.

9 Likes
12

Now that queued proposal has been executed, we’ve sent @jvaqa the bug bounty. Thanks again to everyone for the feedback!

4 Likes