ERC1155Votes

[toledoroy]

What about ERC1155Votes?

🧐 Motivation

1. seems to be the natural next step
2. DAOs are looking for ways to separate themselves into smaller groups (guild/pods/etc), each with it's own responsibilities and power. The ERC1155 multi-token standard can help with that.

📝 Details
An implementation of Votes for the ERC1155 contract that will allow different voting weight for different tokens.

My thoughts is that this should be possible to implement in much the same method used here
https://github.com/toledoroy/openzeppelin-contracts_NFVotes/blob/master/contracts/token/ERC721/extensions/ERC721VotesNF.sol

Please share your thoughts 🙏

[toledoroy]

I see this doesn't have nearly as much appeal as I've imagined.
Anyway, I did go ahead and put some of my thoughts down in code, so I'll go ahead and share some of the possible implementation:

1. Treat NFT voting power as fungible voting power. [units = total token amount]
   https://github.com/toledoroy/openzeppelin-contracts_NFVotes/blob/1155Votes/contracts/token/ERC1155/extensions/ERC1155VotesF.sol
2. Treat tokens as different and assign each token a different voting power. [units = tokenIdtoken poweramount]
   https://github.com/toledoroy/openzeppelin-contracts_NFVotes/blob/1155Votes/contracts/token/ERC1155/extensions/ERC1155VotesNF.sol
3. Treat tokens as different and allow changing their value retroactively. (I don't have that figured out yet. still working out the design)
   https://github.com/toledoroy/openzeppelin-contracts_NFVotes/blob/1155Votes/contracts/token/ERC1155/extensions/ERC1155VotesRetro.sol

[jaketimothy]

Example built on solmate/base https://github.com/z0r0z/zolidity/blob/main/src/gov/ERC1155Votes.sol

[Amxx]

Example built on solmate/base https://github.com/z0r0z/zolidity/blob/main/src/gov/ERC1155Votes.sol

This example doesn't move update votes when token are transfered. This by itself is a critical bug. Be carefull before using or even advertising this.

[jaketimothy]

@toledoroy Would love your thoughts on my proposed direction.

I have a need for multi-token voting - think multi-class shares. The voting power for any one token needs to be configurable by a higher level auth - the parent org.

My intention is to create the base voting unit tracking and then build a governor on top of this that handles the voting weights.

Would this serve your needs as well?

[toledoroy]

Hi @jaketimothy
Yes, definitely.
The current solution is good because it works with the same gov contracts. So it's simple.
Though, for better management of voting power, and to make changes to power after token creation, it seems the best way is to handle voting power on the governor contract side.

[kwizzn]

@jaketimothy, I support your approach. We also have a use case where it makes a lot of sense to configure the voting power of individual tokens on the parent level. In fact, ERC1155 voting would provide even more utility than ERC721.

[z0r0z]

Example built on solmate/base https://github.com/z0r0z/zolidity/blob/main/src/gov/ERC1155Votes.sol

This example doesn't move update votes when token are transfered. This by itself is a critical bug. Be carefull before using or even advertising this.

Hi — quick comments from zauthor: I am opinionated to treating each ID like an ERC20 with own accounting. The example ERC1155Votes @jaketimothy linked was just that, an example, and an abstract contract, that should be inherited. I have a few contracts in production that do that just, but will make a note in code comments. Not sure why it should not be linked here.

Anyways ~~ I think an ERC1155Votes would be a great addition to Governor toolkit!

[frangio]

A simple ERC-1155 token where one of the token ids can be used for voting is very simple to implement using Votes.sol:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.9;

import "@openzeppelin/contracts/governance/utils/Votes.sol";
import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

// WARNING: UNTESTED
abstract contract ERC1155Votes is ERC1155, Votes {
    uint256 constant public VOTING_TOKEN_ID = 42;

    function _getVotingUnits(address account) internal view virtual override returns (uint256) {
        return balanceOf(account, VOTING_TOKEN_ID);
    }

    function _afterTokenTransfer(
        address operator,
        address from,
        address to,
        uint256[] memory ids,
        uint256[] memory amounts,
        bytes memory data
    ) internal virtual override {
        for (uint256 i = 0; i < amounts.length; i++) {
            if (ids[i] == VOTING_TOKEN_ID) {
                _transferVotingUnits(from, to, amounts[i]);
            }
        }
        super._afterTokenTransfer(operator, from, to, ids, amounts, data);
    }
}

contract MyToken is ERC1155, ERC1155Votes {
    constructor() ERC1155("") EIP712("MyToken", "1") {}

    function _afterTokenTransfer(
        address operator,
        address from,
        address to,
        uint256[] memory ids,
        uint256[] memory amounts,
        bytes memory data
    ) internal virtual override(ERC1155, ERC1155Votes) {
        super._afterTokenTransfer(operator, from, to, ids, amounts, data);
    }
}

---

If instead you want all token ids to count towards voting power, this is not as easy, there's a difficulty that comes from not having a balanceOf function across all ids.

Here's an incomplete skeleton and some comments showing this:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.9;

import "@openzeppelin/contracts/governance/utils/Votes.sol";
import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

// WARNING: INCOMPLETE IMPLEMENTATION
abstract contract ERC1155Votes is ERC1155, Votes {
    function _getVotingUnits(address account) internal view virtual override returns (uint256) {
        // TODO: This function should return total balance across all ids.
        // This value is not available in standard ERC1155 so it requires
        // an additional storage variable to track it.
        revert();
    }

    function _afterTokenTransfer(
        address operator,
        address from,
        address to,
        uint256[] memory ids,
        uint256[] memory amounts,
        bytes memory data
    ) internal virtual override {
        for (uint256 i = 0; i < amounts.length; i++) {
            _transferVotingUnits(from, to, amounts[i]);
        }
        super._afterTokenTransfer(operator, from, to, ids, amounts, data);
    }
}

contract MyToken is ERC1155, ERC1155Votes {
    constructor() ERC1155("") EIP712("MyToken", "1") {}

    function _afterTokenTransfer(
        address operator,
        address from,
        address to,
        uint256[] memory ids,
        uint256[] memory amounts,
        bytes memory data
    ) internal virtual override(ERC1155, ERC1155Votes) {
        super._afterTokenTransfer(operator, from, to, ids, amounts, data);
    }
}

[z0r0z]

That looks like a clean way to handle via Votes.sol @frangio. In the case where we want to use all IDs as potential points of voting power, but not cumulatively (for example, ID 0 uses Governor0, ID 1 uses Governor1, etc.), I think this could be similarly handled. Thoughts? My own work around this kind of ERC1155Votes is opinionated in using timestamp but I can see this can be conveniently integrated via ERC6372 which you support in Votes.sol. If there could be a way to pass arbitrary IDs into checkpointing system, that would be ideal. The remaining question is whether events need to be adapted to memo IDs.

[yvesbou]

I'm curious if there is any progress/update on this matter @toledoroy @z0r0z ?

[toledoroy]

Hi,
I haven't heard anything outside this post.