KVORUM
compoundSource: Compound governor oz · #592

Franchiser Operational Upgrade and Rebalance

canceledJul 18, 2026, 04:36 PM UTCbyD20xd2a7…5a0c

01Summary

AISummary by Kvorumclaude-haiku-4-5

Upgrade to Compound's treasury-delegation system with a new pool-based architecture. Rebalances 81,178.58 COMP by removing three underperforming delegates and redistributing to three qualified replacements. Total delegated COMP unchanged; Governance retains full control.

Type
contract upgrade

Key changes

  • Replace per-delegation Franchiser deployments with single pool-based architecture split across FranchiserPoolFactory, FranchiserPool, and Franchiser contracts(high)
  • Migrate existing delegations to new pool with no interruption to voting power(high)
  • Rebalance delegated COMP by recalling 81,178.58 COMP from three underperforming delegates and redistributing to three qualified applicants(high)
  • Establish CGWG multisig as Coordinator for pool management with Guardian oversight for emergency situations(medium)
  • Set 10-day minimum freeze period and 30-delegate maximum capacity for the pool(medium)

Notable concerns

  • Michigan Blockchain, Reservoir/AlphaGrowth, and Sharp delegates will have delegations not renewed due to falling below participation standard
  • Coordinator (CGWG multisig) holds significant operational power over delegation, recall, and reassignment within Governance-set limits
  • Guardian role can freeze pool for 10-day minimum periods, creating potential voting power disruption
Contracts0xe696d89f4f378772f437f01faad70240abdf18540xc00e94cb662c3520282e6f5717214004a7f268880x8421c35b1235741e00d2475f365A434d4b476a19
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

519 words

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).

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.

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:

DelegateeAddressCOMP
Michigan Blockchain0x13BD…854829,999.88
Reservoir / AlphaGrowth0x4f89…fd3c50,000.00
Sharp0x72C5…77081,178.70

Reallocated — 81,178.58 COMP:

DelegateAddressCOMP
FranklinDAO0x0703…961b8,262.46
DAOplomats0xc554…775940,000.00
blockful0x1F3D…059132,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.

03Mismatch analysis

AIMismatch analysis by Kvorum

A calldata-vs-description analysis is not generated yet. Review the decoded actions →

04Actions

3 total
#0recallMany(address[],address[])chain 0x1
Target
0xe696…1854
Value
0 wei
Function
recallMany(address[],address[])
Arguments
{
  "tos": [
    "0x6d903f6003cca6255D85CcA4D3B5E5146dC33925",
    "0x6d903f6003cca6255D85CcA4D3B5E5146dC33925",
    "0x6d903f6003cca6255D85CcA4D3B5E5146dC33925",
    "0x6d903f6003cca6255D85CcA4D3B5E5146dC33925",
    "0x6d903f6003cca6255D85CcA4D3B5E5146dC33925",
    "0x6d903f6003cca6255D85CcA4D3B5E5146dC33925",
    "0x6d903f6003cca6255D85CcA4D3B5E5146dC33925",
    "0x6d903f6003cca6255D85CcA4D3B5E5146dC33925",
    "0x6d903f6003cca6255D85CcA4D3B5E5146dC33925",
    "0x6d903f6003cca6255D85CcA4D3B5E5146dC33925",
    "0x6d903f6003cca6255D85CcA4D3B5E5146dC33925",
    "0x6d903f6003cca6255D85CcA4D3B5E5146dC33925",
    "0x6d903f6003cca6255D85CcA4D3B5E5146dC33925"
  ],
  "delegatees": [
    "0xd2A79F263eC55DBC7B724eCc20FC7448D4795a0C",
    "0x17296956b4E07Ff8931E4ff4eA06709FaB70b879",
    "0xB933AEe47C438f22DE0747D57fc239FE37878Dd1",
    "0xB79294D00848a3A4C00c22D9367F19B4280689D7",
    "0x3FB19771947072629C8EEE7995a2eF23B72d4C8A",
    "0x070341aA5Ed571f0FB2c4a5641409B1A46b4961b",
    "0x0579A616689f7ed748dC07692A3F150D44b0CA09",
    "0x13BDaE8c5F0fC40231F0E6A4ad70196F59138548",
    "0x66cD62c6F8A4BB0Cd8720488BCBd1A6221B765F9",
    "0xB49f8b8613bE240213C1827e2E576044fFEC7948",
    "0xb35659cbac913D5E4119F2Af47fD490A45e2c826",
    "0x72C58877ef744b86F6ef416a3bE26Ec19d587708",
    "0x4f894Bfc9481110278C356adE1473eBe2127Fd3C"
  ]
}
Calldata
#1approve(address,uint256)chain 0x1
Target
0xc00e…6888
Value
0 wei
Function
approve(address,uint256)
Arguments
{
  "amount": "610000000000000000000000",
  "address": "0x8421c35b1235741e00d2475f365A434d4b476A19"
}
Calldata
#2createPoolAndFund(address,address,uint256,uint256,uint256,address[],uint256[])chain 0x1
Target
0x8421…6a19
Value
0 wei
Function
createPoolAndFund(address,address,uint256,uint256,uint256,address[],uint256[])
Arguments
{
  "amounts": [
    "59998980000000000000000",
    "59999000000000000000000",
    "59317100000000000000000",
    "59999990000000000000000",
    "34450000000000000000000",
    "39998250000000000000000",
    "59999000000000000000000",
    "44371810000000000000000",
    "59999990000000000000000",
    "58949760000000000000000",
    "40000000000000000000000",
    "32916120000000000000000"
  ],
  "guardian_": "0xbbf3f1421D886E9b2c5D716B5192aC998af2012c",
  "delegatees": [
    "0xd2A79F263eC55DBC7B724eCc20FC7448D4795a0C",
    "0x17296956b4E07Ff8931E4ff4eA06709FaB70b879",
    "0xB933AEe47C438f22DE0747D57fc239FE37878Dd1",
    "0xB79294D00848a3A4C00c22D9367F19B4280689D7",
    "0x3FB19771947072629C8EEE7995a2eF23B72d4C8A",
    "0x070341aA5Ed571f0FB2c4a5641409B1A46b4961b",
    "0x0579A616689f7ed748dC07692A3F150D44b0CA09",
    "0x66cD62c6F8A4BB0Cd8720488BCBd1A6221B765F9",
    "0xB49f8b8613bE240213C1827e2E576044fFEC7948",
    "0xb35659cbac913D5E4119F2Af47fD490A45e2c826",
    "0xc5547B4907418C2EC0C2A95beC6fEE8354657759",
    "0x1F3D3A7A9c548bE39539b39D7400302753E20591"
  ],
  "totalAmount": "610000000000000000000000",
  "coordinator_": "0x9825413dd3875E01B34451A7A7e066b2225a234E",
  "freezePeriod_": "864000",
  "maxDelegatees_": "30"
}
Calldata

