Add the possibility to include ERC721 token voting within OZ Governor module

🧐 Motivation As stated in the governance introductory article:

OpenZeppelin Contracts contain the most common requirements out of the box. Beyond these, OpenZeppelin Governor could potentially be configured with ERC721 voting power so certain NFT owners can participate in governance when specified.

I was wondering if such possibility is already explored somewhere or not yet… I imagine the customization and usecases could be infinite, but what would imply to have a basic version of the OZ Governor that uses ERC721 tokens to create proposals, delegate and vote?

This issue is a continuation of the https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2868 one. In this thread I explain a little bit more the usecase I’m working on.

📝 Details Following @Amxx suggestions I drafted 3 new contracts:

• GovernorERC721Votes: A new governance flavor extension for voting weight extraction from an ERC721Votes token.
• ERC721Votes: A clone of ERC20Votes, with the same functions - included getPastVotes - but that inherits NFTPermit instead of draft-ERC20Permit
• NFTPermit: A draft implementation of Permit for the ERC721 token (taken from here)

As I am not really proficient with solidity, I expect there’s lot of devil in the details when implementing even the most trivial things, so I was wondering if I’m totally out of track or not?

[Amxx]

@omer2307 It’s marked as draft because it depends on EIP712, which is not final

[Amxx]

I can’t say we thought about this.

We considered that the uint8 support, introduced by bravo, could be used in many different ways? It can be an enum, but it could also be a ranking. These “grades” would be used to compute the weighted average and decide the outcome of the vote.

For maximum bravo compatibility, we wanted our external function to share the same signature, so we couldn’t add/remove or even change the types of the existing parameters. That being said, if you want to implement your approach, you can have the castVote, castVoteWithReason and castVoteBySig function disabled (by overriding _castVote with an empty function that reverts, and add functions of you own.

Interfaces that are commonly use to vote on compound like governors will not be able to have users vote, but the rest of the system (proposal / queueing/ execution) should be transparent.

you system would have to :

• create new public voting function
• extract the weight of each vote
• prevent double voting
• implement the _quorumReached and _voteSucceeded function

Note, the propose function requires getVotes to exist, so you may need to expose something like the NFT balance even though you don’t use that for the actual voting