KVORUM
compoundSource: Compound governor oz · #497

Update price feeds in cUSDSv3 on Mainnet with CAPO and Chainlink SVR implementation.

executedNov 15, 2025, 06:07 AM UTCby870x871f…e26c

01Summary

AISummary by Kvorumclaude-haiku-4-5

This proposal updates price feeds for wstETH, WETH, and weETH on the USDS market on Mainnet by implementing Chainlink's Streamlined Verification Route (SVR) and deploying new CAPO (Correlated Assets Price Oracle) implementations. CAPO is designed to safely track assets that grow gradually relative to a base asset. SVR fee revenue will go to the Compound DAO. The Comet protocol will be upgraded to support these new price feed implementations.

Type
contract upgrade

Key changes

  • wstETH price feed updated to CAPO implementation with new price feed address 0xA2699232B341881B1Ed85d91592b7c259E029aCf(high)
  • WETH price feed updated to SVR implementation with new price feed address 0xc0053f3FBcCD593758258334Dfce24C2A9A673aD(high)
  • weETH price feed updated to CAPO implementation with new price feed address 0x4F12633d511dC3049DE1ea923b7047fBeD0070D2(high)
  • Comet protocol upgraded to support new CAPO and SVR price feed implementations(high)
  • SVR fee revenue directed to Compound DAO multisig at 0xd9496F2A3fd2a97d8A4531D92742F3C8F53183cB(medium)

Notable concerns

  • CAPO is a new oracle implementation that has been audited by OpenZeppelin but represents a change in how certain asset prices are calculated
Contracts0x316f9708bb98af7da9c68c1c3b5e79039cd336e30x5D409e56D886231aDAf00c8775665AD0f9897b560x1ec63b5883c3481134fd50d5daebc83ecd2e8779
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

236 words

Update price feeds in cUSDSv3 on Mainnet with CAPO and Chainlink SVR implementation.

Proposal summary

This proposal updates existing price feeds for wstETH, WETH and weETH on the USDS market on Mainnet.

SVR summary

RFP process and community vote passed and decided to implement Chainlink's SVR solution for Mainnet markets, this proposal updates wstETH, WETH and weETH price feeds to support SVR implementations.

CAPO summary

CAPO is a price oracle adapter designed to support assets that grow gradually relative to a base asset - such as liquid staking tokens that accumulate yield over time. It provides a mechanism to track this expected growth while protecting downstream protocol from sudden or manipulated price spikes. wstETH and weETH price feeds are updated to their CAPO implementations.

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

CAPO audit

CAPO has been audited by OpenZeppelin, as well as the LST / LRT implementation here.

SVR fee recipient

SVR generates revenue from liquidators and Compound DAO will receive that revenue as part of the protocol fee. The fee recipient for SVR is set to Compound DAO multisig: 0xd9496F2A3fd2a97d8A4531D92742F3C8F53183cB.

Proposal actions

The first action updates wstETH price feed. The second action updates WETH price feed. The third action updates weETH price feed. The fourth action deploys and upgrades Comet to a new version.

03Mismatch analysis

AIMismatch analysis by Kvorumclaude-sonnet-5
Consistent

The description lists four proposal actions: three price-feed updates (wstETH, WETH, weETH) and one Comet deploy-and-upgrade. The decoded calldata contains exactly four actions matching this order and structure: three updateAssetPriceFeed calls targeting the Configurator with asset addresses that correspond to wstETH, WETH, and weETH respectively (verified against known token addresses), followed by a deployAndUpgradeTo call on the same cometProxy/configuratorProxy pair. All target contracts (Configurator at 0x316f97... and cUSDSv3 comet proxy at 0x5D409e...) are consistent across the three feed updates and the upgrade call, matching the single-market scope described (cUSDSv3 on Mainnet). No numeric parameters (percentages, caps) are stated in the prose that could be checked against calldata values, and the SVR fee recipient address mentioned in the description is not a separate on-chain action here — it is presumably embedded in the new price feed adapter contracts being deployed off-chain, which is a reasonable summarization consistent with how CAPO/SVR feed adapters are typically pre-configured before being pointed to via updateAssetPriceFeed. No omitted, extra, or mismatched actions were found. The description accurately and completely reflects the four decoded actions with no material or misleading discrepancies.

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

04Actions

