KVORUM
compoundSource: Compound governor oz · #579

Ethereum Supply cap Reduction Across Non-USD Based Comets

executedMay 6, 2026, 04:05 PM UTCby890x89f2…e8db

01Summary

AISummary by Kvorumclaude-haiku-4-5

This proposal reduces supply caps for various ETH-based and BTC-based assets across three Compound Comet markets on Ethereum (cWstETHv3, cWETHv3, and cWBTCv3) based on current utilization and risk parameters. Most assets have their caps reduced to zero, while select assets like tETH, weETH, pufETH, and ezETH receive adjusted caps.

Type
parameter change

Key changes

  • cWstETHv3 market: weETH and ezETH supply caps reduced to 0, tETH supply cap set to 44(high)
  • cWETHv3 market: wOETH, tBTC, rswETH, rETH, osETH, and ETHx supply caps reduced to 0(high)
  • cWETHv3 market: weETH supply cap set to 3,860, tETH to 1,545, pufETH to 105, and ezETH to 33,163(high)
  • cWBTCv3 market: pumpBTC and LBTC supply caps reduced to 0(high)
  • Comet implementation upgrades deployed across all three markets to apply the supply cap changes(medium)
Contracts0x3D0bb1ccaB520A66e607822fC55BC921738fAFE30xA17581A9E3356d9A858b789D68B4d866e593aE940xe85Dc543813B8c2CFEaAc371517b925a166a9293
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

158 words

Ethereum Supply cap Reduction Across Non-USD Based Comets

Proposal summary

This proposal updates supply caps for a number of assets across the non-usd based Mainnet markets. The supply caps for the affected assets are being updated based on their current utilization and risk parameters.

Further detailed information can be found on the corresponding proposal pull request and forum discussion.

Proposal actions

1 - 4. Updates supply caps for weETH and ezETH to 0 and tETH to 44 on cWstETHv3 market and upgrades the Comet implementation to apply the changes.

5 - 15. Updates supply caps for wOETH, tBTC, rswETH, rETH, osETH, and ETHx to 0 and weETH to 3,860, tETH to 1,545, pufETH to 105, and ezETH to 33,163 on cWETHv3 market and upgrades the Comet implementation to apply the changes.

16 - 18. Updates supply caps for pumpBTC and LBTC to 0 on cWBTCv3 market and upgrades the Comet implementation to apply the changes.

03Mismatch analysis

AIMismatch analysis by Kvorumclaude-sonnet-5
Consistent

I mapped each of the 18 decoded actions to the corresponding token addresses (weETH, ezETH, tETH, wOETH, tBTC, rswETH, rETH, osETH, ETHx, pufETH, pumpBTC, LBTC) and the three comet proxies (cWstETHv3, cWETHv3, cWBTCv3). All numeric supply cap values in the calldata, once converted from 18-decimal wei to whole token units, exactly match the figures stated in the description (e.g., 44e18 = 44 tETH, 3860e18 = 3,860 weETH, 33163e18 = 33,163 ezETH, etc.). The zero-cap assets listed in the prose (weETH/ezETH for cWstETHv3; wOETH/tBTC/rswETH/rETH/osETH/ETHx for cWETHv3; pumpBTC/LBTC for cWBTCv3) all correspond correctly to their target comet proxies. Each market's action group also includes a deployAndUpgradeTo call targeting the correct comet proxy, matching the description's claim that the Comet implementation is upgraded to apply the changes. No values, targets, or omitted/extra actions were found. The description accurately and completely represents the calldata's effects, so the proposal is consistent with no discrepancies to flag.

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

04Actions

