KVORUM
compoundSource: Compound governor bravo · #152

Compound V2 -> V3 Migration Phase 1

executedMar 4, 2023, 04:34 PM UTCby680x683a…6c02

01Summary

AISummary by Kvorumclaude-haiku-4-5

Phase 1 of Compound V2 to V3 migration that reduces V2 COMP rewards for USDC and DAI markets by 120 COMP daily combined, redirects 120 COMP daily to V3 USDC borrowing, increases V3 ETH supply cap from 150k to 350k and WBTC from 6k to 12k, and adjusts storefront price factor from 50% to 60%.

Type
protocol addition

Key changes

  • Decrease V2 USDC supply COMP rewards from 241.20 to 211.20 daily (-30 COMP)(medium)
  • Decrease V2 USDC borrow COMP rewards from 241.20 to 211.20 daily (-30 COMP)(medium)
  • Decrease V2 DAI supply COMP rewards from 241.20 to 211.20 daily (-30 COMP)(medium)
  • Decrease V2 DAI borrow COMP rewards from 241.20 to 211.20 daily (-30 COMP)(medium)
  • Increase V3 USDC borrow COMP rewards from 161.41 to 281.41 daily (+120 COMP)(medium)
  • Increase V3 ETH supply cap from 150k to 350k(high)
  • Increase V3 WBTC supply cap from 6k to 12k(high)
  • Increase storefront price factor from 50% to 60%(medium)
Contracts0x3d9819210a31b4961b30ef54be2aed79b9c9cd3b0x316f9708bb98af7da9c68c1c3b5e79039cd336e30x1ec63b5883c3481134fd50d5daebc83ecd2e8779
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

232 words

Compound V2 -> V3 Migration Phase 1

Simple Summary

Gauntlet provides this initial proposal for Compound V2 -> V3 Migration.

Background

Following community feedback, please see below an initial migration plan to align with the community's strategic preference. See the forum post for more detail.

  • Decrease v2 daily USDC supply COMP rewards from 241.20 to 211.20 (-30)
  • Decrease v2 daily USDC borrow COMP rewards from 241.20 to 211.20 (-30)
  • Decrease v2 daily DAI supply COMP rewards from 241.20 to 211.20 (-30)
  • Decrease v2 daily DAI borrow COMP rewards from 241.20 to 211.20 (-30)
  • Increase v3 daily USDC borrow COMP rewards from 161.41 to 281.41 (+120)
  • Increase v3 ETH supply cap from 150k to 350k
  • Increase v3 WBTC supply cap from 6k to 12k
  • Increase storefront price factor from 50% to 60%

Specification

This proposal implements a number of changes using several different contracts:

  • v2 daily COMP rewards are updated using _setCompSpeeds on the Comptroller contract
  • v3 USDC daily COMP rewards are updated using setBaseTrackingBorrowSpeed on the Configurator contract
  • v3 USDC supply caps are updated using updateAssetSupplyCap on the Configurator contract
  • v3 USDC storefront price factor is updated using setStoreFrontPriceFactor on the Configurator contract

By approving this proposal, you agree that any services provided by Gauntlet shall be governed by the terms of service available at gauntlet.network/tos.

03Mismatch analysis

AIMismatch analysis by Kvorumclaude-sonnet-5
Minor discrepancy

I compared each of the eight prose bullet points to the six decoded actions. The V2 COMP speed reduction (action 0) sets identical borrow/supply speeds for cUSDC and cDAI at 29333333333333333 wei/block, which converts to ~211.2 COMP/day at ~7200 blocks/day, matching the claimed drop from 241.20 to 211.20 across all four streams (USDC/DAI, supply/borrow). The WETH and WBTC supply cap updates (actions 1 and 2) precisely match the claimed 350k and 12k caps once decimals are accounted for (18 vs 8). The USDC borrow speed increase (action 3) converts to ~281.41 COMP/day, matching the claimed increase from 161.41 to 281.41. The storefront price factor update (action 4) is exactly 60% (6e17/1e18), matching the claimed 50%->60% change. All numeric values check out after unit conversion, so there are no value or target mismatches. The one item not mentioned in the description is action 5, a deployAndUpgradeTo call that pushes a new Comet implementation to activate the configurator changes — this is standard boilerplate required by Compound V3's governance pattern whenever Configurator parameters change, not a separate substantive action, so I classified it as a low-severity omission rather than a material one. Overall the description faithfully represents the calldata with only this minor, low-risk omission, so I rate this a minor discrepancy with high confidence.