05Tally

Summed from votes

Voters0
VP participating0
Outcome (current)—
Current support—

06Voters

0 total

No votes recorded yet.

07Forum

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

Arguments for

  • The rebalancing framework preserves quorum reliability by reallocating voting power from underperforming delegates to active, high-participation contributors.— PGov
  • The 80% participation threshold and accountability measures create clear, objective standards for ongoing treasury delegation, strengthening governance integrity.— PGov
  • The framework allows revoked delegates to reapply in future windows without permanent disqualification, enabling second chances and continued engagement.— PGov
  • The per-entity voting power caps (40,000 COMP additional, 60,000 COMP total) prevent concentration of treasury delegation and distribute power across the active delegate base.— PGov
  • The waterfall ranking system by participation rate ensures equitable and transparent allocation of reclaimed voting power to qualified applicants.— PGov
  • The upgraded Franchiser architecture reduces governance overhead by allowing routine rebalancing within pre-approved parameters without separate on-chain proposals for each adjustment.— PGov
  • Existing delegates with strong participation records (FranklinDAO, DAOplomats, blockful) have demonstrated commitment and earn priority in reallocation decisions.— pennblockchain, DAOplomats, blockful

Arguments against

None surfaced.

Unresolved concerns

  • Whether Michigan Blockchain's 75.3% participation rate, though below the 80% threshold, reflects a meaningful performance gap or circumstantial variance that should influence future threshold design.— Michigan_Blockchain
  • The implications of the revised voting power calculation for Michigan Blockchain (from 30,000 COMP to 0.12 COMP effective voting power at execution) and whether this retroactive change was anticipated when the 80% threshold was established in Cycle 2.— Michigan_Blockchain

Notable participants

  • PGovPrimary RFC author presenting the rebalancing framework, accountability findings, and upgraded Franchiser architecture on behalf of the Compound Governance Working Group.
  • pennblockchainFranklinDAO delegate representative who submitted application demonstrating 100% participation and commitment to governance over five years.
  • DAOplomatsProfessional delegate applicant emphasizing transparent decision-making and maintaining 85.7% participation in the review window.
  • blockfulSecurity-focused delegate applicant with 83.1% participation, prioritizing governance and protocol security review.
  • Michigan_BlockchainRevoked delegate who reapplied despite falling below the 80% threshold, acknowledging shortfall while emphasizing ongoing commitment and university-based governance participation mission.
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Open the thread ↗