18 total
#0updateAssetSupplyCap(address,address,uint128)chain 0x1
Target
0x316f…36e3
Value
0 wei
Function
updateAssetSupplyCap(address,address,uint128)
Arguments
{
  "asset": "0xCd5fE23C85820F7B72D0926FC9b05b43E359b7ee",
  "cometProxy": "0x3D0bb1ccaB520A66e607822fC55BC921738fAFE3",
  "newSupplyCap": "0"
}
Calldata
#1updateAssetSupplyCap(address,address,uint128)chain 0x1
Target
0x316f…36e3
Value
0 wei
Function
updateAssetSupplyCap(address,address,uint128)
Arguments
{
  "asset": "0xbf5495Efe5DB9ce00f80364C8B423567e58d2110",
  "cometProxy": "0x3D0bb1ccaB520A66e607822fC55BC921738fAFE3",
  "newSupplyCap": "0"
}
Calldata
#2updateAssetSupplyCap(address,address,uint128)chain 0x1
Target
0x316f…36e3
Value
0 wei
Function
updateAssetSupplyCap(address,address,uint128)
Arguments
{
  "asset": "0xD11c452fc99cF405034ee446803b6F6c1F6d5ED8",
  "cometProxy": "0x3D0bb1ccaB520A66e607822fC55BC921738fAFE3",
  "newSupplyCap": "44000000000000000000"
}
Calldata
#3deployAndUpgradeTo(address,address)chain 0x1
Target
0x1ec6…8779
Value
0 wei
Function
deployAndUpgradeTo(address,address)
Arguments
{
  "cometProxy": "0x3D0bb1ccaB520A66e607822fC55BC921738fAFE3",
  "configuratorProxy": "0x316f9708bB98af7dA9c68C1C3b5e79039cD336E3"
}
Calldata
#4updateAssetSupplyCap(address,address,uint128)chain 0x1
Target
0x316f…36e3
Value
0 wei
Function
updateAssetSupplyCap(address,address,uint128)
Arguments
{
  "asset": "0xDcEe70654261AF21C44c093C300eD3Bb97b78192",
  "cometProxy": "0xA17581A9E3356d9A858b789D68B4d866e593aE94",
  "newSupplyCap": "0"
}
Calldata
#5updateAssetSupplyCap(address,address,uint128)chain 0x1
Target
0x316f…36e3
Value
0 wei
Function
updateAssetSupplyCap(address,address,uint128)
Arguments
{
  "asset": "0x18084fbA666a33d37592fA2633fD49a74DD93a88",
  "cometProxy": "0xA17581A9E3356d9A858b789D68B4d866e593aE94",
  "newSupplyCap": "0"
}
Calldata
#6updateAssetSupplyCap(address,address,uint128)chain 0x1
Target
0x316f…36e3
Value
0 wei
Function
updateAssetSupplyCap(address,address,uint128)
Arguments
{
  "asset": "0xFAe103DC9cf190eD75350761e95403b7b8aFa6c0",
  "cometProxy": "0xA17581A9E3356d9A858b789D68B4d866e593aE94",
  "newSupplyCap": "0"
}
Calldata
#7updateAssetSupplyCap(address,address,uint128)chain 0x1
Target
0x316f…36e3
Value
0 wei
Function
updateAssetSupplyCap(address,address,uint128)
Arguments
{
  "asset": "0xae78736Cd615f374D3085123A210448E74Fc6393",
  "cometProxy": "0xA17581A9E3356d9A858b789D68B4d866e593aE94",
  "newSupplyCap": "0"
}
Calldata
#8updateAssetSupplyCap(address,address,uint128)chain 0x1
Target
0x316f…36e3
Value
0 wei
Function
updateAssetSupplyCap(address,address,uint128)
Arguments
{
  "asset": "0xf1C9acDc66974dFB6dEcB12aA385b9cD01190E38",
  "cometProxy": "0xA17581A9E3356d9A858b789D68B4d866e593aE94",
  "newSupplyCap": "0"
}
Calldata
#9updateAssetSupplyCap(address,address,uint128)chain 0x1
Target
0x316f…36e3
Value
0 wei
Function
updateAssetSupplyCap(address,address,uint128)
Arguments
{
  "asset": "0xA35b1B31Ce002FBF2058D22F30f95D405200A15b",
  "cometProxy": "0xA17581A9E3356d9A858b789D68B4d866e593aE94",
  "newSupplyCap": "0"
}
Calldata
#10updateAssetSupplyCap(address,address,uint128)chain 0x1
Target
0x316f…36e3
Value
0 wei
Function
updateAssetSupplyCap(address,address,uint128)
Arguments
{
  "asset": "0xCd5fE23C85820F7B72D0926FC9b05b43E359b7ee",
  "cometProxy": "0xA17581A9E3356d9A858b789D68B4d866e593aE94",
  "newSupplyCap": "3860000000000000000000"
}
Calldata
#11updateAssetSupplyCap(address,address,uint128)chain 0x1
Target
0x316f…36e3
Value
0 wei
Function
updateAssetSupplyCap(address,address,uint128)
Arguments
{
  "asset": "0xD11c452fc99cF405034ee446803b6F6c1F6d5ED8",
  "cometProxy": "0xA17581A9E3356d9A858b789D68B4d866e593aE94",
  "newSupplyCap": "1545000000000000000000"
}
Calldata
#12updateAssetSupplyCap(address,address,uint128)chain 0x1
Target
0x316f…36e3
Value
0 wei
Function
updateAssetSupplyCap(address,address,uint128)
Arguments
{
  "asset": "0xD9A442856C234a39a81a089C06451EBAa4306a72",
  "cometProxy": "0xA17581A9E3356d9A858b789D68B4d866e593aE94",
  "newSupplyCap": "105000000000000000000"
}
Calldata
#13updateAssetSupplyCap(address,address,uint128)chain 0x1
Target
0x316f…36e3
Value
0 wei
Function
updateAssetSupplyCap(address,address,uint128)
Arguments
{
  "asset": "0xbf5495Efe5DB9ce00f80364C8B423567e58d2110",
  "cometProxy": "0xA17581A9E3356d9A858b789D68B4d866e593aE94",
  "newSupplyCap": "33163000000000000000000"
}
Calldata
#14deployAndUpgradeTo(address,address)chain 0x1
Target
0x1ec6…8779
Value
0 wei
Function
deployAndUpgradeTo(address,address)
Arguments
{
  "cometProxy": "0xA17581A9E3356d9A858b789D68B4d866e593aE94",
  "configuratorProxy": "0x316f9708bB98af7dA9c68C1C3b5e79039cD336E3"
}
Calldata
#15updateAssetSupplyCap(address,address,uint128)chain 0x1
Target
0x316f…36e3
Value
0 wei
Function
updateAssetSupplyCap(address,address,uint128)
Arguments
{
  "asset": "0xF469fBD2abcd6B9de8E169d128226C0Fc90a012e",
  "cometProxy": "0xe85Dc543813B8c2CFEaAc371517b925a166a9293",
  "newSupplyCap": "0"
}
Calldata
#16updateAssetSupplyCap(address,address,uint128)chain 0x1
Target
0x316f…36e3
Value
0 wei
Function
updateAssetSupplyCap(address,address,uint128)
Arguments
{
  "asset": "0x8236a87084f8B84306f72007F36F2618A5634494",
  "cometProxy": "0xe85Dc543813B8c2CFEaAc371517b925a166a9293",
  "newSupplyCap": "0"
}
Calldata
#17deployAndUpgradeTo(address,address)chain 0x1
Target
0x1ec6…8779
Value
0 wei
Function
deployAndUpgradeTo(address,address)
Arguments
{
  "cometProxy": "0xe85Dc543813B8c2CFEaAc371517b925a166a9293",
  "configuratorProxy": "0x316f9708bB98af7dA9c68C1C3b5e79039cD336E3"
}
Calldata

