COMP Speed Recalibration
01Summary
Proposal to recalibrate COMP token distribution speeds across 9 active Compound markets based on 6 months of usage data. Each market receives a fixed 10% allocation plus variable rewards, enabling future A/B testing of incentive mechanisms. Implementation involves adjusting COMP emission rates across multiple market contracts.
- Type
- parameter change
Key changes
- Recalibrate COMP distribution speeds across markets based on 6-month usage data instead of arbitrary initial parameters(high)
- Implement fixed 10% allocation of COMP rewards spread evenly across 9 active markets(high)
- Split market rewards into fixed and variable quantities to enable A/B testing of optimal incentive levels(medium)
- Adjust individual market COMP emission rates ranging from 1.95e15 to 67e15 wei per block(medium)
Notable concerns
- Initial COMP distribution parameters were set arbitrarily and required reset
- Proposal relies on community forum discussion for technical details and rationale
Generated by Kvorum
02Description
COMP Speed Recalibration
Summary
As Robert Leshner mentioned in his forum post, the community now has the power to control COMP distribution across markets after Gauntlet's recent proposal (#33). This will allow the protocol to better and more efficiently manage how COMP is used to improve and further the protocol's interests. Given that the initial COMP distribution numbers were set somewhat arbitrarily, it has become clear that it is worth resetting the parameters based on usage over the last six months. The refreshed numbers proposed will be used for A/B testing optimal COMP emission quantities in future proposals.
In a comp.xyz forum post, Robert and Sirokko have put forth reasonable suggestions that we believe would improve upon the existing values. Both of their values for COMP distribution were quite similar and we chose Sirokko's numbers for two reasons:
- All markets are given a fixed quantity (10% of rewards spread evenly across the 9 active markets) of COMP rewards
- Splitting each market's COMP rewards into a fixed quantity (common to all markets) and a variable quantity makes it easy to analyze improvements in future A/B tests for incentives
Please read the forum post for more details.
Acknowledgments
- Robert Leshner: For starting the discussion and putting out the first distribution numbers
- Sirokko: For providing a coherent methodology for this refresh
- Hsien-Tang Kao: For analyzing 1-step recursive borrowing in existing markets
References
03Mismatch analysis
The description explains that this proposal recalibrates COMP distribution speeds across the 9 active Compound markets, using a fixed+variable methodology proposed by Sirokko, and explicitly defers exact numbers to a linked forum post rather than stating them in the proposal body. The calldata consists of exactly 9 _setCompSpeed calls, one per market address, each setting a new COMP emission rate — this structurally matches the described action (a market-wide speed reset) in both scope (9 markets) and mechanism (setting speeds via the standard Comptroller function). There is no target mismatch, no unrelated action, and no evidence of value manipulation beyond what the description authorizes, since the description intentionally does not enumerate specific values and instead points to the forum post as the source of truth. Because the specific COMP speed values are not stated in the prose itself, a full numeric cross-check against 'Sirokko's numbers' is not possible from the provided materials, which slightly lowers confidence but does not constitute a discrepancy per the guidelines (summarization deferring detail to a linked source is legitimate). Overall, the on-chain actions are consistent with what the proposal claims it will do: reset COMP emission speeds across the nine active markets per the community-discussed methodology.
Discrepancies
- lowomitted in description
The proposal text does not restate the actual numeric COMP speeds being set (it defers entirely to an external forum post). This is a legitimate summarization for a recalibration proposal, but it means the specific values (e.g. 0.067, 0.01075, 0.00195, 0.005 COMP/block) cannot be verified word-for-word against the prose itself — only against the referenced forum post, which is outside the scope of the on-chain description provided.
“Please read the forum post for more details.”
Generated by Kvorum
04Actions
- Target
- 0x3d98…cd3b
- Value
- 0 wei
- Function
- _setCompSpeed(address,uint256)
- Arguments
{ "0": "0x4Ddc2D193948926D02f9B1fE9e1daa0718270ED5", "1": "10750000000000000" }- Calldata
- Target
- 0x3d98…cd3b
- Value
- 0 wei
- Function
- _setCompSpeed(address,uint256)
- Arguments
{ "0": "0xC11b1268C1A384e55C48c2391d8d480264A3A7F4", "1": "10750000000000000" }- Calldata
- Target
- 0x3d98…cd3b
- Value
- 0 wei
- Function
- _setCompSpeed(address,uint256)
- Arguments
{ "0": "0x39AA39c021dfbaE8faC545936693aC917d5E7563", "1": "67000000000000000" }- Calldata
- Target
- 0x3d98…cd3b
- Value
- 0 wei
- Function
- _setCompSpeed(address,uint256)
- Arguments
{ "0": "0xf650C3d88D12dB855b8bf7D11Be6C55A4e07dCC9", "1": "9650000000000000" }- Calldata
- Target
- 0x3d98…cd3b
- Value
- 0 wei
- Function
- _setCompSpeed(address,uint256)
- Arguments
{ "0": "0x5d3a536E4D6DbD6114cc1Ead35777bAB948E3643", "1": "67000000000000000" }- Calldata
- Target
- 0x3d98…cd3b
- Value
- 0 wei
- Function
- _setCompSpeed(address,uint256)
- Arguments
{ "0": "0x6C8c6b02E7b2BE14d4fA6022Dfd6d75921D90E4E", "1": "1950000000000000" }- Calldata
- Target
- 0x3d98…cd3b
- Value
- 0 wei
- Function
- _setCompSpeed(address,uint256)
- Arguments
{ "0": "0xB3319f5D18Bc0D84dD1b4825Dcde5d5f7266d407", "1": "1950000000000000" }- Calldata
- Target
- 0x3d98…cd3b
- Value
- 0 wei
- Function
- _setCompSpeed(address,uint256)
- Arguments
{ "0": "0x35A18000230DA775CAc24873d00Ff85BccdeD550", "1": "1950000000000000" }- Calldata
- Target
- 0x3d98…cd3b
- Value
- 0 wei
- Function
- _setCompSpeed(address,uint256)
- Arguments
{ "0": "0x70e36f6BF80a52b3B46b3aF8e106CC0ed743E8e4", "1": "5000000000000000" }- Calldata
05Tally
Summed from votes
06Voters
| Voter | Choice | % of total | Rationale | ||
|---|---|---|---|---|---|
| 660x6626…c35c | For | 126.1K | 0.00% | — | 6y ago |
| AC0xac57…faf6 | For | 105.1K | 0.00% | — | 6y ago |
| 540x54a3…e189 | For | 100.1K | 0.00% | — | 6y ago |
| 7E0x7e4a…19fa | For | 100K | 0.00% | — | 6y ago |
| 450x458c…730e | For | 50K | 0.00% | — | 6y ago |
| E50xe5b5…4b03 | For | 29.9K | 0.00% | — | 6y ago |
| 870x879d…0f11 | For | 22K | 0.00% | — | 6y ago |
| DAdakeshi.eth0xe3c9…6b21 | For | 20K | 0.00% | — | 6y ago |
| 140x1494…3c2b | For | 18.8K | 0.00% | — | 6y ago |
| 7F0x7f89…58c4 | For | 12K | 0.00% | — | 6y ago |
| 5B0x5b97…66c2 | For | 10K | 0.00% | — | 6y ago |
| B00xb032…449b | For | 9.1K | 0.00% | — | 6y ago |
| 580x582c…d468 | For | 9K | 0.00% | — | 6y ago |
| 8D0x8d07…a265 | For | 7.5K | 0.00% | — | 6y ago |
| B80xb8a6…6406 | For | 5K | 0.00% | — | 6y ago |
| 900x905c…e25a | For | 5K | 0.00% | — | 6y ago |
| FC0xfc04…5ac2 | For | 2.3K | 0.00% | — | 6y ago |
| 7F0x7f84…4d0b | Against | 158.2 | 0.00% | — | 6y ago |
| 9B0x9b68…2984 | Against | 100.1 | 0.00% | — | 6y ago |
| 030x03f0…7618 | Against | 20.3 | 0.00% | — | 6y ago |
| 840x84e3…5a95 | For | 10.8 | 0.00% | — | 6y ago |
| E00xe0b3…2514 | For | 8 | 0.00% | — | 6y ago |
| 930x9348…0c53 | For | 2.2 | 0.00% | — | 6y ago |
| FB0xfb30…ea3f | For | 1.3 | 0.00% | — | 6y ago |
| 420x42ed…d691 | For | 1 | 0.00% | — | 6y ago |
| 850x8579…213a | For | 0.5 | 0.00% | — | 6y ago |
| 850x8590…1637 | For | 0.3 | 0.00% | — | 6y ago |
| 020x02af…6516 | For | 0.3 | 0.00% | — | 6y ago |
| JTjthrack.eth0x44c6…aabd | For | 0.3 | 0.00% | — | 6y ago |
| F60xf67e…7bf6 | For | 0.2 | 0.00% | — | 6y ago |
| 3E0x3e61…322b | For | 0.2 | 0.00% | — | 6y ago |
| A00xa0e4…ea1e | For | 0.1 | 0.00% | — | 6y ago |
| 400x4007…7f4e | For | 0.1 | 0.00% | — | 6y ago |
| 6F0x6f7a…c97b | For | 0.1 | 0.00% | — | 6y ago |
| 2E0x2eb4…8c26 | For | 0.1 | 0.00% | — | 6y ago |
| 000x0006…13f5 | For | 0 | 0.00% | — | 6y ago |
| A40xa455…eff3 | For | 0 | 0.00% | — | 6y ago |
| E00xe02c…5e3e | For | 0 | 0.00% | — | 6y ago |
| 1F0x1f76…f6dd | For | 0 | 0.00% | — | 6y ago |
| H0h0neybad9er.eth0x26a2…4cbe | For | 0 | 0.00% | — | 6y ago |
07Forum
- COMP Distribution Speeds ↗discourse · high confidence
Arguments for
- The current COMP speed allocation is an arbitrary relic of when Proposal 033 passed and should not be anchored to as a baseline; governance now has responsibility to actively (re)calibrate it.— rleshner, haseebq
- COMP emissions should be optimized using rigorous, data-driven experiments (A/B-style hypothesis testing) rather than left static, since $125M/year in incentives is a large spend whose ROI is unclear.— tarun, haseebq, jthrack
- Distribution should shift away from 'farmers' who exploit recursive leverage/high-rate markets toward genuine long-term users and governance participants.— rleshner, Sirokko, dabar90, jthrack
- Important collateral assets like ETH and WBTC receive negligible COMP relative to their importance and should get a meaningful baseline allocation to change user behavior and deepen collateral markets.— rleshner, dabar90, Sirokko
- Increasing the COMP allocation to the COMP market itself acts like a staking reward that incentivizes long-term holding rather than immediate selling.— rleshner, tarun, Sirokko
- COMP distribution's core purpose is to decentralize protocol ownership, not merely minimize customer acquisition cost, so reallocation should be judged by its effect on decentralization.— aklamun, jthrack
- Similar assets (e.g., BAT/ZRX/UNI or stablecoins) can be grouped and standardized to simplify and rationalize the speed-setting process.— rleshner, dabar90, Sirokko
Arguments against
- The existing distribution 'isn't broken' and intuitively tracks interest rates, so major changes should wait until effects of other initiatives like vesting are observed.— lay2000lbs
- Manually adjusting COMP speeds via governance controlled by a small number of large token holders undermines decentralization and looks like 'big business' behavior rather than systematic, transparent adjustment.— Fishbtc, massnomis
- Reducing rewards to recursive-leverage markets like DAI may simply push farmers to recursively leverage other collateral markets (ETH, WBTC), artificially inflating borrow rates there instead of solving the underlying problem.— trader-geo
- The proposal process was rushed (posted with a short voting window) and lacked the depth of academic/economic rigor warranted for a decision of this magnitude, and should be postponed for a more dynamic, decentralized economic model.— massnomis
- The vesting/lockup mechanism that is supposed to complement the new speeds was not yet well-defined before the reallocation proposal moved forward.— massnomis, jthrack
Unresolved concerns
- Whether reducing rewards to stablecoin recursive-leverage farming actually curbs farming overall or just displaces it into other collateral markets, inflating their borrow rates.— trader-geo, jthrack, aklamun
- Governance allocation decisions are effectively made by a small number of large holders, raising decentralization/legitimacy concerns about the process itself.— Fishbtc
- Whether protocol reserves and a treasury (funded by reduced COMP emissions or direct COMP sales) should be prioritized alongside or instead of speed recalibration was raised but explicitly deferred to a separate discussion.— Sirokko, jthrack
- Design of a vesting or 'anti-farmer' penalty/staking mechanism to complement speed changes remained conceptual and unresolved.— mrhen, massnomis, jthrack
- The inability to set different supplier/borrower split ratios (e.g., 75/25 for collateral markets) without a protocol code change was acknowledged as a limitation but left as a future improvement rather than resolved.— Sirokko, rleshner
Notable participants
- rleshnerOpened the thread with guiding questions, synthesized community feedback into a baseline allocation proposal, and closed the thread noting the changes were enacted via Proposal 035.
- tarunGauntlet researcher who proposed a rigorous experimental/hypothesis-testing framework and provided data analysis on recursive borrowing to inform allocation choices.
- SirokkoProvided a detailed alternative allocation model with a fixed baseline per market plus targeted incentives, and argued extensively for treasury/reserve considerations.
- jthrackAdvocated for net borrow/supply rate balancing and reallocating COMP toward development or treasury diversification to reduce farming incentives.
- aklamunReframed the debate around decentralization of ownership as the primary goal and proposed a max(lend reward, borrow reward) mechanism to curb recursive leverage.
- haseebqStrongly endorsed moving away from the arbitrary status quo toward an optimized, data-informed emission rate.
- lay2000lbsRepresented a cautious, status-quo-leaning viewpoint urging minimal changes.
- FishbtcRaised concerns about governance centralization and the optics of manual reallocation by a small group of holders.
- massnomisCriticized the pace and rigor of the governance process and called for a more dynamic, decentralized economic model before passing changes.
- dabar90Highlighted opportunity costs for ETH holders and questioned Compound's user growth relative to competitors, supporting reduced stablecoin incentives.
Generated by Kvorum
08Similar proposals
- compoundexecutedSplit COMP rewards distribution and bug fixes79%
- compoundexecutedCOMP Rewards Adjustments - Kickstart Rewards: Step One76%
- compounddefeatedCOMP Rewards Adjustments - Kickstart Rewards: Step Two76%
- compoundexecutedCOMP Distribution Patch75%
- compoundexecutedDistribute COMP to Users73%
- compoundexecutedAdjusting COMP distribution speed to match Ethereum network block time and increasing higher-risk assets Reserve Factor73%
- compoundexecutedInitialize Compound III COMP Distribution73%
- compoundexecutedReduce COMP emissions by 20%72%
- compoundexecutedRemove automatic COMP claims and COMP speed refresh71%
- compounddefeated[Temp. Check] Should Compound retroactively distribute COMP tokens to early users?70%