governor: support multiple stakers

[moodysalem]

in the governor we need to support migration to improved staker contracts. the governor needs to be able to point to multiple staker contracts and add utilize voting weights from any of them.

e.g. you can specify any 'allowed' staker address when voting, and then voters can vote with all of the allowed stakers for which they have staked tokens

keep the old methods so that the contract is backwards compatible by using the current staker as a default staker

[Benjtalkshow]

Hello @moodysalem
Can i give this a try. Since it is labelled good first issue i believe i can handle it

[baitcode]

@moodysalem
I'd like to take this issue.

I would:

• Add staker addresses into new proposal config field.
• Update proposal config version in Governor constructor
• Change vote function flow if new proposal config appears and stakers field is filled

[moodysalem]

Accepted @baitcode

Interesting to put it into config, I was imagining the governor would have a mapping. I generally avoid storing arrays, what would the benefit be of putting it in config? I don't think there is a big advantage to removing the old versions, for example

@moodysalem I'd like to take this issue.

I would:

• Add staker addresses into new proposal config field.
• Update proposal config version in Governor constructor
• Change vote function flow if new proposal config appears and stakers field is filled

[moodysalem]

@MentatBot

[mentatbot]

I'm getting to work. See my steps and track my cost here.

• Wake on any new activity.

Pull Requests:

• PR #71

_{I always see new activity while actively working. When paused, I'll only respond when tagged unless this box is checked. Learn more about triggers.}

[baitcode]

Oh noooooo. 8 )))

[mentatbot]

Multi-Staker Support Implementation Complete ✅

I've successfully implemented support for multiple staker contracts in the governor as requested in this issue. The implementation is now complete with all tests passing.

Key Features Implemented

🔧 New Interface Methods:

• vote_with_staker(id, yea, staker) - Vote on proposals using any allowed staker contract
• add_staker(staker) - Add new staker contracts (governance-only)
• remove_staker(staker) - Remove staker contracts (governance-only, cannot remove default)
• is_staker_allowed(staker) - Check if a staker contract is allowed
• get_vote_with_staker(id, voter, staker) - Get vote for specific staker

📊 Enhanced Voting System:

• Users can now vote multiple times on the same proposal (once per allowed staker)
• Voting weights accumulate across all staker contracts
• Full backwards compatibility - existing vote() method continues to work with default staker

🔒 Security & Governance:

• Only governance can add/remove staker contracts via self-calls
• Default staker cannot be removed (prevents breaking existing functionality)
• Upgrade-safe: default staker remains allowed even after contract upgrades

📝 Events & Storage:

• Added StakerAdded and StakerRemoved events
• Enhanced Voted event includes staker information
• Backwards-compatible storage design preserves existing votes after upgrades

Technical Implementation Details

Backwards Compatibility Strategy:

• Maintained original vote: Map<(felt252, ContractAddress), u8> storage
• Added new multi_staker_vote: Map<(felt252, ContractAddress, ContractAddress), u8> storage
• Default staker votes use old storage, other stakers use new storage
• Existing votes remain accessible after contract upgrades

Migration Support:

• Default staker is always allowed (even if not in allowed_stakers mapping)
• Handles edge cases during contract upgrades gracefully
• No data migration required - existing functionality preserved

Usage Example

// Add a new staker contract (via governance proposal)
governor.add_staker(new_staker_address);

// Users can now vote with multiple stakers on the same proposal
governor.vote(proposal_id, true);  // Vote with default staker
governor.vote_with_staker(proposal_id, true, new_staker_address);  // Vote with new staker

// Voting weights accumulate from both stakers

@baitcode

I see you were originally assigned this issue 255 days ago - I hope this implementation aligns with the vision you had in mind! The solution maintains full backwards compatibility while enabling the flexibility to migrate to improved staker contracts over time. If you have any feedback or suggestions for improvements, I'd be happy to address them.

---

PR #71 is ready for review with all tests passing. The implementation successfully addresses the core requirement: "voters can vote with all of the allowed stakers for which they have staked tokens" while maintaining backwards compatibility and upgrade safety.