05Tally

Summed from votes

Voters19
VP participating784.7K
Outcome (current)For
Current support100%

06Voters

19 total
Filter:
VoterChoice% of totalRationale
3F0x3fb1…4c8aFor104.8K13.35%—6mo ago
660x66cd…65f9For80.2K10.22%—6mo ago
B40xb49f…7948For60K7.65%—6mo ago
050x0579…ca09For60K7.65%—6mo ago
170x1729…b879For60K7.65%—6mo ago
B70xb792…89d7For60K7.65%—6mo ago
B90xb933…8dd1For60K7.65%—6mo ago
D20xd2a7…5a0cFor60K7.65%—6mo ago
B30xb356…c826For59.8K7.62%—6mo ago
070x0703…961bFor51.7K6.59%—6mo ago
4F0x4f89…fd3cFor50K6.37%—6mo ago
8D0x8d07…a265For30K3.82%—6mo ago
130x13bd…8548For30K3.82%—6mo ago
DAdakeshi.eth0xe3c9…6b21For15K1.91%—6mo ago
4D0x4d74…5896For2.7K0.34%—6mo ago
1F0x1f3d…0591For440.70.06%—6mo ago
C50xc554…7759For11.20.00%—6mo ago
2F0x2f2f…f78aFor0.50.00%—6mo ago
880x88f6…0ec0For00.00%—6mo ago
Showing 19

07Forum

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

Arguments for

  • Supply caps should be tightened to a buffer above current demand because excess headroom creates uncompensated downside risk if an asset suffers an exploit or depeg event.— Gauntlet
  • The frequency and sophistication of attacks on long-tail collaterals (LSTs, LRTs, wrapped assets) have risen sharply, making a defensive risk-off posture prudent.— Gauntlet
  • Dormant assets with negligible utilization (under 1%) should have caps set to zero since they carry idiosyncratic risk without corresponding organic demand.— Gauntlet
  • Existing users will not be displaced because all Rule 2 caps are set above current supply balances, preserving room to top up collateral during volatility.— Gauntlet
  • The proposal's uniform methodology applied consistently across all collaterals in scope provides a clear, defensible framework for cap-setting.— Gauntlet

Arguments against

None surfaced.

Unresolved concerns

  • Standard Compound governance may be too slow to reopen caps when dormant assets experience sudden demand surges, as evidenced by the 9-month timeline for the superOETH/stablecoin proposal.— pete
  • It is unclear whether a faster onboarding track should be created for assets that have already passed governance technical reviews by WOOF and OpenZeppelin rather than requiring a full restart of the governance process.— pete

Notable participants

  • GauntletProposer who recommended the supply cap reduction strategy based on risk analysis and provided detailed methodology and tables for all affected assets across six Ethereum Comets.
  • peteCommunity participant who raised concerns about governance speed for reopening caps and suggested a faster onboarding track for previously-approved assets.
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Open the thread ↗