# Validator Group Voter Reward Commission

**URL:** <https://forum.celo.org/t/validator-group-voter-reward-commission/13392>\
**Category:** Governance\
**Created:** [June 4, 2026, 5:23pm UTC](https://forum.celo.org/t/validator-group-voter-reward-commission/13392 "2026-06-04T17:23:23Z")\
**Posts on this page:** 1\
**Showing post:** 9

<div class="post-metadata">

**Author:** ![webx379](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.celo.org/webx379/32/12110_2.png) [@webx379](https://forum.celo.org/u/webx379)\
**Post date:** [June 11, 2026, 8:22am UTC](https://forum.celo.org/t/validator-group-voter-reward-commission/13392/9 "2026-06-11T08:22:46Z")

</div>

This is interesting message, I think the upgrade is good and I want to share the message and keep in my box also

> [@stCELO: Withdrawal flow improvements (Account, Manager, DefaultStrategy, SpecificGroupStrategy upgrade)](https://forum.celo.org/t/stcelo-withdrawal-flow-improvements-account-manager-defaultstrategy-specificgroupstrategy-upgrade/13427/1):
>
> **`Manager`\*\*** — threads the distribution context through to the strategies for the above.
> 
> **## Technical details**
> 
> New implementations (deployed and source-verified on **\*\*Celoscan\*\*** and **\*\*Blockscout\*\*** ):
> 
> | Contract | Proxy (unchanged) | New implementation |
> 
> |—|—|—|
> 
> | Account | `0x4aAD04D41FD7fd495503731C5a2579e19054C432` | `0x3a81b5bd5c719cd57d9122d34a093119d61c8117` |
> 
> | Manager | `0x0239b96D10a434a56CC9E09383077A0490cF9398` | `0xbc465bbf2e2d71c62eda1b24061916877f6ae15e` |
> 
> | DefaultStrategy | `0x3A3ed74B1cC543D5EB323f70ac2F19977a0eA088` | `0xac294abf757dd2890c65751dcc095152c27b3416` |
> 
> | SpecificGroupStrategy | `0xb88af6EAc9cd146D8b03b66708EF76beBD937871` | `0x9cbbb5b84dc3dec31daea36c53bdfe145cb40e9d` |
> 
> | AddressSortedLinkedList (library) | — | `0x1f2030b177ea2d1ef457e4311d4ace5a920381a1` |
> 
> **\*\*Upgrade safety\*\***
> 
> - Storage layouts are **\*\*identical\*\*** to the current implementations (verified by per-slot layout diff and on-fork upgrade with live state preserved). No new state variables, no reordering.
> 
> - Deployed bytecode matches the published source byte-for-byte (aside from the standard per-deployment immutable addresses).
> 
> - Validated end-to-end on a fork of current mainnet: the upgrade applies, existing protocol state is preserved, and withdrawals continue to function.
> 
> **## On-chain action**
> 
> This upgrade will be submitted as an on-chain **\*\*Celo Governance proposal\*\*** and follow the standard governance lifecycle (referendum vote, then execution by Celo Governance). It is not executed directly by the stCELO MultiSig — the MultiSig only serves as the proxies’ owner contract, and its `governanceProposeAndExecute` function is callable exclusively by Celo Governance for exactly this purpose.
> 
> The proposal contains a single transaction, which performs all four `upgradeTo` calls atomically:
> 
> - **\*\*To:\*\*** `0x78DaA21FcE4D30E74fF745Da3204764a0ad40179` (stCELO MultiSig)
> 
> - **\*\*Value:\*\*** `0`
> 
> - **\*\*Function:\*\*** `governanceProposeAndExecute(address[],uint256[],bytes[])`
> 
> - destinations: `[Account, DefaultStrategy, SpecificGroupStrategy, Manager]` proxies
> 
> - values: `[0, 0, 0, 0]`
> 
> - payloads: `upgradeTo(newImpl)` for each, in that order
> 
> If the proposal passes referendum, execution by Celo Governance triggers the MultiSig to apply all four upgrades in one transaction.
> 
> **## Risk**

---

_[View the full topic](https://forum.celo.org/t/validator-group-voter-reward-commission/13392)._