Discrepancies

  • lowomitted in description

    The proposal calldata includes a deployAndUpgradeTo call that deploys and activates a new Comet implementation reflecting the configurator changes. This step is not mentioned anywhere in the description, though it is the standard mechanical step required to make Configurator parameter changes take effect on Compound V3, so its omission is low-risk.

Generated by Kvorum
model: claude-sonnet-5
provider: anthropic
profile: anthropic-strong-v1
prompt: v1.0
generated: 2mo ago
Review the decoded actions ↗

04Actions

6 total
#0_setCompSpeeds(address[],uint256[],uint256[])chain 0x1
Target
0x3d98…cd3b
Value
0 wei
Function
_setCompSpeeds(address[],uint256[],uint256[])
Arguments
{
  "cTokens": [
    "0x39AA39c021dfbaE8faC545936693aC917d5E7563",
    "0x5d3a536E4D6DbD6114cc1Ead35777bAB948E3643"
  ],
  "borrowSpeeds": [
    "29333333333333333",
    "29333333333333333"
  ],
  "supplySpeeds": [
    "29333333333333333",
    "29333333333333333"
  ]
}
Calldata
#1updateAssetSupplyCap(address,address,uint128)chain 0x1
Target
0x316f…36e3
Value
0 wei
Function
updateAssetSupplyCap(address,address,uint128)
Arguments
{
  "asset": "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2",
  "cometProxy": "0xc3d688B66703497DAA19211EEdff47f25384cdc3",
  "newSupplyCap": "350000000000000000000000"
}
Calldata
#2updateAssetSupplyCap(address,address,uint128)chain 0x1
Target
0x316f…36e3
Value
0 wei
Function
updateAssetSupplyCap(address,address,uint128)
Arguments
{
  "asset": "0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599",
  "cometProxy": "0xc3d688B66703497DAA19211EEdff47f25384cdc3",
  "newSupplyCap": "1200000000000"
}
Calldata
#3setBaseTrackingBorrowSpeed(address,uint64)chain 0x1
Target
0x316f…36e3
Value
0 wei
Function
setBaseTrackingBorrowSpeed(address,uint64)
Arguments
{
  "cometProxy": "0xc3d688B66703497DAA19211EEdff47f25384cdc3",
  "newBaseTrackingBorrowSpeed": "3257060185185"
}
Calldata
#4setStoreFrontPriceFactor(address,uint64)chain 0x1
Target
0x316f…36e3
Value
0 wei
Function
setStoreFrontPriceFactor(address,uint64)
Arguments
{
  "cometProxy": "0xc3d688B66703497DAA19211EEdff47f25384cdc3",
  "newStoreFrontPriceFactor": "600000000000000000"
}
Calldata
#5deployAndUpgradeTo(address,address)chain 0x1
Target
0x1ec6…8779
Value
0 wei
Function
deployAndUpgradeTo(address,address)
Arguments
{
  "cometProxy": "0xc3d688B66703497DAA19211EEdff47f25384cdc3",
  "configuratorProxy": "0x316f9708bB98af7dA9c68C1C3b5e79039cD336E3"
}
Calldata

05Tally

Summed from votes

Voters0
VP participating0
Outcome (current)—
Current support—

06Voters

