KVORUM
compoundSource: Compound governor bravo · #352

[Gauntlet] Compound v2 Deprecation (10/07/2024)

executedOct 26, 2024, 10:13 AM UTCby7B0x7b3c…cc33

01Summary

AISummary by Kvorumclaude-haiku-4-5

Gauntlet recommends reducing collateral factors for 8 assets (AAVE, BAT, LINK, MKR, SUSHI, UNI, YFI, ZRX) and making minor adjustments to WBTC as part of Compound v2 deprecation strategy. These changes reduce the amount of these assets that can be used as collateral, lowering protocol risk during the migration away from v2.

Type
parameter change

Key changes

  • AAVE collateral factor decreased from 18% to 8%(high)
  • YFI collateral factor decreased from 20% to 10%(high)
  • UNI collateral factor decreased from 50% to 40%(high)
  • MKR collateral factor decreased from 23% to 18%(medium)
  • LINK collateral factor decreased from 28% to 26%(medium)
  • SUSHI collateral factor decreased from 17% to 12%(medium)
  • BAT collateral factor decreased from 35% to 34%(low)
  • ZRX collateral factor decreased from 10% to 0%(medium)

Notable concerns

  • These parameter changes are part of Compound v2 deprecation and users holding these assets as collateral will have reduced borrowing capacity
Contracts0x3d9819210a31b4961b30ef54be2aed79b9c9cd3b0xccf4429db6322d5c611ee964527d42e5d685dd6a
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

168 words

[Gauntlet] Compound v2 Deprecation (10/07/2024)

Summary

Gauntlet recommends the following risk recommendations to the protocol:

  • Decrease AAVE Collateral Factor from 18% to 8%
  • Decrease BAT Collateral Factor from 35% to 34%
  • Decrease LINK Collateral Factor from 28% to 26%
  • Decrease MKR Collateral Factor from 23% to 18%
  • Decrease SUSHI Collateral Factor from 17% to 12%
  • Decrease UNI Collateral Factor from 50% to 40%
  • Decrease YFI Collateral Factor from 20% to 10%
  • Decrease ZRX Collateral Factor from 10% to 0%
  • Decrease for WBTC Collateral Factor from 70% to 69%
  • Increase for WBTC Reserve Factor from 20% to 30%

Motivation

This recommendation aims to proceed with Compound v2 comet deprecation.

Full proposal and forum discussions can be found here

Specification

The proposal updates the parameters by using the respective methods on the Configurator.

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
Consistent

I matched each of the 10 prose bullet points to a corresponding decoded action by (a) resolving the target cToken address to the asset named in the prose and (b) converting the 18-decimal fixed-point calldata value to a percentage for comparison against the stated target percentage. All ten pairs align exactly: AAVE→8% (action 0), BAT→34% (action 1), LINK→26% (action 2), MKR→18% (action 3), SUSHI→12% (action 4), UNI→40% (action 5), WBTC reserve factor→30% (action 6, note this targets the cToken address used for _setReserveFactor rather than the Configurator-per-cToken CF calls, but this is expected since reserve factor is set on the cToken itself), WBTC collateral factor→69% (action 7), YFI→10% (action 8), and ZRX→0% (action 9). No extra actions exist in the calldata beyond these ten, and no claimed action in the description is missing from the calldata. The only oddity is the ordering (WBTC reserve factor action appears before the WBTC collateral factor action in the array), but ordering does not affect the substance of what will execute and is not something the description makes any claim about. Overall, this proposal's prose is a faithful, complete summary of the on-chain actions with no value, target, or omission discrepancies of note.

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

04Actions

