Add voting functions with additional bytes parameter for downstream implementations (e.g., multipliers)

[RonTuretzky]

Feature Request: Voting with Additional Bytes for Downstream Implementations

Motivation

Enable voting modules to accept arbitrary bytes data that can be handled by downstream implementations, providing flexibility for features like custom multipliers, metadata, or other protocol-specific parameters.

This follows the pattern established in the Breadchain repository, which implements a sophisticated voting multipliers system through castVoteWithMultipliers function. However, the current BreadKit voting module implementation lacks a generic mechanism to pass additional data to voting functions.

Context from Breadchain

The Breadchain repo demonstrates advanced voting features:

• VotingMultipliers.sol: Manages allowlisted multipliers for voting power calculation
• castVoteWithMultipliers: Accepts multiplier indices to apply different voting power modifiers
• Multiple multiplier types: NFT-based, proveable, cross-chain, etc.

Reference: Breadchain VotingMultipliers Implementation

Current Limitation

The current BreadKit voting module only supports:

function castVoteWithSignature(
    address voter, 
    uint256[] calldata points, 
    uint256 nonce, 
    bytes calldata signature
) external;

There's no mechanism to pass additional protocol-specific data that downstream implementations might need.

Proposed Solution

Add new voting functions that accept an additional bytes parameter, following OpenZeppelin Governor patterns:

// In AbstractVotingModule or concrete implementations
function castVoteWithSignatureAndParams(
    address voter,
    uint256[] calldata points,
    uint256 nonce,
    bytes calldata signature,
    bytes calldata additionalData
) external virtual;

// Internal processing
function _processVoteWithParams(
    address voter,
    uint256[] calldata points,
    uint256 votingPower,
    bytes calldata additionalData
) internal virtual {
    // Default implementation calls standard _processVote
    _processVote(voter, points, votingPower);
    
    // Hook for downstream implementations
    _handleAdditionalVoteData(voter, points, votingPower, additionalData);
}

// Hook for downstream implementations to override
function _handleAdditionalVoteData(
    address voter,
    uint256[] calldata points,
    uint256 votingPower,
    bytes calldata additionalData
) internal virtual {
    // Default: no-op, can be overridden
}

Use Cases

1. Multipliers System (like Breadchain):

   • Pass multiplier contract addresses or indices
   • Include proof data for proveable multipliers
   • Support cross-chain multiplier verification data

2. Metadata Attachment:

   • Voting reasons or comments
   • Reference links or IPFS hashes
   • Category tags or labels

3. Conditional Voting:

   • Time-locked votes
   • Conditional execution parameters
   • Delegated voting instructions

4. Protocol-Specific Features:

   • Custom scoring algorithms
   • Weighted voting parameters
   • Quadratic voting coefficients

Implementation Considerations

1. Backward Compatibility: Keep existing functions unchanged
2. Gas Efficiency: Additional data only processed when provided
3. Event Emission: Include additional data in VoteCast events
4. Signature Verification: Update EIP-712 typehash if including additional data in signatures
5. Validation: Let downstream implementations handle validation of additional data

Benefits

• Extensibility: Future features can be added without modifying core contracts
• Composability: Different protocols can implement their own logic
• Consistency: Follows established patterns from OpenZeppelin and Breadchain
• Flexibility: Supports wide range of use cases without prescribing specific implementations

Technical Approach

1. Add optional bytes parameter to voting functions
2. Create virtual hook functions for processing additional data
3. Update events to include additional data when present
4. Maintain all existing security checks and validations
5. Document patterns for downstream implementations

Related Issues

• Implement Voting Module #2 - Original voting module design
• Backlog: Store required votes at proposal creation in VotingRecipientRegistry #43 - VotingRecipientRegistry integration
• Voting Module Implementation Status: Comparison with Issue #2 Design & Remaining Tasks #61 - Current voting module implementation status

References

• Breadchain VotingMultipliers
• OpenZeppelin Governor - castVoteWithReasonAndParams pattern
• EIP-712 - For signature updates if needed

This enhancement would significantly increase the flexibility of the voting module while maintaining clean separation of concerns and allowing downstream protocols to implement their specific requirements.

[RonTuretzky]

Moving to TODO; a full feature spec for votiing multipliers would be more effective

[RonTuretzky]

RonTuretzky/vote-with-params draft is in this branch