SETUP-44: Update 2 staking beneficiary addresses

Governance
1

Summary

This proposal calls transferBeneficiary on two OperatorRewarder contracts on Ethereum mainnet, replacing the current beneficiary 0x31bBD7a242A38372DE92CA304fE29C12C90A382C with new addresses on each: 0x4d44418328e0bbe8FD9cDDE2A9FfdAe7f209F6cE on the Conduit KMS rewarder and 0xc49376C4D044011eEce6eE69eFAe06f0Cc2bd008 on the Artifact Coprocessor rewarder. If it passes, each of those addresses becomes the only address able to set the operator fee (setFee) and claim accrued fees (claimFee) on its rewarder. Nothing else changes: fee rates, delegator rewards, and staked balances are untouched.

Motivation & Context

Each OperatorStaking deployment creates an OperatorRewarder whose beneficiary is fixed at construction.

No execution ordering constraints: this proposal is self-contained and independent of any other pending proposal.

Proposed Changes

Both actions execute on Ethereum mainnet in a single transaction.

  • Action 1: transferBeneficiary(0x4d44418328e0bbe8FD9cDDE2A9FfdAe7f209F6cE) on the OperatorRewarder for Conduit / KMS at 0x13332Ceadc4c00e50955BD84F8aA9E9f6D007849 — replaces the current beneficiary 0x31bBD7a242A38372DE92CA304fE29C12C90A382C, so setFee and claimFee on that rewarder become callable only by the new address.

  • Action 2: transferBeneficiary(0xc49376C4D044011eEce6eE69eFAe06f0Cc2bd008) on the OperatorRewarder for Artifact / Coprocessor at 0x661305a9b15691d05B2238404949fE164eA4ca75 — replaces the current beneficiary 0x31bBD7a242A38372DE92CA304fE29C12C90A382C, with the same effect on that rewarder.

Technical Details

  • Network: Ethereum mainnet.

  • Target contract(s) & addresses: both target contracts are published in protocol-registry as OPERATOR_REWARDER_CONDUIT_KMS (0x13332Ceadc4c00e50955BD84F8aA9E9f6D007849) and OPERATOR_REWARDER_ARTIFACT_COPROCESSOR (0x661305a9b15691d05B2238404949fE164eA4ca75).

  • Beneficiary addresses (arguments): 0x4d44418328e0bbe8FD9cDDE2A9FfdAe7f209F6cE and 0xc49376C4D044011eEce6eE69eFAe06f0Cc2bd008

  • Authority: transferBeneficiary is onlyOwner, and OperatorRewarder.owner() returns protocolStaking().owner(). Both PROTOCOL_STAKING_KMS (0xe9b176CCaA8840DC3b3567bb83e2cD2a6c36F4Ab) and PROTOCOL_STAKING_COPROCESSOR (0x7147485b892158f2B875f7aC5Ea48A9937C66AE8) are owned by PROTOCOL_DAO (0xB6D69D5F334d8B97B194617B53c6aB62f8681Ef3) per protocol-registry, so the DAO is the authorized caller.

  • Magic constants / encoded data: None.

  • Cross-chain: None.

  • Code / PR references: OperatorRewarder.transferBeneficiary and its internal _transferBeneficiary (rejects the zero address and a no-op re-set) in contracts/staking/contracts/OperatorRewarder.sol.

Other considerations

  • Unclaimed fees follow the new beneficiary. _transferBeneficiary deliberately does not claim outstanding fees for the outgoing beneficiary.

  • Fee control moves with the beneficiary. Each new address can call setFee up to that rewarder’s maxFeeBasisPoints, which only the DAO can raise. The proposal changes no fee value itself.

  • No effect on stake or delegator rewards. Delegator balances, claimRewards, staking, and unstaking behaviour are unaffected.

  • Atomic and revert-sensitive. Both actions run in one execution transaction. _transferBeneficiary reverts with BeneficiaryAlreadySet if a rewarder’s beneficiary already equals the proposed value, which would fail the whole proposal — worth re-checking beneficiary() on both rewarders shortly before execution if any other beneficiary proposal lands first.

  • Reversible by the DAO only. A later DAO proposal can call transferBeneficiary again; a beneficiary cannot change itself.

Resources

1 Like