0 total
Filter:
VoterChoice% of totalRationale
EA0xea6c…3bf7For331K0.00%—4y ago
7D0x7d1a…b27fFor65K0.00%—4y ago
B40xb49f…7948For50K0.00%—4y ago
070x0703…961bFor50K0.00%—4y ago
130x13bd…8548For50K0.00%—4y ago
880x88fb…3981For42.8K0.00%—4y ago
DAdakeshi.eth0xe3c9…6b21For21.3K0.00%—4y ago
0A0x0a09…b92eFor15K0.00%—4y ago
230x2380…b5f2For11K0.00%—4y ago
660x66cd…65f9For91.70.00%—4y ago
840x84e3…5a95For39.60.00%—4y ago
230x2368…e99dFor30.00%—4y ago
940x9497…6eeaFor2.80.00%—4y ago
DD0xdd4a…86baFor2.80.00%—4y ago
E10xe1d1…951aFor2.80.00%—4y ago
050x05ac…646dFor2.70.00%—4y ago
610x61d9…b63fFor2.70.00%—4y ago
F90xf977…5d89For2.70.00%—4y ago
B90xb933…8dd1For1.10.00%—4y ago
030x0389…72c6For0.80.00%—4y ago
8B0x8bc8…7276For0.60.00%—4y ago
E40xe459…e666For0.50.00%—4y ago
860x8679…2c0fFor0.40.00%—4y ago
030x0329…5dafFor0.30.00%—4y ago
8F0x8f2a…5272For0.30.00%—4y ago
890x8960…3a8cFor0.30.00%—4y ago
710x7121…4461For0.20.00%—4y ago
520x5290…35b9For0.20.00%—4y ago
320x3274…ca96For0.20.00%—4y ago
4C0x4cb5…e66bFor0.10.00%—4y ago
A20xa2b3…fe3fFor0.10.00%—4y ago
F80xf84c…9a63For0.10.00%—4y ago
160x16c4…d71fFor0.10.00%—4y ago
2E0x2eb0…2428For00.00%—4y ago
910x917b…8ad6For00.00%—4y ago
450x455d…099dFor00.00%—4y ago
F00xf097…359aFor00.00%—4y ago
2F0x2fe7…6f04For00.00%—4y ago
130x136d…269aFor00.00%—4y ago
410x4121…3ad4For00.00%—4y ago
880x88f6…0ec0For00.00%—4y ago
7A0x7ade…7f90For00.00%—4y ago
A70xa78f…0e44For00.00%—4y ago
Showing 43

07Forum

AIForum synthesis by Kvorumclaude-sonnet-5
sentiment · mixedthread · constructive

Arguments for

  • Gauntlet's original plan justifies migrating COMP incentives from V2 to V3, increasing V3 supply caps, and raising the storefront price factor to encourage migration while managing protocol risk.— pauljlei
  • Increasing the V2 USDC reserve factor could be justified strategically because V2 and V3 USDC serve different use cases, with V2 shifting toward volatile-asset borrowing/shorting rather than stablecoin borrowing.— pauljlei
  • COMP incentive migration (increasing V3 borrow rewards while trimming V2 rewards) can target the largest non-recursive V2 borrowers to encourage their migration to V3 with manageable reserve risk.— pauljlei

Arguments against

  • The migration strategy should rely on COMP incentive shifts rather than reserve factor increases, since RF hikes are punitive to users who choose to remain on V2 rather than encouraging migration.— MathisGD, allthecolors, WintermuteGovernance
  • Increasing the V2 USDC reserve factor does not inherently reduce protocol risk, so it lacks a risk-based justification.— MathisGD
  • V2 has significant integrations beyond shorting/collateral use cases (aggregators, leveraged token strategies, interest rate swaps), so framing V2 USDC as solely for collateral purposes and doubling its RF unfairly penalizes these other legitimate uses.— OneTrueKirk

Unresolved concerns

  • Whether COMP incentive migration alone would be sufficient to drive migration without needing punitive reserve factor increases was debated but not fully tested before the proposal moved forward.— MathisGD, allthecolors, WintermuteGovernance
  • The risk that increasing V3 COMP borrow rewards could push utilization above 86%, causing reserve losses, was acknowledged by Gauntlet but not further challenged or resolved in discussion.— pauljlei
  • The risk that new migrating users could have riskier health factors, causing unforeseen market downturn risk, was flagged by Gauntlet without community follow-up or pushback.— pauljlei

Notable participants

  • pauljleiProposer representing Gauntlet who authored the migration plan, responded to community feedback, and updated the proposal before it went to an on-chain vote.
  • MathisGDRaised the initial objection to the V2 reserve factor increase, arguing it makes V2 worse without reducing risk.
  • allthecolorsSupported MathisGD's concern, distinguishing between incentivizing migration versus punitively discouraging V2 use.
  • WintermuteGovernanceBacked the preference for using COMP incentives as the primary migration lever over reserve factor changes.
  • OneTrueKirkReinforced concerns about the reserve factor increase from an integrator's perspective, highlighting V2's diverse use cases.
Generated by Kvorum
model: claude-sonnet-5
provider: anthropic
profile: anthropic-strong-v1
prompt: v1.0
generated: 2mo ago
Open the thread ↗