4 total
#0updateAssetPriceFeed(address,address,address)chain 0x1
Target
0x316f…36e3
Value
0 wei
Function
updateAssetPriceFeed(address,address,address)
Arguments
{
  "asset": "0x7f39C581F595B53c5cb19bD0b3f8dA6c935E2Ca0",
  "cometProxy": "0x5D409e56D886231aDAf00c8775665AD0f9897b56",
  "newPriceFeed": "0xA2699232B341881B1Ed85d91592b7c259E029aCf"
}
Calldata
#1updateAssetPriceFeed(address,address,address)chain 0x1
Target
0x316f…36e3
Value
0 wei
Function
updateAssetPriceFeed(address,address,address)
Arguments
{
  "asset": "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2",
  "cometProxy": "0x5D409e56D886231aDAf00c8775665AD0f9897b56",
  "newPriceFeed": "0xc0053f3FBcCD593758258334Dfce24C2A9A673aD"
}
Calldata
#2updateAssetPriceFeed(address,address,address)chain 0x1
Target
0x316f…36e3
Value
0 wei
Function
updateAssetPriceFeed(address,address,address)
Arguments
{
  "asset": "0xCd5fE23C85820F7B72D0926FC9b05b43E359b7ee",
  "cometProxy": "0x5D409e56D886231aDAf00c8775665AD0f9897b56",
  "newPriceFeed": "0x4F12633d511dC3049DE1ea923b7047fBeD0070D2"
}
Calldata
#3deployAndUpgradeTo(address,address)chain 0x1
Target
0x1ec6…8779
Value
0 wei
Function
deployAndUpgradeTo(address,address)
Arguments
{
  "cometProxy": "0x5D409e56D886231aDAf00c8775665AD0f9897b56",
  "configuratorProxy": "0x316f9708bB98af7dA9c68C1C3b5e79039cD336E3"
}
Calldata

05Tally

Summed from votes

Voters0
VP participating0
Outcome (current)—
Current support—

06Voters

0 total

No votes recorded yet.

07Forum

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

Arguments for

  • Chainlink SVR is already live and proven in production (e.g., with Aave) and Compound already relies on Chainlink feeds on mainnet, so adopting it there adds minimal incremental risk.— cylon, allthecolors, pennblockchain
  • Ethereum mainnet holds the largest share of liquidation value, making it the most strategically important and comparatively safe place to pilot an OEV solution first.— cylon
  • A phased, single-market rollout on mainnet lets the DAO observe real performance (including through a stress event) before expanding further.— cylon
  • Delegates demonstrated decisive support for adopting Chainlink SVR on mainnet through the Snapshot vote, reflecting broad community backing.— AranaDigital

Arguments against

  • OEV auctions can add latency to liquidations, and historical price-drawdown data shows even a few blocks of delay can push positions into insolvency, especially on volatile assets and L2s.— Gauntlet, victator
  • Empirical analysis of past large Compound liquidations shows that slippage, builder tips, and provider fees consume the vast majority of liquidation incentive, meaning actual recapturable OEV revenue is far smaller than advertised (comparable to a minor SFPF adjustment).— victator
  • OEV is a patch over a deeper structural flaw in Compound's liquidation mechanism; resources would be better spent on partial liquidations and mechanism redesign rather than locking in an OEV vendor.— victator
  • Committing broadly to any OEV vendor now is premature since solutions are not yet fully tested in live, volatile conditions; a cautious, staged approach with real performance data is preferable.— cylon, Avantgarde
  • Chainlink's fairness and prioritization for Compound is questionable given it reportedly offered a materially worse revenue share than to Aave, raising doubts about whether L2 rollout and support will be prioritized.— ugurmersin

Unresolved concerns

  • Whether OEV-induced liquidation delays could materially increase insolvency risk on mainnet during high-volatility events once Chainlink SVR is live.— Gauntlet, victator
  • Whether real-world OEV revenue capture will be far smaller than projected once slippage, builder tips, and provider fees are accounted for.— victator
  • Whether Chainlink SVR's actual latency on mainnet and future L2 rollouts will meet Gauntlet's recommended sub-3-block liquidation window.— Gauntlet, mikemassari
  • Unresolved questions about Chainlink's comparatively lower revenue share and prioritization for Compound relative to other protocols like Aave.— ugurmersin
  • Whether adopting OEV now risks entrenching an inefficient liquidation architecture rather than pursuing higher-leverage fixes like partial liquidations.— victator

Notable participants

  • AranaDigitalOrganized and ran the RFP/Snapshot voting process, provided procedural updates and final vote results.
  • cylonDelegate who proposed and iteratively refined a risk-minimized, phased rollout strategy across chains, including supporting Chainlink SVR on mainnet.
  • GauntletProvided quantitative risk analysis on liquidation latency and price drawdowns, recommending caution and a 3-block latency ceiling.
  • victatorAuthored a detailed risk-first analysis (Platonia) arguing OEV revenue is overestimated and that liquidation mechanism redesign is a higher priority than OEV adoption.
  • ugurmersinApi3 representative who defended Api3's production track record and raised pointed questions about Chainlink and RedStone's claims and incentives.
  • mikemassariRedStone representative who responded to latency/searcher-network critiques and defended RedStone's Venus pilot record.
  • allthecolorsDelegate who largely aligned with cylon's cautious approach but advocated testing Chainlink SVR on Base and keeping Api3 on Mantle.
  • pennblockchainDelegate who voted with a measured rollout stance, initially favoring Api3 on Arbitrum before revising to no deployment there.
  • AvantgardeDelegate who echoed cylon's cautious, phased-testing approach given immature state of OEV solutions.
Generated by Kvorum
model: claude-sonnet-5
provider: anthropic
profile: anthropic-strong-v1
prompt: v1.0
generated: 2mo ago
Open the thread ↗