In GovernorCountingFractional.sol , the ProposalVote struct is defined in the following order: againstVotes , forVotes , abstainVotes . This order aligns with the standard usage in OpenZeppelin's contracts library as well as in Compound's Bravo.
However, the voteData bytes parameter received by the _countVote function requires a different order: forVotes , againstVotes , abstainVotes . While the code currently handles the decoding of this bytes parameter correctly, this inconsistency in the ordering can be problematic for projects that are integrating with the GovernorCountingFractional
contract.
In GovernorCountingFractional.sol , the ProposalVote struct is defined in the following order: againstVotes , forVotes , abstainVotes . This order aligns with the standard usage in OpenZeppelin's contracts library as well as in Compound's Bravo.
However, the voteData bytes parameter received by the _countVote function requires a different order: forVotes , againstVotes , abstainVotes . While the code currently handles the decoding of this bytes parameter correctly, this inconsistency in the ordering can be problematic for projects that are integrating with the GovernorCountingFractional contract.