Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Token & Hybrid Voting #915

Open
wants to merge 3 commits into
base: develop
Choose a base branch
from
Open

Token & Hybrid Voting #915

wants to merge 3 commits into from

Conversation

kronosapiens
Copy link
Member

@kronosapiens kronosapiens commented Dec 24, 2020

Closes #90

This PR introduces two new extensions: VotingToken.sol and VotingHybrid.sol. As expected, VotingToken implements token-based voting, while VotingHybrid implements joint reputation- and token-based voting, defined as requiring both reputation- and token-weighted votes to pass.

VotingToken

VotingToken implements similar voting logic to VotingReputation, with the material difference being that token balances are used to determine "influence", rather than domain-specific reputation balances. This difference has a number of implications:

  • Every token vote must place a lock on the token. To do this, we introduce authorized functions in the colony to place locks on the token.* This function is restricted to extensions managed by ColonyNetwork.
  • Token balances are not domain-specific, so VotingToken only supports root-level motions. Note that you can still hold a token vote on an issue pertaining to a domain (such as an expenditure, or to do arbitration) but the vote still "takes place" in the root.
  • To simplify the implementation of VotingToken and enable code re-use between token and reputation voting, "reputation" and "token balances" have been abstracted into "influence". All voting implementations must implement a getInfluence function which is called by the base contract when tabulating votes / calculating rewards.

** Note that technically, the restriction achieves little, since there is nothing preventing a bad actor from creating a separate colony to grief holders of a token by placing arbitrary locks. As a friction, however, it should reduce the incidence of attack.

VotingHybrid

Hybrid voting is implemented as a voting contract which uses two influence values instead of one. Otherwise, it behaves very similarly to Token voting, in that motions are root-level only and involve placing locks on the tokens.

@area
Copy link
Member

area commented Aug 11, 2021

Yep, you're right, I think I nope'd out at the summing of the yayVotes and didn't look further when I should have.

Copy link
Member

@area area left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In recognition of #928, should there be something to do with escalation on VotingBase, even if it's just a virtual function that needs to be implemented on contracts that inherit?

/// @notice Called when uninstalling the extension
function uninstall() public override auth {
selfdestruct(address(uint160(address(colony))));
return 1;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The implication here that this is a totally new contract, that people won't be upgrading from the old one (a viewpoint also supported by the storage changes)? In which case, this definitely needs a new identifier, and I would argue this should be a totally separate contract, with the old (not-abstracted) contract and test suite still present.

contracts/extensions/VotingBase.sol Outdated Show resolved Hide resolved
contracts/extensions/VotingReputation.sol Outdated Show resolved Hide resolved
contracts/extensions/VotingToken.sol Outdated Show resolved Hide resolved
contracts/extensions/VotingBase.sol Outdated Show resolved Hide resolved
@kronosapiens kronosapiens force-pushed the feat/all-voting branch 2 times, most recently from 1a26a6d to a24be9b Compare August 16, 2021 20:28
@kronosapiens
Copy link
Member Author

Following on the discussion in #product-private, we will proceed by disabling the fast-forward functionality for token & hybrid votes, on the grounds that these votes are intended to be infrequent and high-stakes, making the fast-forward functionality (say that five times fast) less important.

@kronosapiens
Copy link
Member Author

This PR has been updated with the feature changes we've discussed and is ready for review. I would suggest not doing anything about external escalation until later on, once we've had a chance to discuss the functionality in some detail and think about the arguments, etc. Once I've gotten a rough approval for the PR as-is, I'll restore the original VotingReputation contract as we've discussed.

@kronosapiens kronosapiens force-pushed the feat/all-voting branch 6 times, most recently from 54e78d2 to 29d748a Compare October 27, 2021 10:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Token and hybrid voting
2 participants