# Deprecate pumpBTC from cWBTCv3 on Ethereum
## Proposal summary
Woof proposes to deprecate pumpBTC from cWBTCv3 on Ethereum network, since deprecation of its Chainlink oracle.
In order to achieve this price feed will be updated to a new one, which will return the smallest acceptable price - 0.00000001 (1e-8).
This proposal takes the governance steps recommended and necessary to update a Compound III WBTC market on Ethereum. Simulations have confirmed the market’s readiness, as much as possible, using the [Comet scenario suite](https://github.com/compound-finance/comet/tree/main/scenario).
Further detailed information can be found on the corresponding [proposal pull request](https://github.com/Compound-Foundation/comet/pull/19).
## Proposal Actions
The first proposal action updates pumpBTC price feed to the price feed that returns the smallest acceptable price.
The second action deploys and upgrades Comet to a new version.
# Update cWETHv3 and cWstETHv3 Comets on Mainnet to the service patch version
## Proposal summary
WOOF! proposes to update Mainnet cWETHv3 and cWstETHv3 Comet markets to a new service patch version introducing several improvements and security enhancements:
- Extended Pause Controls: collateral interactions can now be paused independently per collateral asset.
- Price Feed Patch (Post-USDM incident response): skips price feed calls for assets with zero collateral factor, preventing unnecessary reverts.
- Collateral Deactivation Mechanism: introduces a Guardian-controlled emergency mechanism to deactivate unsafe collateral assets, with reactivation requiring a governance proposal.
- Utilization Peaking Protection: caps utilization at 200%, preventing additional borrowing when post-borrow utilization exceeds this threshold, while preserving lender withdrawals.
- Borrow Index Fix (Empty Market): prevents borrow interest accrual in markets without active borrowers.
- Supply Index Fix (Empty Market): ensures supply index only accrues when lenders are present.
- Lender Illiquidity Fix in Zero-Borrow Markets: prevents reserve depletion in markets with no borrowers by capping supply rate to zero when utilization is zero and reserves are exhausted.
- Accrue Interest on Collateral Actions (Post-USDM incident response): collateral actions (supply, withdraw, transfer) now trigger interest accrual for affected accounts.
- Technical Improvements: includes removal of redundant arguments in supplyInternal() and optimized price caching in absorbInternal(), improving gas efficiency without affecting protocol behavior.
This proposal takes the governance steps recommended and necessary to update Compound III WETH and wstETH markets on Mainnet. Simulations have confirmed the market's readiness, as much as possible, using the [Comet scenario suite](https://github.com/compound-finance/comet/tree/main/scenario).
Detailed information can be found on the corresponding [proposal pull request](https://github.com/Compound-Foundation/comet/pull/15).
### Bytecode Repository
This update is done with the use of the bytecode repository, which provides trustless and deterministic deployments.
Further details on the deployment can be found in the [Bytecode Repository git](https://github.com/woof-software/bytecode-repository) and [forum discussion](https://www.comp.xyz/t/rfc-bytecode-repository-and-deployment-pipeline-modernization/6965).
### Audit
Both service patch Comet update and Bytecode Repository have been audited by Certora and full reports can be found here:
- [Certora Comet Service Patch Audit](https://www.certora.com/reports/comet-service-patch)
- [Certora Bytecode Repository Audit](https://www.certora.com/reports/compound-bytecoderepository)
## Proposal Actions
The first proposal action updates the version in the new Comet factory to the recent service patch version.
The second proposal action updates the factory of the WETH Comet to the new V2 factory.
The third proposal action sets the extension delegate for the WETH Comet to the new service patch version.
The fourth proposal action deploys and upgrades the WETH Comet to the new service patch version.
The fifth proposal action updates the factory of the wstETH Comet to the new V2 factory.
The sixth proposal action sets the extension delegate for the wstETH Comet to the new service patch version.
The seventh proposal action deploys and upgrades the wstETH Comet to the new service patch version.
# Complete Arbitrum and Base Comet Upgrade
## Summary
This is a follow-up to [Proposal 596](https://www.tally.xyz/gov/compound/proposal/596), which upgraded Comets on Arbitrum and Base to v1.2.1. That upgrade was split per network into a sub-proposal that bumped the Comet Factory's version to 1.2.1 and a sub-proposal that redeploys each Comet from that same factory.
The execution automation ran these out of order, so the redeploy step for four Comets ran before the factory's version was bumped, deploying the prior version instead:
- Arbitrum cUSDTv3 ('0xd98Be00b5D27fc98112BdE293e487f8D4cA57d07')
- Arbitrum cWETHv3 ('0x6f7D514bbD4aFf3BcD1140B7344b32f063dEe486')
- Base cAEROv3 ('0x784efeB622244d2348d4F2522f8860B96fbEcE89')
- Base cWETHv3 ('0x46e6b214b524310239732D51387075E0e70970bf')
These four are now on an earlier Service Patch release rather than v1.2.1. That patch predates v1.2.1 and does not include the auditor-identified fix for under-paying suppliers when a market has no borrowers, but since all those markets are live there is no impact on current functionality or funds. All other Comets from Proposal 596 upgraded correctly and are unaffected.
The Comet Factory is already at v1.2.1, so this proposal just re-runs 'deployAndUpgradeTo' for the four Comets to finish the upgrade.
## Proposal Actions
The first action sends a cross-chain message to Arbitrum calling 'deployAndUpgradeTo' for cUSDTv3 and cWETHv3.
The second action sends a cross-chain message to Base calling 'deployAndUpgradeTo' for cAEROv3 and cWETHv3.
# Stop Legacy On-Chain COMP Reward Accrual; Merkl Migration and Season 1 Update
## Summary
This proposal seeks governance approval for one on-chain action: stop the remaining legacy on-chain COMP reward accrual by setting reward speeds to zero in the affected Comet markets.
It also provides implementation updates on the [<u>Merkl rewards</u>](https://app.compound.xyz/rewards) migration. These migration activities are proceeding under the existing TMC and Risk Manager mandates. Reward funding held in the relevant multisigs is being directed through Merkl, including the method by which accrued and future incentive rewards are delivered.
The Merkl migration does not change the applicable legacy methodology used to calculate previously accrued rewards. It changes how the resulting allocations are distributed and claimed. Season 1 applies the same distribution architecture to future incentives. The on-chain action in this proposal only sets the remaining legacy reward speeds to zero, stopping further technical accrual in the affected Comet markets.
## Background
Since the launch of Compound V2 and V3, COMP rewards have been distributed through protocol-owned reward contracts. Users continuously accrued rewards and could claim them at any time through the Compound interface or directly from the corresponding reward contracts. This mechanism has served since launch, but it has structural limitations:
* Reward logic is embedded in the protocol contracts. Any change to incentives, including rates, markets, or duration, requires a new protocol release, with the engineering and audit work that entails.
* Distribution is continuous by design. There is no native way to run a fixed-term or market-scoped campaign.
* Accrual and funding are independent. The contracts keep accruing rewards whether or not the rewards contract holds COMP, so the accrual a user sees on-chain can diverge from what is actually claimable.
* The claim functions permit any third party to trigger delivery of another account's accrued COMP. This mechanism has been deliberately abused to force COMP into contract addresses with no ability to transfer it out, rendering those rewards inaccessible and exposing further accrued COMP to the same attack.
This is an active security issue, not merely a design limitation. As described in this [<u>post</u>](https://www.comp.xyz/t/pausing-comet-rewards-top-ups/7879), the legacy permissionless claim mechanism has been used maliciously to force COMP into addresses that cannot recover it. Continued operation exposes further accrued COMP to the same misuse. Acting to protect the protocol and prevent further loss falls within the existing protocol-steward mandate.
The Risk Manager's existing mandate covers incentive programs intended to support Comet growth and healthy market behavior. Together with the TMC's responsibility for reward funding held in the relevant multisigs, this includes confirming campaign parameters and directing how funded rewards are delivered. The Merkl migration and Season 1 are being implemented under those mandates.
To address these limitations, the Merkl rewards migration changes the distribution implementation to Merkl, an independent rewards distribution platform used by multiple DeFi protocols. Merkl specializes in distributing on-chain incentives while allowing protocols to maintain transparent and verifiable reward calculations.
The migration changes only the distribution layer. The applicable legacy reward calculations remain unchanged.
## Proposal Overview
This proposal seeks approval for one on-chain action and separately provides implementation updates on the Merkl rewards migration and Season 1.
The action submitted for approval is to set the remaining legacy Comet reward speeds to zero, ending further technical accrual in the affected markets. The Merkl migration update below describes the treatment of previously accrued rewards included in the snapshot ranges for migrated networks.
Season 1 is the first fixed 90-day incentive campaign distributed through Merkl. It is funded from the relevant multisigs and is proceeding under the existing TMC and Risk Manager mandates. Season 1 and all future Merkl-distributed COMP incentive programmes are governed by the Incentive Programme Terms set out below.
This approach separates reward distribution from protocol contracts while allowing the TMC and Risk Manager to confirm and publish future campaign parameters without modifying protocol reward contracts.
## Merkl Rewards Migration Update
Previously accrued rewards included in the snapshot ranges for migrated networks are being moved to Merkl without changing the applicable legacy calculation methodology.
The implementation process consists of reading the relevant on-chain data, aggregating each user's previously accrued rewards using open-source scripts, publishing the resulting allocations, and making those allocations claimable through Merkl. The full snapshot amount is funded by directing COMP from the relevant multisigs to the Merkl distributor.
Users are not required to migrate their positions or perform any protocol interaction. Existing lending and borrowing positions remain completely unaffected.
## Seasonal Incentive Model
Season 1 is being launched as the first Merkl-distributed COMP incentive campaign.
A Season is a fixed 90-day incentive campaign during which users earn rewards through lending and borrowing activity on supported Compound markets.
## Season 1 Parameters
Details of Season 1 will be posted on the website.
* Distribution terms:
* Mainnet
* USDC
* Lending: 55 COMP/daily
* Borrowing: 55 COMP/daily
* USDT
* Lending: 30 COMP/daily
* Borrowing: 30 COMP/daily
* WETH
* Lending: 10 COMP/daily
* Borrowing: 20 COMP/daiy
In total 200 COMP/daily
* Maximum COMP allocation: 18,000
Unlike the previous system, rewards cannot be claimed during the Season itself.
Instead, rewards accumulate throughout the campaign. After the Season concludes:
1. A snapshot of accrued rewards is generated.
2. The allocation dataset is published publicly.
3. A dedicated Merkl campaign is created.
4. Users can claim their rewards during the campaign's claim window.
Before each future Season begins, the Compound Governance Working Group (CGWG), TMC and Risk Manager will confirm and publish relevant parameters and terms applying to the relevant Season. This allows the CGWG, TMC and Risk Manager to adjust incentive programs without modifying protocol reward contracts, while ensuring that each Season's parameters are published before it begins.
## Reward Claiming
Previously accrued rewards become claimable through dedicated Merkl campaigns. Future Season rewards become claimable only after the corresponding Season has ended and the reward snapshot has been published.
To claim rewards, users simply connect the wallet that participated in Compound to the official Merkl application and claim any available COMP rewards.
No migration transaction, staking process, or protocol interaction is required. From the snapshot block forward, the Merkl distribution is the DAO's record of reward entitlement.
## Claim Windows
To avoid rewards remaining unclaimed indefinitely, Merkl campaigns include finite claim windows.
Under the Incentive Programme Terms below:
* Previously accrued V2 rewards may be claimed for 60 days after their snapshot.
* Previously accrued V3 rewards may be claimed for 180 days after their snapshot.
* Season rewards may be claimed for 30 days after the Season concludes.
Once a campaign's claim window expires, rewards can no longer be claimed under the current governance rules. COMP that remains unclaimed when a window closes is returned by the TMC, as distributor admin, to the Treasury Timelock.
## If This Proposal Fails
If this proposal fails, the remaining Ethereum USDC, USDT and WETH Comet reward speeds will stay non-zero and the on-chain contracts will continue recording technical accrual. The relevant multisigs will not be reloaded to fund those additional balances, so legacy distribution will remain effectively off despite the continuing accounting entries. The Merkl migration and Season 1 will continue under the existing TMC and Risk Manager implementation.
Existing funded COMP balances in the legacy rewards contracts will remain available for on-chain claims while sufficient balances remain. Any additional balances recorded after the Merkl cutover will not be funded through those contracts.
## Supported Networks
Previously accrued rewards continue to be available for all chains where Compound previously distributed COMP incentives.
The migration covers:
* Ethereum
* Arbitrum
* Optimism
* Base
* Polygon
* Unichain
Mantle and Linea are excluded from this migration and continue using their existing on-chain reward contracts. Rewards on those chains remain claimable through the legacy mechanism and are not subject to the Merkl claim deadlines.
## Snapshot Blocks
Allocations are calculated deterministically and can be independently verified.
For the legacy rewards system, each campaign is calculated over an inclusive block range, meaning both the start and end blocks are included in the reward calculation. These ranges correspond to the governance proposals that either initiated or terminated rewards on each network.
The corresponding block snapshots will be posted on the [forum](https://www.comp.xyz/t/stop-legacy-on-chain-comp-reward-accrual-merkl-migration-and-season-1-update/8043) once the Merkl campaigns are created.
## Merkl Rewards Migration FAQ
*All placeholders will be filled in once the details are ready on the* [*forum*](https://www.comp.xyz/t/stop-legacy-on-chain-comp-reward-accrual-merkl-migration-and-season-1-update/8043)*.*
### Q1
* Question: Why was claiming moved to Merkl?
* Answer: Claiming moved so incentive campaigns can run without changing protocol contracts. Under the old system, every rewards program was tied to a protocol release and carried its own distribution infrastructure. Merkl changes only how rewards are distributed and claimed; Compound's reward calculations remain unchanged. The TMC and Risk Manager confirm the parameters for each Season and publish them before it begins.
### Q2
* Question: Is rewards distribution still active?
* Answer: Yes. Season 1 is active as the first Merkl-distributed incentive campaign. Its parameters were confirmed by the TMC and Risk Manager under their existing mandates and published at [<u>forum</u>](https://www.comp.xyz/t/stop-legacy-on-chain-comp-reward-accrual-merkl-migration-and-season-1-update/8043). Rewards accrued before the Merkl cutover remain available and can be claimed separately. The Snapshot Blocks section records where the legacy distribution period ended and Season 1 began.
### Q3
* Question: How can I verify the accrued rewards calculation is accurate?
* Answer: To calculate your claimable amount for Merkl, an off-chain script reads the on-chain data and applies no additional logic beyond aggregating it. You can verify your own number two ways: (1) check the calculation script's source code (see on the [<u>forum</u>](https://www.comp.xyz/t/stop-legacy-on-chain-comp-reward-accrual-merkl-migration-and-season-1-update/8043)), which is open and published on GitHub, or (2) independently read your \`baseTrackingAccrued\` value directly from the \[CometRewards contract]\(https://github.com/compound-foundation/comet/blob/main/contracts/CometRewards.sol#L207) on a block explorer and compare it to what Merkl shows. This method applies to V3. For V2, the calculation reads the Comptroller contract's reward state; the V2 script linked under "Do rewards expire?" shows the exact method.
##
### Q4
* Question: What's the official Merkl link, and what happens once I leave the Compound app?
* Answer: The only official Merkl app URL is app\[.]merkl\[.]xyz]. Once you leave the Compound app for Merkl, you're interacting with an independent, third-party platform; Compound Foundation and Compound DAO aren't responsible for actions taken there.
### Q5
* Question: What chains are supported for rewards?
* Answer: All chains where Compound DAO has historically distributed rewards: \*\*V2\*\* — \[Ethereum]\({{V2\_ETHEREUM\_MERKL\_LINK}}). \*\*V3\*\* — \[Ethereum]\({{V3\_ETHEREUM\_MERKL\_LINK}}), \[Arbitrum]\({{V3\_ARBITRUM\_MERKL\_LINK}}), \[Optimism]\({{V3\_OPTIMISM\_MERKL\_LINK}}), \[Unichain]\({{V3\_UNICHAIN\_MERKL\_LINK}}), \[Polygon]\({{V3\_POLYGON\_LINK}}), \[Base]\({{V3\_BASE\_MERKL\_LINK}}). See all the links on the [<u>forum</u>](https://www.comp.xyz/t/stop-legacy-on-chain-comp-reward-accrual-merkl-migration-and-season-1-update/8043). Mantle and Linea rewards are claimed on-chain, not through Merkl; see "Have all V3 chains migrated to the new Merkl distribution system?" below.
### Q6
* Question: Are V2 rewards available only on Ethereum?
* Answer: Yes. Compound V2 rewards are only on Ethereum.
### Q7
* Question: Can I still see my rewards in the old on-chain system after claiming via Merkl?
* Answer: Yes. Even after claiming COMP via Merkl, you can still view your historical reward balance in the old on-chain system (except on Mantle and Linea, where that system is still the active claim method). No new rewards are distributed through the old system on any other chain; Merkl has fully replaced it there. The balance the old contracts display after migration is historical only. The Merkl distribution is the DAO's record of reward entitlement, and amounts claimed through Merkl are not payable again from the old contracts
### Q8
* Question: Have all V3 chains migrated to the new Merkl distribution system?
* Answer: No. Ethereum, Arbitrum, Optimism, Unichain, Polygon, and Base have migrated to Merkl. \*\*Mantle and Linea have not\*\* — claim there directly through the original on-chain reward contracts:
* Mantle: 0xCd83CbBFCE149d141A5171C3D6a0F0fCCeE225Ab
* Linea: 0x2c7118c4C88B9841FCF839074c26Ae8f035f2921
### Q9
* Question: What is a "Season," how are its rewards distributed, when can I claim them, and do they expire?
* Answer: A Season is a fixed-term incentive campaign during which users accrue COMP rewards through lending and borrowing activity. Season 1 runs for 90 days. It distributes 200 COMP per day, up to 18,000 per Season 1, across USDC, USDT and WETH V3 markets on Mainnet. Rewards cannot be claimed during the Season. After it ends, the allocation snapshot is published on [forum](https://www.comp.xyz/t/stop-legacy-on-chain-comp-reward-accrual-merkl-migration-and-season-1-update/8043) and a dedicated Merkl claim campaign opens for \[30] days. Before each subsequent Season begins, the TMC and Risk Manager will confirm its parameters and publish them in advance.
### Q10
* Question: What block ranges were rewards calculated over?
* Answer: For the legacy rewards distribution mechanism, rewards were calculated from the snapshot block at which the first rewards campaign for a given market began (or from the market deployment block if rewards started immediately) through the block at which the last rewards campaign ended. Both the start and end blocks are included in the calculation (i.e., the block range is inclusive on both ends).
## Incentive Programme Terms
These terms govern Season 1 and all future COMP incentive programmes distributed through Merkl.
1. COMP accrues only in the markets, at the rates and for the period published before a Season begins. Participation in one Season creates no entitlement to rewards in any future Season.
2. The programme is administered by the Compound Governance Working Group (CGWG), Treasury Management Committee (TMC) and the Risk Manager. The TMC multisig holds the Merkl distributor admin role, and its signers are publicly disclosed.
3. Claims are made through the Merkl distributor. Merkl is a third-party platform, and claims are also subject to Merkl's terms.
4. Each campaign's published claim window applies: 60 days for previously accrued V2 rewards, 180 days for previously accrued V3 rewards and the period published for each Season. Unclaimed COMP is returned by the TMC to the Treasury Timelock when the window closes.
5. For migrated networks, the published Merkl distribution is the DAO's definitive record of reward entitlement for the period it covers. Mantle and Linea remain on their existing on-chain reward contracts and are outside that record.
6. Allocations are calculated from on-chain data using published open-source scripts. If a published allocation differs from a legacy contract display, the published allocation governs for the relevant campaign.
7. Reward speeds recorded in Comet contracts after a snapshot do not establish that additional COMP is owed. No COMP is appropriated to legacy reward contracts; funding them would require a new DAO appropriation.
8. Recipients are responsible for any tax arising from COMP they receive.
9. The TMC, Risk Manager and CGWG may set, change or end a Season by a joint forum update within their existing mandates. These terms may be amended only by a joint forum update from the TMC, Risk Manager and CGWG.
# Franchiser Operational Upgrade and Rebalance
## Summary
This proposal upgrades Compound's treasury-delegation (Franchiser) system to a new pool-based architecture and, in the same step, carries out the first scheduled biannual delegate rebalancing under **Proposal 504 — [Compound Delegate Race (Cycle 2)](https://www.comp.xyz/t/compound-delegate-race-cycle-2/7302)**.
The total COMP delegated through the program does not change. Existing delegations migrate to the new pool with no interruption to voting power, and the pool reclaimed from under-participating delegates is redistributed to qualified active delegates. COMP remains in Governance-owned contracts throughout.
## Background
Proposal 504 established a standing six-monthly review of treasury-delegated voting power, with a uniform on-chain participation standard and a defined reallocation procedure. The first review window (Proposals 505–586) has closed and participation has been verified on-chain. The full review, application window, and waterfall are documented on the forum: [comp.xyz/t/7862](https://www.comp.xyz/t/7862).
## What this proposal does
1. **Upgrade.** Migrate the treasury-delegation program to the upgraded Franchiser pool: existing delegations move into a new Governance-funded pool, with the CGWG multisig set as Coordinator and a Guardian set for emergency oversight. Governance retains sole authority to fund, halt, or reclaim the pool in full.
2. **Rebalance.** As part of the migration, three delegations that fell below the participation standard are not renewed — releasing **81,178.58 COMP** — which is redistributed to the qualified applicants per the waterfall.
**Not renewed — 81,178.58 COMP reclaimed:**
| Delegatee | Address | COMP |
|---|---|---:|
| Michigan Blockchain | `0x13BD…8548` | 29,999.88 |
| Reservoir / AlphaGrowth | `0x4f89…fd3c` | 50,000.00 |
| Sharp | `0x72C5…7708` | 1,178.70 |
**Reallocated — 81,178.58 COMP:**
| Delegate | Address | COMP |
|---|---|---:|
| FranklinDAO | `0x0703…961b` | 8,262.46 |
| DAOplomats | `0xc554…7759` | 40,000.00 |
| blockful | `0x1F3D…0591` | 32,916.12 |
## The upgraded architecture
The upgrade replaces per-delegation Franchiser deployments with a single pool, split across three role-gated contracts:
- **FranchiserPoolFactory** — the Governance-only entry point. Governance creates, funds, and can halt a pool; halting recalls all delegates and returns the full COMP balance to the Timelock (the only path for COMP to leave the program).
- **FranchiserPool** — holds the program's idle COMP. A **Coordinator** (the CGWG multisig) can `delegate`, `recall`, and `reassign` voting power among delegates within Governance-set limits. A separate **Guardian** can emergency-`recall` a delegate or `freeze` the pool (10-day minimum), but can never move or delegate COMP.
- **Franchiser** — unchanged from V1: holds delegated COMP and grants voting power to a delegatee (who may name up to one sub-delegate).
Governance (the Timelock) sets each pool's parameters — delegate cap, Coordinator, Guardian, freeze period — and can change them or halt the program at any time by on-chain vote.
## Guarantees
- **Delegation only, never custody.** COMP stays in Governance-owned contracts at every step (Timelock → pool → Franchiser); no working group, Coordinator, or Guardian ever takes custody of the tokens.
- **Total set by governance.** This proposal does not change the program's total delegated COMP — it migrates and reallocates the existing pool. Any change to the total returns to an on-chain vote, and Governance can recall or reassign any delegation at any time.
# [TMC Housekeeping] Deprecate the Aera Vendor Vault & Avantgarde Treasury Vehicle
The Treasury Management RFP has concluded and the Avantgarde COMP strategy ($4.2M) was not selected. This housekeeping proposal deprecates it, together with the near-empty Aera Vendor Vault ($8K), by placing the Vendor Vault's ownership with the TMC's Treasury Timelock and severing Avantgarde's external operator access so the committee can wind both down and redeploy into the selected strategies, within the audited Escrow/Timelock architecture the DAO approved in Prop 580 (2-day delay; the DAO keeps its 60-day termination right).
For the Vendor Vault this finishes the transfer Prop 580 left half-done: Prop 580 set the Treasury Timelock as pendingOwner but the accept was never made, so the vault has sat in limbo. This proposal accepts it.
This proposal only transfers control already approved by governance and performs low-level, amount-independent cleanup. The actual liquidation and disbursement are executed by the TMC afterward as ordinary operations; no market/price-sensitive transfers are included here.
# Update All L2 Comets to the service patch version
## Proposal summary
WOOF! proposes upgrading next Comet markets:
- Arbitrum: USDC, USDC.e, USDT and WETH
- Base: USDC, USDbC, USDS, AERO and WETH
- Optimism: USDC, USDT and WETH
- Polygon: USDC and USDT
- Mantle: USDe
- Unichain: USDC and WETH
To a new service patch version introducing several improvements and security enhancements:
- Extended Pause Controls: collateral interactions can now be paused independently per collateral asset.
- Price Feed Patch (Post-USDM incident response): skips price feed calls for assets with zero collateral factor, preventing unnecessary reverts.
- Collateral Deactivation Mechanism: introduces a Guardian-controlled emergency mechanism to deactivate unsafe collateral assets, with reactivation requiring a governance proposal.
- Utilization Peaking Protection: caps utilization at 200%, preventing additional borrowing when post-borrow utilization exceeds this threshold, while preserving lender withdrawals.
- Borrow Index Fix (Empty Market): prevents borrow interest accrual in markets without active borrowers.
- Supply Index Fix (Empty Market): ensures supply index only accrues when lenders are present.
- Lender Illiquidity Fix in Zero-Borrow Markets: prevents reserve depletion in markets with no borrowers by capping supply rate to zero when utilization is zero and reserves are exhausted.
- Accrue Interest on Collateral Actions (Post-USDM incident response): collateral actions (supply, withdraw, transfer) now trigger interest accrual for affected accounts.
- Technical Improvements: includes removal of redundant arguments in supplyInternal() and optimized price caching in absorbInternal(), improving gas efficiency without affecting protocol behavior.
This proposal takes the governance steps recommended and necessary to update Compound III markets. Simulations have confirmed the market’s readiness, as much as possible, using the [Comet scenario suite](https://github.com/compound-finance/comet/tree/main/scenario).
Detailed information can be found on the corresponding [proposal pull request](https://github.com/compound-finance/comet/pull/1132).
### Bytecode Repository
This update is done with the use of the bytecode repository, which provides trustless and deterministic deployments.
Further details on the deployment can be found in the [Bytecode Repository git](https://github.com/woof-software/bytecode-repository) and [forum discussion](https://www.comp.xyz/t/rfc-bytecode-repository-and-deployment-pipeline-modernization/6965).
### Audit
Both service patch Comet update and Bytecode Repository have been audited by Certora and full reports can be found here:
- [Certora Comet Service Patch Audit](https://www.certora.com/reports/comet-service-patch)
- [Certora Bytecode Repository Audit](https://www.certora.com/reports/compound-bytecoderepository)
## Proposal Actions
The first action sets the factory to the newly deployed factory, extension delegate to the newly deployed contract and deploys and upgrades Arbitrum USDC and USDC.e Comets to a new version.
The second action sets the factory to the newly deployed factory, extension delegate to the newly deployed contract and deploys and upgrades Arbitrum USDT and WETH Comets to a new version.
The third action sets the factory to the newly deployed factory, extension delegate to the newly deployed contract and deploys and upgrades Base USDC, USDbC and USDS Comets to a new version.
The fourth action sets the factory to the newly deployed factory, extension delegate to the newly deployed contract and deploys and upgrades Base AERO and WETH Comets to a new version.
The fifth action sets the factory to the newly deployed factory, extension delegate to the newly deployed contract and deploys and upgrades Optimism USDC, USDT and WETH Comets to a new version.
The sixth action sets the factory to the newly deployed factory, extension delegate to the newly deployed contract and deploys and upgrades Polygon USDC and USDT Comets to a new version.
The seventh action sets the factory to the newly deployed factory, extension delegate to the newly deployed contract and deploys and upgrades Mantle USDe Comet to a new version.
The eighth action sets the factory to the newly deployed factory, extension delegate to the newly deployed contract and deploys and upgrades Unichain USDC and WETH Comets to a new version.
# Zeroing Supply Rates on Deprecated Comets
## Proposal summary
Woof proposes to zero out supply rates on deprecated Comets: cUSDCv3 and cWETHv3 on Linea, cUSDev3 on Mantle, cWETHv3 and cWRONv3 on Ronin, and cUSDCv3 on Scroll. This proposal takes the governance steps recommended and necessary to update Compound III markets on each network. Simulations have confirmed the market’s readiness, as much as possible, using the [Comet scenario suite](https://github.com/compound-finance/comet/tree/main/scenario). The new parameters are based on the [recommendations from Gauntlet](https://www.comp.xyz/t/accelerating-deprecation-zeroing-supply-rates-on-deprecated-comets/7997/1).
Further detailed information can be found on the corresponding [proposal pull request](https://github.com/Compound-Foundation/comet/pull/12) and [forum discussion](https://www.comp.xyz/t/accelerating-deprecation-zeroing-supply-rates-on-deprecated-comets/7997).
## Specification
The following parameters apply identically to all six Comets:
| Parameter | Proposed |
| ------------------------------- | -------- |
| Annual Supply Rate Base | 0% |
| Annual Supply Rate Slope Low | 0% |
| Supply Kink | 90% |
| Annual Supply Rate Slope High | 0% |
## Proposal Actions
The first action sends a message to the Linea network to zero out supply rates and upgrade the USDC and WETH Comets.
The second action sends a message to the Mantle network to zero out supply rates and upgrade the USDe Comet.
The third action approves the L1CCIPRouter to transfer GHO from the Timelock to pay for the proposal execution fee on Ronin.
The fourth action sends a CCIP message to the Ronin network to zero out supply rates and upgrade the WETH and WRON Comets.
The fifth action sends a message to the Scroll network to zero out supply rates and upgrade the USDC Comet.
# Update Comet version on Linea and Scroll
## Proposal summary
This proposal upgrades the Compound III USDC and WETH markets on Linea and the USDC market on Scroll to a new Comet version that changes how the base supply index is capped in markets that have lenders but no borrowers.
Previously, `accruedInterestIndices()` applied a post-accrual clamp: whenever `totalBorrowBase == 0`, if `presentValueSupply(totalSupplyBase)` exceeded the Comet's base token balance, `baseSupplyIndex` was forced down to `(balance * BASE_INDEX_SCALE) / totalSupplyBase`. This protected lender withdrawals in reserve-funded markets with no borrowers, but only corrected the index after it had already been pushed too far.
The new version enforces the same cap earlier, in `getSupplyRate()`: when utilization is `0` and `presentValueSupply(totalSupplyBase) >= balanceOf(this)`, the supply rate returns `0`, so accrual stops before the index overshoots rather than being corrected after the fact. Because a single accrual step still applies one rate over the full `timeElapsed`, a long gap between accruals can still overshoot the cap by a few wei; after that, `getSupplyRate()` returns `0` and the supply index no longer increases.
Further detailed information can be found in the corresponding [pull request](https://github.com/compound-finance/comet/pull/1139).
## Audit
The new Comet version has been audited by [Certora](https://certora.cdn.prismic.io/certora/o_tSg8jfh3YhErQ7_Woof-CometPRs-FinalReport.pdf) and no issues were found.
## Proposal Actions
The first action updates the Comet implementation version in V2 Factory on Linea and deploys and upgrades the USDC and WETH Comets to the new implementation.
The second action updates the Comet implementation version in V2 Factory on Scroll and deploys and upgrades the USDC Comet to the new implementation.
# Update cbBTC price feeds on Base to SVR
## Proposal summary
This proposal updates the cbBTC price feeds in the Compound III AERO, USDC, USDS, and WETH markets on Base to use the new SVR price feeds.
Further detailed information can be found on the corresponding [proposal pull request](https://github.com/compound-finance/comet/pull/1129) and [forum discussion for SVR](https://www.comp.xyz/t/request-for-proposal-rfp-oracle-extractable-value-oev-solution-for-compound-protocol/6786).
### 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 on Base is set to Compound DAO multisig: 0xb3e79c7cac540ca833015e63d96d3032ba0c4129.
## Proposal Actions
The first action updates the cbBTC price feeds in the AERO and WETH markets.
The second action updates the cbBTC price feeds in the USDC and USDS markets.
# Franchiser Operational Upgrade and Rebalance
## Summary
This proposal upgrades Compound's treasury-delegation (Franchiser) system to a new pool-based architecture and, in the same step, carries out the first scheduled biannual delegate rebalancing under **Proposal 504 — [Compound Delegate Race (Cycle 2)](https://www.comp.xyz/t/compound-delegate-race-cycle-2/7302)**.
The total COMP delegated through the program does not change. Existing delegations migrate to the new pool with no interruption to voting power, and the pool reclaimed from under-participating delegates is redistributed to qualified active delegates. COMP remains in Governance-owned contracts throughout.
## Background
Proposal 504 established a standing six-monthly review of treasury-delegated voting power, with a uniform on-chain participation standard and a defined reallocation procedure. The first review window (Proposals 505–586) has closed and participation has been verified on-chain. The full review, application window, and waterfall are documented on the forum: [comp.xyz/t/7862](https://www.comp.xyz/t/7862).
## What this proposal does
1. **Upgrade.** Migrate the treasury-delegation program to the upgraded Franchiser pool: existing delegations move into a new Governance-funded pool, with the CGWG multisig set as Coordinator and a Guardian set for emergency oversight. Governance retains sole authority to fund, halt, or reclaim the pool in full.
2. **Rebalance.** As part of the migration, three delegations that fell below the participation standard are not renewed — releasing **81,178.58 COMP** — which is redistributed to the qualified applicants per the waterfall.
**Not renewed — 81,178.58 COMP reclaimed:**
| Delegatee | Address | COMP |
|---|---|---:|
| Michigan Blockchain | `0x13BD…8548` | 29,999.88 |
| Reservoir / AlphaGrowth | `0x4f89…fd3c` | 50,000.00 |
| Sharp | `0x72C5…7708` | 1,178.70 |
**Reallocated — 81,178.58 COMP:**
| Delegate | Address | COMP |
|---|---|---:|
| FranklinDAO | `0x0703…961b` | 8,262.46 |
| DAOplomats | `0xc554…7759` | 40,000.00 |
| blockful | `0x1F3D…0591` | 32,916.12 |
## The upgraded architecture
The upgrade replaces per-delegation Franchiser deployments with a single pool, split across three role-gated contracts:
- **FranchiserPoolFactory** — the Governance-only entry point. Governance creates, funds, and can halt a pool; halting recalls all delegates and returns the full COMP balance to the Timelock (the only path for COMP to leave the program).
- **FranchiserPool** — holds the program's idle COMP. A **Coordinator** (the CGWG multisig) can `delegate`, `recall`, and `reassign` voting power among delegates within Governance-set limits. A separate **Guardian** can emergency-`recall` a delegate or `freeze` the pool (10-day minimum), but can never move or delegate COMP.
- **Franchiser** — unchanged from V1: holds delegated COMP and grants voting power to a delegatee (who may name up to one sub-delegate).
Governance (the Timelock) sets each pool's parameters — delegate cap, Coordinator, Guardian, freeze period — and can change them or halt the program at any time by on-chain vote.
## Guarantees
- **Delegation only, never custody.** COMP stays in Governance-owned contracts at every step (Timelock → pool → Franchiser); no working group, Coordinator, or Guardian ever takes custody of the tokens.
- **Total set by governance.** This proposal does not change the program's total delegated COMP — it migrates and reallocates the existing pool. Any change to the total returns to an on-chain vote, and Governance can recall or reassign any delegation at any time.
# Update Linea and Scroll Comets to the service patch version
## Proposal summary
WOOF! proposes upgrading the Linea cUSDCv3, cWETHv3, and Scroll cUSDCv3 Comet markets to a new service patch version introducing several improvements and security enhancements:
- Extended Pause Controls: collateral interactions can now be paused independently per collateral asset.
- Price Feed Patch (Post-USDM incident response): skips price feed calls for assets with zero collateral factor, preventing unnecessary reverts.
- Collateral Deactivation Mechanism: introduces a Guardian-controlled emergency mechanism to deactivate unsafe collateral assets, with reactivation requiring a governance proposal.
- Utilization Peaking Protection: caps utilization at 200%, preventing additional borrowing when post-borrow utilization exceeds this threshold, while preserving lender withdrawals.
- Borrow Index Fix (Empty Market): prevents borrow interest accrual in markets without active borrowers.
- Supply Index Fix (Empty Market): ensures supply index only accrues when lenders are present.
- Lender Illiquidity Fix in Zero-Borrow Markets: prevents reserve depletion in markets with no borrowers by capping supply rate to zero when utilization is zero and reserves are exhausted.
- Accrue Interest on Collateral Actions (Post-USDM incident response): collateral actions (supply, withdraw, transfer) now trigger interest accrual for affected accounts.
- Technical Improvements: includes removal of redundant arguments in supplyInternal() and optimized price caching in absorbInternal(), improving gas efficiency without affecting protocol behavior.
This proposal takes the governance steps recommended and necessary to update Compound III USDC and WETH markets on Linea and Scroll. Simulations have confirmed the market’s readiness, as much as possible, using the [Comet scenario suite](https://github.com/compound-finance/comet/tree/main/scenario).
Detailed information can be found on the corresponding [proposal pull request](https://github.com/compound-finance/comet/pull/1118).
### Bytecode Repository
This update is done with the use of the bytecode repository, which provides trustless and deterministic deployments.
Further details on the deployment can be found in the [Bytecode Repository git](https://github.com/woof-software/bytecode-repository) and [forum discussion](https://www.comp.xyz/t/rfc-bytecode-repository-and-deployment-pipeline-modernization/6965).
### Audit
Both service patch Comet update and Bytecode Repository have been audited by Certora and full reports can be found here:
- [Certora Comet Service Patch Audit](https://www.certora.com/reports/comet-service-patch)
- [Certora Bytecode Repository Audit](https://www.certora.com/reports/compound-bytecoderepository)
## Proposal Actions
The first action sets the factory to the newly deployed factory, extension delegate to the newly deployed contract and deploys and upgrades Comet to a new version on Linea.
The second action sets the factory to the newly deployed factory, extension delegate to the newly deployed contract and deploys and upgrades Comet to a new version on Scroll.
Voting against this proposal. While the temporary MinMaxConstantPriceFeed was introduced as an emergency measure, removing it at this stage may be premature. Given the recent history surrounding the rsETH bridge exploit, maintaining additional safeguards for a longer observation period could provide stronger protection against unexpected market or oracle-related risks.
I would prefer to see more extended stability data and further risk assessment before reverting to the previous oracle configuration across both the Mainnet WETH and wstETH Comets.
# Return rsETH Price Feeds on WETH and wstETH Markets (Mainnet)
## Summary
This proposal is a follow-up to the emergency rsETH oracle migration and returns the Mainnet WETH and wstETH Comets to their prior rsETH price feed configuration.
The earlier migration to a MinMaxConstantPriceFeed was introduced as a temporary risk-control measure after the April 18 Kelp rsETH bridge exploit. With conditions now stabilized, this proposal removes the temporary setup and restores the previous feed configuration.
Implementation details: [PR #1122](https://github.com/compound-finance/comet/pull/1122).
## Proposal Actions
1. Update the rsETH price feed on the Mainnet WETH market.
2. Update the rsETH price feed on the Mainnet wstETH market.
3. Deploy and upgrade the WETH Comet to apply the configuration change.
4. Deploy and upgrade the wstETH Comet to apply the configuration change.
# Supply Cap Reduction Across L2 Comets (Part 2)
## Proposal summary
WOOF! proposes to update supply caps on cUSDCv3, cUSDTv3 and cWETHv3 on Optimism, cUSDCv3 and cUSDTv3 on Polygon, cUSDCv3 and cWETHv3 on Unichain networks. This proposal takes the governance steps recommended and necessary to update Compound III markets on each network. Simulations have confirmed the market’s readiness, as much as possible, using the [Comet scenario suite](https://github.com/compound-finance/comet/tree/main/scenario). The new parameters are based on the [recommendations from Gauntlet](https://www.comp.xyz/t/supply-cap-reduction-across-l2-comets/7794/1).
Further detailed information can be found on the corresponding [proposal pull request](https://github.com/compound-finance/comet/pull/1124) and [forum discussion](https://www.comp.xyz/t/supply-cap-reduction-across-l2-comets/7794).
## Proposal Actions
The first action sends a message to the Optimism network to update supply caps on the USDC, USDT and WETH Comets.
The second action sends a message to the Polygon network to update supply caps on the USDC and USDT Comets.
The third action sends a message to the Unichain network to update supply caps on the USDC and WETH Comets.
# Supply Cap Reduction Across L2 Comets
## Proposal summary
WOOF! proposes to update supply caps on cUSDCv3, cUSDC.ev3, cUSDTv3 and cWETHv3 on Arbitrum, cUSDCv3 and cWETHv3 on Base, cWETHv3 on Linea and cUSDev3 on Mantle networks. This proposal takes the governance steps recommended and necessary to update a Compound III markets on each network. Simulations have confirmed the market’s readiness, as much as possible, using the [Comet scenario suite](https://github.com/compound-finance/comet/tree/main/scenario). The new parameters are based on the [recommendations from Gauntlet](https://www.comp.xyz/t/supply-cap-reduction-across-l2-comets/7794/1).
Further detailed information can be found on the corresponding [proposal pull request](https://github.com/compound-finance/comet/pull/1120) and [forum discussion](https://www.comp.xyz/t/supply-cap-reduction-across-l2-comets/7794).
## Proposal Actions
The first action sends a message to the Arbitrum network to update supply caps on the USDC and USDC.e Comets.
The second action sends a message to the Arbitrum network to update supply caps on the USDT and WETH Comets.
The third action sends a message to the Base network to update supply caps on the USDC and WETH Comets.
The fourth action sends a message to the Linea network to update supply caps on the WETH Comet.
The fifth action sends a message to the Mantle network to update supply caps on the USDe Comet.
This proposal is what the community has been asking for since it converged on the establishment of a Foundation as the path forward following significant turbulence in 2024-2025. The ask is large, but the vision for V4 will create a competitive edge for Compound both at the protocol level and at the market acquisition level. While moving forward with these proposals is a bit clunky amidst the rsETH resolution, I agree with the Foundation that it doesn't make sense to delay these important and time-sensitive initiatives. Passage of proposals 581 and especially 580 will contribute to the success of 582, so I am glad to see them moving together through governance.
This is the second initiative to establish a delegate compensation program. I abstained from the first such proposal on principle as a delegate who stood to gain from the initiative despite my conviction that such an initiative was overdue given the significant time and effort required to be an informed and productive delegate. That proposal was defeated by a single actor who obfuscated their voting power and acted to kill the initiative at the 11th hour. While I still feel like abstention is the best path philosophically, at a practical level given the way the vote was decided last time, I regret my previous abstention and vote in favor of this proposal.
Given the scale of the Foundation's upcoming V4 request from the DAO, it is prudent to structure management of these funds and related DAO assets under a committee structure. The structure balances accountability to the DAO with a degree of discretion and industry expertise suited to the need. I acknowledge the existence of a conflict of interest insofar as I have been identified in the proposal as a community member on the committee. That said, this proposal is an important complement to the Foundation's ask: I support Proposal 582 (funding V4) and see passage of this proposal as critical infrastructure to protect and strengthen the DAO under the initiatives launched by Proposal 582.
I am supportive of Gauntlet's relatively strict tightening of supply caps on non-USD mainnet Comets. In addition to the general TVL outflows I cited in my support for Proposal 578, the need to carefully manage caps on staked ETH collateral is especially fraught due to strong correlation among these assets and potential edge-case risks in case an unexpected turn of events in the rsETH recapitalization campaign propagates through these markets.
Significant liquidity exited lending protocols across mainnet following the exploit of the rsETH LayerZero bridge. Conditions justify the significant supply cap reductions proposed by Gauntlet. The ruleset they introduce meaningfully and appropriately tightens risk tolerance across these Comets.
# Delegate Compensation Program (Initial 6-Month Term)
Authors: CGWG ([@AranaDigital](https://www.comp.xyz/u/aranadigital) [@PGov](https://www.comp.xyz/u/pgov)) in collaboration with [@Compound\_Foundation](https://www.comp.xyz/u/compound_foundation)
## Summary
This proposal introduces a Delegate Compensation Program to strengthen Compound governance by tying delegate remuneration to objective, measurable criteria. Delegates are essential to Compound’s governance, but the lack of structured compensation has contributed to declining participation and engagement over time. This is especially important since Compound governance has one of the most active DAOs by number of proposals, requiring material and consistent participation from voters.
We propose a framework that applies consistently across all eligible delegates, rewarding both voting participation and substantive public forum communications, and includes clear oversight mechanisms to maintain accountability. The program would run for an initial six-month pilot period, renewable by subsequent governance action.
This proposal does not modify governance power, voting weight, or delegation mechanics. It solely introduces a structured compensation mechanism to incentivize and reward consistent, high-quality participation.
## Objectives
* Retain and increase voting participation rates
* Improve responsiveness and feedback pertaining to important proposals
* Encourage substantive engagement on the forums
* Align delegate incentives with protocol resilience and long-term health
* Introduce predictable, transparent compensation standards
## Baseline Eligibility
To be eligible for remuneration under this framework, a delegate must:
* Maintain a minimum delegated voting power of 25,000 COMP, equivalent to the effective proposal threshold
* Manage a public delegate statement on the forum and adhere to the [Governance Code of Conduct](https://www.comp.xyz/t/compound-governance-code-of-conduct/7251)
* Provide a publicly accessible communication channel for submitting voting rationales
* Not be under suspension (see Oversight section below)
Eligibility assessments shall be conducted at fixed three-month intervals from the program start date, with updated eligibility taking effect at the beginning of the following calendar month.
## Qualification for Remuneration
### Delegate Selection
At the start of the program, the top 8 eligible delegates, selected based on objective voting participation data, will qualify for remuneration. Every 3 months, these 8 spots will be re-evaluated and members reshuffled based on the metrics below.
Each eligible delegate’s previous 6 months of voting history will be analyzed, with the top 8 qualifying for remuneration. After the first 3 months, the previous 6-month voting history determines updated rankings, allowing for candidates to compensate for missed votes and potentially qualify for future rounds of remuneration.
In the case of a tie between 2 or more candidates, the previous 12-month voting history will be analyzed, then 18 months, then 24 months, and so on.
### Components of Remuneration
Remuneration is split into two components: vote participation and public communication. These criteria pertain to the 8 delegates that pass the delegate selection process.
#### Vote Participation
Delegates that qualify for remuneration must:
* Maintain a minimum 95% participation rate across all onchain governance proposals that reach the voting stage during the month
* “Participation” means casting a vote (For / Against / Abstain) prior to a vote closing
* Failure to meet 95% participation in a given month results in zero vote participation remuneration for that month
* In cases where a delegate is unable to participate in a vote due to verifiable, widespread technical issues (including but not limited to network outages, RPC failures, or wallet malfunctions), the oversight group may, acting reasonably and based on objective evidence, exclude such vote from the participation calculation for that month
#### Public Communication
To qualify for the communication portion of the remuneration, delegates must:
* Publish a written public rationale for 100% of their votes within 3 days of the vote ending.
* A rationale must be substantive and reference proposal content (not boilerplate or generic text). More leniency will be applied for routine market parameter updates and adjustments.
* Rationales are to be posted on a delegate’s “Delegate Platform.” This is intended to create a communication thread that the public can reference to easily access a voter’s collective perspectives.
* Post at least 2 substantive forum contributions relating to governance proposals, risk, treasury, or protocol development. “Substantive” excludes one-line comments, acknowledgments, or purely procedural remarks.
* Attend at least one community call in a given month. These are hosted biweekly and are managed according to [this thread](https://www.comp.xyz/t/compound-community-calls-thread/7272).
Failure to meet any of these requirements results in a proportional reduction of that month’s communication component.
Example: A qualified delegate is expected to give rationales for 6 votes, 2 substantive forum comments, and attend 1 call in a given month. If they provide rationale on 4 votes, 1 comment, and a call, they receive (4 + 1 + 1) / (6 + 2 + 1) = 2/3 of the communication portion.
If a vote crosses over between two months—for instance, a voting period takes place between April and May—then the relevant voting participation rate and associated rationale will count under the May remuneration. Votes are divided based on when a particular voting period concludes. Note that vote “end” refers to the conclusion of the voting period, not upon proposal execution.
## Remuneration Amount
Qualified delegates are eligible to receive up to $4,000 per month, split as follows:
ComponentAmountPayout BasisVote Participation$2,000/monthAll-or-nothing (must meet 95% threshold)Public Communication$2,000/monthProrated based on rationale, forum comments, and call attendance
The vote participation remuneration is all-or-nothing. In other words, delegates must maintain over 95% voting participation in a given month to receive this portion. The public communication remuneration is prorated based on the percentage of voting rationale, substantive forum comments, and call attendance provided. If a delegate does not meet the 95% voting participation rate, they are automatically disqualified from the communication remuneration for that month as well.
Example: A qualified delegate is expected to give rationales for 6 votes, 2 substantive forum comments, and attend 1 call in a given month.
* If they vote on everything, provide rationale on 4 votes, 1 comment, and a call, they receive $2,000 for voting and ~$1333 (⅔\*$2000) for communication of the communication portion. Total = $3,133.
* If they vote on everything and don’t partake in communication, they only receive $2,000.
* If they vote on ⅚ proposals, or 83% of all votes, then Total = $0 since the threshold is 95%.
## Forum Contributions
Delegate Platform and Communication Thread
Each month, qualified delegates are expected to update their Delegate Platform thread with each vote decision and respective rationales. We ask that delegates maintain one forum post that is edited as it is updated.
These communications should be established as a running thread under the initial delegate statement. For formatting, you may reference the outline at the bottom of the [Code of Conduct](https://www.comp.xyz/t/compound-governance-code-of-conduct/7251).
Substantive Comments
As stated in the above section, a delegate must also make 2 substantive forum comments. These comments are not intended to be posted under a delegate’s communication thread. They’re meant to be commented directly under a forum topic. For example, if there’s an RFC related to treasury management, a delegate should comment their substantive contribution as a reply to that forum post. We also encourage delegates to start fresh discussions in the event there aren’t enough active forum posts. A new forum post that initiates discussion will also be acknowledged as a substantive contribution.
## Payment Administration
Payments will be made monthly in USDC, and each delegate’s contribution results will be transparently reported to the forums. Payments shall be calculated and disbursed within a reasonable period following the end of each calendar month, based on the finalised participation and engagement metrics for that month.
Approved funds shall be transferred to a newly created multisig established solely for the administration of delegate remuneration under this framework. The multisig will operate under a 3-of-4 signing threshold, with 2 representatives each from the CGWG and the Compound Foundation.
The multisig shall:
* Hold only the funds allocated for this program
* Disburse monthly payments strictly in accordance with publicly verifiable data
* Publish transaction records and monthly payout summaries in a forum thread
## Transparency, Reporting, and Oversight
### Reporting
A public spreadsheet will be maintained, tracking vote participation percentage and engagement count (rationale posts, forum comments, call attendance) for each delegate. A continuous forum thread will update the community each month.
All voting participation data shall be derived from publicly verifiable onchain governance records (including recognised governance interfaces such as Tally or equivalent), and engagement metrics shall be sourced from the Compound governance forum and officially recognised communication channels.
### Suspension for Suspected Malicious Conduct
Remuneration may be suspended where there is reasonable suspicion that a delegate:
* Is coordinating with known malicious actors
* Is participating in governance manipulation or vote-buying schemes
* Is acting in bad faith to undermine protocol security or integrity
* Is engaged in undisclosed conflicts of interest materially affecting governance behavior
* Or is in violation of any of the other Code of Conduct criteria
### Oversight Group
Suspension determinations shall be made by a 2-party oversight group comprising the Compound Foundation and the CGWG. A unanimous decision of the group is required to impose suspension. The standard is “reasonable suspicion based on objective evidence.”
All suspensions are immediate, and public disclosure will be made. This mechanism applies solely to delegate qualification for remuneration. It does not affect governance power or delegation. Treasury delegation matters, for example, are handled under a different program managed by the CGWG.
The oversight group is also responsible for making final decisions around tracking delegate scores pertaining to voting participation and forum comments.
## Term and Budget
DetailValueInitial Duration6 months from activation—if this proposal passes in the middle of a given month, remuneration tracking will commence on the 1st of the following monthRenewalRequires subsequent governance proposal and approvalReviewA performance and impact review shall be published before renewal
Total Budget: $4,000/delegate × 8 delegates × 6 months = $192,000 USDC (maximum)
If not renewed, this program automatically expires, and any unused USDC will be returned to the treasury. A follow-up will be posted prior to the onchain vote to confirm exactly where assets for funding this proposal will be sourced from.
## Proposal Actions
1. Decrease cUSDCv3 reserves for 192,000 USDC. The reserves are transferred to 0x42a7716cf1f55Fe3F4f6585Aa37349bcbE69D621
# Establishment of Treasury Management Program and Treasury Management Committee
This proposal establishes the Compound Treasury Management Program (TMP) and deploys the on-chain infrastructure required to consolidate and manage protocol treasury assets under the oversight of a newly constituted Treasury Management Committee (TMC).
Upon execution, this proposal:
1. Withdraws deprecated V2 reserves (~$18.95M) to Treasury Escrow.
2. Transfers Aera vault ownership (~$28.21M) from the Governor Timelock to Treasury Timelock.
3. Transfers Avantgarde vault ownership (~$3.8M) from the Governor Timelock to Treasury Timelock.
4. Withdraws V3 surplus reserves (~$6.94M) above the reserve floor to Treasury Escrow.
All withdrawals from Treasury Escrow are subject to a 2-day cooldown before execution, a 7-day expiration window, and Safeguard cancellation rights. The Treasury Timelock enforces a 2-day minimum delay on governance-level operations. Both contracts have been audited by ChainSecurity and Certora.
### Audit
Treasury manager has been audited by [Certora](https://www.certora.com/) and the report can be found [here](https://www.certora.com/reports/compound-treasury-manager).
Full proposal details, fund source methodology, on-chain controls, and TMC composition: [Establishment of Treasury Management Program and Treasury Management Committee](https://www.comp.xyz/t/establishment-of-treasury-management-program-and-treasury-management-committee/7710).
# 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](https://github.com/compound-finance/comet/pull/1116) and [forum discussion](https://www.comp.xyz/t/ethereum-supply-cap-reduction-across-comets/7793).
## 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.
# Ethereum Supply cap Reduction Across USD Based Comets
## Proposal summary
This proposal updates supply caps for a number of assets across the 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](https://github.com/compound-finance/comet/pull/1115) and [forum discussion](https://www.comp.xyz/t/ethereum-supply-cap-reduction-across-comets/7793).
## Proposal actions
1 - 7. Updates supply caps for weETH and mETH to 0 and tBTC to 73, sFRAX to 33M, UNI to 310,336, and LINK to 210,317 on cUSDTv3 market and upgrades the Comet implementation to apply the changes.
8 - 10. Updates supply caps for weETH and tBTC to 0 on cUSDSv3 market and upgrades the Comet implementation to apply the changes.
11 - 14. Updates supply caps for tBTC to 40, UNI to 364,691, and LINK to 585,990 on cUSDCv3 market and upgrades the Comet implementation to apply the changes.
# Ethereum Supply cap Reduction Across Comets
## Proposal summary
This proposal updates supply caps for a number of assets across the 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](https://github.com/compound-finance/comet/pull/1115) and [forum discussion](https://www.comp.xyz/t/ethereum-supply-cap-reduction-across-comets/7793).
## 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.
19 - 25. Updates supply caps for weETH and mETH to 0 and tBTC to 73, sFRAX to 33M, UNI to 310,336, and LINK to 210,317 on cUSDTv3 market and upgrades the Comet implementation to apply the changes.
26 - 28. Updates supply caps for weETH and tBTC to 0 on cUSDSv3 market and upgrades the Comet implementation to apply the changes.
29 - 32. Updates supply caps for tBTC to 40, UNI to 364,691, and LINK to 585,990 on cUSDCv3 market and upgrades the Comet implementation to apply the changes.
# WETH Comets Interest Rate Curve Recommendations on L2 networks
## Simple Summary
Given heightened market activity and elevated volatility across ETH markets Gauntlet recommends the following Interest Rate (IR) Curve updates across WETH comets on Ethereum. These changes are designed to keep borrow costs low and avoid liquidations during the volatile period.
## Motivation
The recent Kelp exploit has led to heightened volatility and shifting dynamics across ETH-correlated assets. In this environment LST/LRT-based looping strategies are facing a significantly high negative carry. The recommendations below flatten the slope below kink and compress the slope above kink resulting in lower kink and max borrow rates across all WETH markets.
The intent is to:
* Keep Compound’s WETH borrow rates not too high so that unwinding can happen gradually in a volatile environment.
* Decrease existing borrow positions gradually without pushing rates to a level that would unwind a high amount of the existing ETH-leverage positions. We will continue to monitor utilization and reserve growth and will adjust as conditions evolve.
## Specification
Target APRs at kink and at 100% utilization across the comets:
| Comet | Kink Rate | Max Rate |
| --------------- | --------- | -------- |
| Base WETH | 1.50% | 3.00% |
| Arbitrum WETH | 1.50% | 3.00% |
| Optimism WETH | 1.50% | 3.00% |
| Linea WETH | 1.50% | 3.00% |
| Unichain WETH | 1.50% | 3.00% |
Borrow kink is held at 90% across all markets. The base rate is held constant at current values. Slope Low and Slope High are updated to achieve the target kink and max rates above. [Forum Post](https://www.comp.xyz/t/weth-comet-interest-rate-curve-recommendations/7749)
# Update rsETH Price Feeds on WETH and wstETH Markets (Mainnet)
## Summary
It is proposed to migrate the rsETH price feeds on the Mainnet WETH and wstETH Comets to a new 'MinMaxConstantPriceFeed' contract. This follows [Gauntlet's proposal](https://www.comp.xyz/t/rseth-oracle-migration-and-temporary-liquidation-pause-on-ethereum-weth-and-wsteth-markets/7772) in response to the April 18 Kelp rsETH bridge exploit, and gives the Community Multisig a faster defensive lever than a full governance cycle.
This is intended as a temporary measure. Once the rsETH situation is resolved, a subsequent governance proposal will revert the price feeds to the prior configuration.
## New Price Feed
The new feed wraps the existing Kelp exchange rate and operates in one of two modes, set by the Community Multisig:
1. **Bounded exchange rate (default).** Passes the Kelp exchange rate through unchanged when it sits between configured 'min' and 'max' bounds. If the rate falls below 'min' or rises above 'max', the feed returns the bound. Setting 'min = 0' and 'max = ∞' reproduces the existing oracle behavior.
2. **Constant price.** Returns a fixed price set by the multisig, bypassing the underlying feed. Intended for cases where the exchange rate can no longer be trusted.
Bounds and mode changes are multisig-only, with no cooldown. A cursory review by SSPs was already performed and a final audit confirmation will be linked on the forum prior to proposal vote.
Implementation details: [PR #1113](https://github.com/compound-finance/comet/pull/1113).
## Proposal Actions
1. Update the rsETH price feed on the Mainnet WETH market.
2. Update the rsETH price feed on the Mainnet wstETH market.
3. Deploy and upgrade the WETH Comet to the new implementation.
4. Deploy and upgrade the wstETH Comet to the new implementation.
On execution, the liquidation pause on rsETH/wrsETH collateral in these markets will be lifted. A follow-up proposal will revert these markets to their prior price feed configuration once the incident is resolved.
# WETH & wstETH Comets Interest Rate Curve Recommendations on Mainnet
## Simple Summary
Given heightened market activity and elevated volatility across ETH markets, Gauntlet recommends the following Interest Rate (IR) Curve updates across WETH comets on Ethereum. These changes are designed to keep borrow costs low and avoid liquidations during the volatile period.
## Motivation
The recent Kelp exploit has led to heightened volatility and shifting dynamics across ETH-correlated assets. In this environment, LST/LRT-based looping strategies are facing a significantly high negative carry.
The recommendations below flatten the slope below kink and compress the slope above kink, resulting in lower kink and max borrow rates across all WETH markets. The intent is to:
* Keep Compound’s WETH borrow rates not too high so that unwinding can happen gradually in a volatile environment.
* Decrease existing borrow positions gradually without pushing rates to a level that would unwind a high amount of the existing ETH-leverage positions.
We will continue to monitor utilization and reserve growth and will adjust as conditions evolve.
## Specification
Target APRs at kink and at 100% utilization across the comets:
| Comet | Kink Rate | Max Rate |
| --------------- | --------- | -------- |
| Ethereum wstETH | 2.00% | 5.00% |
| Ethereum WETH | 2.00% | 5.00% |
Borrow kink is held at 90% across all markets. The base rate is held constant at current values. Slope Low and Slope High are updated to achieve the target kink and max rates above.
[Forum Post](https://www.comp.xyz/t/weth-comet-interest-rate-curve-recommendations/7749)
Supply caps are most important (previous proposal), but this proposal ensures additional borrowing is not possible on rsETH collateral already present in these Comets
# WETH & wstETH Comets Interest Rate Curve Recommendations on Mainnet
## Simple Summary
Given heightened market activity and elevated volatility across ETH markets, Gauntlet recommends the following Interest Rate (IR) Curve updates across WETH comets on Ethereum. These changes are designed to keep borrow costs low and avoid liquidations during the volatile period.
## Motivation
The recent Kelp exploit has led to heightened volatility and shifting dynamics across ETH-correlated assets. In this environment, LST/LRT-based looping strategies are facing a significantly high negative carry.
The recommendations below flatten the slope below kink and compress the slope above kink, resulting in lower kink and max borrow rates across all WETH markets. The intent is to:
* Keep Compound’s WETH borrow rates not too high so that unwinding can happen gradually in a volatile environment.
* Decrease existing borrow positions gradually without pushing rates to a level that would unwind a high amount of the existing ETH-leverage positions.
We will continue to monitor utilization and reserve growth and will adjust as conditions evolve.
## Specification
Target APRs at kink and at 100% utilization across the comets:
| Comet | Kink Rate | Max Rate |
| --------------- | --------- | -------- |
| Ethereum wstETH | 2.00% | 5.00% |
| Ethereum WETH | 2.00% | 5.00% |
Borrow kink is held at 90% across all markets. The base rate is held constant at current values. Slope Low and Slope High are updated to achieve the target kink and max rates above.
[Forum Post](https://www.comp.xyz/t/weth-comet-interest-rate-curve-recommendations/7749)
# Reduce Borrow Collateral Factor and Supply Caps for USDe to 0 on Ethereum
This proposal reduces the Collateral Factor utilized on borrow and Supply Caps for USDe; once executed, USDe on Ethereum markets can not be used as collateral for new loans. Note that this proposal will not directly trigger any liquidations as the liquidation collateral factor remains unchanged.
The proposal will minimize the potential risk of an rsETH hack in case it affects USDe. 
# Reduce Borrow Collateral Factor for rsETH to 0 on Ethereum Markets
This proposal reduces the collateral factor utilized on borrow for rsETH--once executed, rsETH on Ethereum markets can not be used as collateral for new loans. Note that this proposal will not directly trigger any liquidations as the liquidation collateral factor remains unchanged.
Please see the forums for further details
* [Kelp Dao Exploit Discussions](https://www.comp.xyz/t/kelp-daos-rseth-hack-response/7732)
# Update USDC and USDT Comets on Polygon to support more collaterals
## Proposal summary
WOOF! proposes to update both Polygon Comets to a new version, which supports up to 24 collaterals. This proposal takes the governance steps recommended and necessary to update Compound III USDT and USDC markets on Polygon. Simulations have confirmed the market’s readiness, as much as possible, using the [Comet scenario suite](https://github.com/compound-finance/comet/tree/main/scenario).
Further detailed information can be found on the corresponding [proposal pull request](https://github.com/compound-finance/comet/pull/1071) and [forum discussion](https://www.comp.xyz/t/increase-amount-of-collaterals-in-comet/5465).
## Proposal Actions
The first action sets the factory to the newly deployed factory, extension delegate to the newly deployed contract and deploys and upgrades Comet to a new version for all 2 comets: cUSDTv3 and cUSDCv3.
# Update USDe Comet on Mantle to support more collaterals
## Proposal summary
WOOF! proposes to update Mantle cUSDev3 Comet to a new version, which supports up to 24 collaterals. This proposal takes the governance steps recommended and necessary to update Compound III USDe markets on Mantle. Simulations have confirmed the market’s readiness, as much as possible, using the [Comet scenario suite](https://github.com/compound-finance/comet/tree/main/scenario).
Detailed information can be found on the corresponding [proposal pull request](https://github.com/compound-finance/comet/pull/1070) and [forum discussion](https://www.comp.xyz/t/increase-amount-of-collaterals-in-comet/5465).
## Proposal Actions
The first action sets the factory to the newly deployed factory, extension delegate to the newly deployed contract and deploys and upgrades Comet to a new version.
# Update USDC price feed on cWRONv3 on Ronin
## Proposal summary
This proposal updates USDC price feeds to API3, since Chainlink is no longer supported on Ronin.
Further detailed information can be found on the corresponding [proposal pull request](https://github.com/compound-finance/comet/pull/1093).
## Proposal actions
The first proposal action approves the L1CCIPRouter to transfer GHO stable token from the timelock to pay for the proposal execution fee on Ronin.
The second proposal action sends the following encoded calls to the governance receiver on Ronin:
- Update USDC price feed to API3 oracle
- Deploy and upgrade to new configuration via `deployAndUpgradeTo`.
# Deprecate stMATIC in cUSDCv3 on Polygon
## Proposal summary
WOOF! propose to deprecate stMATIC as collateral in cUSDCv3 on Polygon by updating its price feed to a constant price feed with a price of 1 wei and set its supply cap to 0.
Further detailed information can be found on the corresponding [proposal pull request](https://github.com/compound-finance/comet/pull/1094) and [forum discussion](https://www.comp.xyz/t/gauntlet-depreciating-stmatic-on-polygon-usdt-and-usdc-e-comets/7083).
## Proposal actions
The first action updates stMATIC price feed to the constant price feed with a price of 1 wei and sets its supply cap to 0. This sends the encoded 'updateAssetPriceFeed', 'updateAssetSupplyCap' and 'deployAndUpgradeTo' calls across the bridge to the governance receiver on Polygon.
# Update price feeds in cWETHv3 on Unichain with CAPO implementation.
## Proposal summary
This proposal updates existing price feed for wstETH, weETH, ezETH, and rsETH on the cWETHv3 market on Unichain.
### 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, weETH, ezETH, and rsETH price feeds are updated to their CAPO implementation.
Further detailed information can be found on the corresponding [proposal pull request](https://github.com/compound-finance/comet/pull/1068) and [forum discussion for CAPO](https://www.comp.xyz/t/woof-correlated-assets-price-oracle-capo/6245).
### CAPO audit
CAPO has been audited by [OpenZeppelin](https://www.comp.xyz/t/capo-price-feed-audit/6631, as well as the LST / LRT implementation [here](https://www.comp.xyz/t/capo-lst-lrt-audit/7118).
## Proposal actions
The first action updates wstETH, weETH, ezETH, and rsETH price feeds to the CAPO implementation. This sends the encoded 'updateAssetPriceFeed' and 'deployAndUpgradeTo' calls across the bridge to the governance receiver on Unichain.
Voting For. The utilization numbers are clearly very low, so reducing the caps feels like a sensible and precautionary step. It helps limit unnecessary risk without affecting existing users, which is important. Appreciate the data-backed approach here.
# Update rETH price feed in cWETHv3 on Mainnet
## Proposal summary
This proposal updates the rETH price feed in the Compound III WETH market on Ethereum.
Due to the deprecation of the RETH / ETH Chainlink Oracle, the rETH price feed must be replaced with a new CAPO price feed that fetches the rETH / ETH exchange rate directly from the rETH contract. The new price feed retains the same CAPO parameters as the previous one.
Further detailed information can be found on the corresponding [proposal pull request](https://github.com/compound-finance/comet/pull/1097) and [forum discussion for CAPO](https://www.comp.xyz/t/woof-correlated-assets-price-oracle-capo/6245).
### New price feed audit
New CAPO price feed for rETH has been audited by [Certora](https://www.certora.com/reports/compound-reth-capo) and no issues were found.
## Proposal Actions
The first action updates the rETH price feed to the new CAPO contract.
The second action deploys and upgrades Comet to a new version.
# Deprecate stMATIC in cUSDTv3 on Polygon
## Proposal summary
WOOF! propose to deprecate stMATIC as collateral in cUSDTv3 on Polygon by updating its price feed to a constant price feed with a price of 1 wei and set its supply cap to 0.
Further detailed information can be found on the corresponding [proposal pull request](https://github.com/compound-finance/comet/pull/1095) and [forum discussion](https://www.comp.xyz/t/gauntlet-depreciating-stmatic-on-polygon-usdt-and-usdc-e-comets/7083).
## Proposal actions
The first action updates stMATIC price feed to the constant price feed with a price of 1 wei and sets its supply cap to 0. This sends the encoded 'updateAssetPriceFeed', 'updateAssetSupplyCap' and 'deployAndUpgradeTo' calls across the bridge to the governance receiver on Polygon.
# Update price feeds in cUSDCv3 on Base with CAPO and SVR price feeds.
## Resubmit
This proposal is a resubmission of previously passed Proposal 526, as it was not executed on L2.
Original proposal: https://www.tally.xyz/gov/compound/proposal/526
## Proposal summary
This proposal updates existing price feeds for WETH, USDC, cbETH and wstETH assets on the USDC market on Base.
### 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 price feed is updated to their CAPO implementations.
### SVR summary
[RFP process](https://www.comp.xyz/t/oev-rfp-process-update-july-2025/6945) and community [vote](https://snapshot.box/#/s:comp-vote.eth/proposal/0xffd84200f112926e8b21793ee3750f272fc40a3f90399f86d41971a44aa3edf3) passed and decided to implement Chainlink's SVR solution for BASE markets, this proposal updates WETH and USDC price feeds to support SVR implementations.
Further detailed information can be found on the corresponding [proposal pull request](https://github.com/compound-finance/comet/pull/1074), [forum discussion for CAPO](https://www.comp.xyz/t/woof-correlated-assets-price-oracle-capo/6245) and [forum discussion for SVR](https://www.comp.xyz/t/request-for-proposal-rfp-oracle-extractable-value-oev-solution-for-compound-protocol/6786).
### CAPO audit
CAPO has been audited by [OpenZeppelin](https://www.comp.xyz/t/capo-price-feed-audit/6631, as well as the LST / LRT implementation [here](https://www.comp.xyz/t/capo-lst-lrt-audit/7118).
### 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 WETH, USDC, cbETH and wstETH price feeds to the CAPO and SVR implementations. This sends the encoded 'updateAssetPriceFeed', 'setBaseTokenPriceFeed' and 'deployAndUpgradeTo' calls across the bridge to the governance receiver on Base.
# Update price feeds in cUSDCv3 on Arbitrum with SVR price feeds.
## Proposal summary
This proposal updates existing price feeds for WETH, ARB, WBTC and USDC assets on the USDC market on Arbitrum.
Further detailed information can be found on the corresponding [proposal pull request](https://github.com/compound-finance/comet/pull/1077) and [forum discussion for SVR](https://www.comp.xyz/t/request-for-proposal-rfp-oracle-extractable-value-oev-solution-for-compound-protocol/6786).
### 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 WETH, ARB, WBTC and USDC price feeds to the SVR implementation. This sends the encoded 'updateAssetPriceFeed' and 'deployAndUpgradeTo' calls across the bridge to the governance receiver on Arbitrum.
# Return accidentally send funds
## Proposal summary
This proposal returns accidentally sended funds to a cUSDTv3 on Mainnet. Funds will be sent back to the user.
Further detailed information can be found on the corresponding [forum discussion](https://www.comp.xyz/t/woof-correlated-assets-price-oracle-capo/6245).
Accidental transfer tx hash: 0x92b03289ad09323ec897e106442096f3fc07f4c9cee4e02add7ee2b672d865e3
Amount sent: 19_958.414155
User address: 0x34074a8706e952a02f8a3def416bab745b54a3ed
## Proposal actions
The first action withdraws accidentally sent funds from a comet and transfers them back to the user.