10 total
#0_setCollateralFactor(address,uint256)chain 0x1
Target
0x3d98…cd3b
Value
0 wei
Function
_setCollateralFactor(address,uint256)
Arguments
{
  "0": "0xe65cdB6479BaC1e22340E4E755fAE7E509EcD06c",
  "1": "80000000000000000"
}
Calldata
#1_setCollateralFactor(address,uint256)chain 0x1
Target
0x3d98…cd3b
Value
0 wei
Function
_setCollateralFactor(address,uint256)
Arguments
{
  "0": "0x6C8c6b02E7b2BE14d4fA6022Dfd6d75921D90E4E",
  "1": "340000000000000000"
}
Calldata
#2_setCollateralFactor(address,uint256)chain 0x1
Target
0x3d98…cd3b
Value
0 wei
Function
_setCollateralFactor(address,uint256)
Arguments
{
  "0": "0xFAce851a4921ce59e912d19329929CE6da6EB0c7",
  "1": "260000000000000000"
}
Calldata
#3_setCollateralFactor(address,uint256)chain 0x1
Target
0x3d98…cd3b
Value
0 wei
Function
_setCollateralFactor(address,uint256)
Arguments
{
  "0": "0x95b4eF2869eBD94BEb4eEE400a99824BF5DC325b",
  "1": "180000000000000000"
}
Calldata
#4_setCollateralFactor(address,uint256)chain 0x1
Target
0x3d98…cd3b
Value
0 wei
Function
_setCollateralFactor(address,uint256)
Arguments
{
  "0": "0x4B0181102A0112A2ef11AbEE5563bb4a3176c9d7",
  "1": "120000000000000000"
}
Calldata
#5_setCollateralFactor(address,uint256)chain 0x1
Target
0x3d98…cd3b
Value
0 wei
Function
_setCollateralFactor(address,uint256)
Arguments
{
  "0": "0x35A18000230DA775CAc24873d00Ff85BccdeD550",
  "1": "400000000000000000"
}
Calldata
#6_setReserveFactor(uint256)chain 0x1
Target
0xccf4…dd6a
Value
0 wei
Function
_setReserveFactor(uint256)
Arguments
{
  "0": "300000000000000000"
}
Calldata
#7_setCollateralFactor(address,uint256)chain 0x1
Target
0x3d98…cd3b
Value
0 wei
Function
_setCollateralFactor(address,uint256)
Arguments
{
  "0": "0xccF4429DB6322D5C611ee964527D42E5d685DD6a",
  "1": "690000000000000000"
}
Calldata
#8_setCollateralFactor(address,uint256)chain 0x1
Target
0x3d98…cd3b
Value
0 wei
Function
_setCollateralFactor(address,uint256)
Arguments
{
  "0": "0x80a2AE356fc9ef4305676f7a3E2Ed04e12C33946",
  "1": "100000000000000000"
}
Calldata
#9_setCollateralFactor(address,uint256)chain 0x1
Target
0x3d98…cd3b
Value
0 wei
Function
_setCollateralFactor(address,uint256)
Arguments
{
  "0": "0xB3319f5D18Bc0D84dD1b4825Dcde5d5f7266d407",
  "1": "0"
}
Calldata

05Tally

Summed from votes

Voters25
VP participating897.7K
Outcome (current)For
Current support100%

06Voters

25 total

No votes recorded yet.

07Forum

AIForum synthesis by Kvorumclaude-haiku-4-5
sentiment · favorablethread · constructive

Arguments for

  • Deprecating Compound v2 is necessary to reduce fragmentation and concentrate liquidity on the superior v3 infrastructure.— Gauntlet
  • Collateral factor reductions can be implemented gradually to minimize liquidation risk while encouraging migration to v3.— Gauntlet
  • Analysis shows no risk-off liquidations would occur from the proposed collateral factor decreases.— Gauntlet

Arguments against

None surfaced.

Unresolved concerns

  • Whether users with low health factors (below 1.17) who become significantly closer to liquidation will be adequately warned or assisted in migrating to v3.— Gauntlet
  • Whether the proposed collateral factor changes are aggressive enough or if further reductions may be necessary to achieve full v2 deprecation.— Gauntlet
  • How to balance deprecation speed against user experience and fairness for positions that will face increased liquidation risk.— Gauntlet

Notable participants

  • GauntletProposer of the v2 deprecation strategy with detailed risk analysis and collateral factor recommendations.
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Open the thread ↗