Proposal: ALP04 Delegation Chains

Author(s): Luke Duncan

Last updated: Dec 5th 2017

Abstract

This proposal extends the functionality described in #3 to include delegation chains where Alice might delegate to Bob who might delegate to Carol. The purpose of allowing delegation chaining is to allow for bottom-up chains of trust.

Proposal

At a minimum a successful implementation would enable the following user stories.

• All user stories which are included in #3
• As a delegate, I want to be able to delegate my influence as well as the influence that has been delegated to me to another user.
• As a user, before I delegate I want to be able to know if the transaction will succeed prior to paying gas.

Rationale

Rather than a typical user having to make a decision between one of many expert delegates, they can simply delegate that choice to a friend who they have a high level of trust but who is more engaged in the project. This process helps mitigate issues where well know figures become super delegates simply because they have a high profile in the community. This also minimized the amount of effort and knowledge required of the average voter.

Open Issues

• To ensure a delegation is valid and does not create a loop, we have to process the delegation chain at the time of delegation. This means the cost to delegate may vary. We can limit the length of delegation chains in order to put a minimum and maximum on this cost.
• To minimize the cost to delegate, we can make the validation of chains happen client side, allowing users to make any delegation choice they want and do the tabulation and validation in batches at the end of a poll. To make tabulation less expensive, it may make sense to move this process “off-chain” with a solution like Truebit. This approach is discussed in #5 .

Proposal: Proxy/Delegate Voting

Author(s): Luke Duncan

Last updated: 11/29/2017

Abstract

Proxy or Delegate based voting allows voters to opt to participate actively or delegate their voting power to another party. This process can be applied to any voting mechanism including carbon vote signaling mechanism as well as those requiring tabulation.

Proposal

At a minimum a successful implementation of this proposal would enable the following user stories:

• As a voter, I want to be able to delegate my vote for a period of time which spans multiple votes
• As a voter, I want to be able to review completed and active polls, and see how my delegate voted
• As a voter, I want the option to override my delegate for a given active poll.
• As a voter, I want the option to change my delegate at any time, for any active and future polls.
• As a delegate, I do not want the actions of other voters including the action of delegating their vote to me, to impact the transaction cost of me placing my vote.

Rationale

Direct voting does not scale particularly well for large groups. This is because users with limited influence on a decision have a negative individual expected value of being informed and actively participating on all issues. The result is low participation and/or negligent, uninformed voting.

By allowing delegation users have the option to participate if they feel strongly about a particular issue, but can still have their voice represented even if they do not pay full attention to all issues.

Delegation is (in theory) better than representation, because delegation can be overridden or revoked at any time, so delegates have more incentive to represent the interests of their constituents than elected representatives.

References

Delegative Democracy is a good primer on delegate voting.

Open Issues

• Delegation Expiration : If users show a tendency to delegate and forget about it, there is a risk of accumulation of influence in “super delegates” which could be worse than representative systems which have term limits. We could consider adding a delegate expiration at some reasonable timeframe, to force voters to re-assess their delegation choices on a somewhat frequent basis.
• Tabulation Scalability : Depending on the implementation delegation may have an impact on the computation required to tabulate votes, particularly in large networks with many participants this may not be an insignificant amount. Until tabulation can be securely and efficiently moved off-chain, it may make sense to experiment with delegation approaches in carbon feedback style voting mechanism initially.

Proposal: Asset-based Confederations

Author(s): Alex Sherbuck [email protected]

Last updated: 2018/02/07

Abstract

Agree upon a scoring mechanism for non-fungible assets. Form a confederation where asset holdings represent each sovereigns' votes. Voting weight is determined by asset scores. Weight may be delegated to represent split control of an asset.

Using this property we may form organizations around our collective asset holdings. This is a means of distinguishing value between non-fungible assets, whose value differ by their nature.

Proposal

Upon forming an organization (Cryptokitties Collectors Club) we set rules relative to our interests. We assign point values based on the traits of our NFTs (rare genes = 10 points, common genes = 1 point). All NFTs are scored equally. NFTs determined to be of the highest value by the group are awarded the highest voting weight.

As the group makes decisions they may use their NFT weight to vote to come to consensus.

Split voting weight can be used to determine internal decisions for joint ownership (Renting space in a building). In the case of an asset that is co-owned or leased among multiple parties control of voting weight may be split according to ownership percentage.

A DAO may form around a single asset split between many owners.

Rationale

ERC-20 Voting is effective to represent shares or investment in an organization. ERC-721 voting can represent interests that move beyond financial stake. Asset voting weight gives rise to governing bodies around any asset holding.

All vote weight may be renting or sold, but the asset owner still retains the property rights of the asset by holding the NFT.

Implementation & Example

Weighted Digital Asset Registry - w/ DAO voting

EIP

Changelog

March 1 - Cleaned up explanation and examples

Proposal: ALP06 Decision Domain Delegation

Author(s): Luke Duncan

Last updated: 12/5/2017

Abstract

In many organizations there are multiple decision domains and users may want to delegate their influence on decisions with a specific domain separately. This proposal suggests assigning proposals to a specific decision domain, and allowing users to choose to delegate relative to specific decisions domains.

Proposal

At a minimum a successful implementation would enable the following user stories.

• As an organization, I want to group proposals into decision domains
• As an organization, I want to limit the authority of proposals that are included in a decision domain (eg, proposals in Domain A are limited to moving at most X funds per month)
• As a voter, I want to be able to assign different delegates depending on the decision domain of an issue.

Rationale

Decisions should be made by people who are trusted experts in a specific domain. This is allows for specialization and associated efficiency improvements.

By organizing the decisions to be made, along with limiting the impact a specific decision can have when sourced from a domain, we allow for complex organizational decisions structures, while mitigating the damage that can be caused by decisions in specific domains.

This could enable domains which have budget authority for day-to-day operations, but which cannot make significant decisions without appealing to a different decision domain.

References

This proposal is heavily dependent on delegate voting. It should be considered in close relationship with other delegative voting proposals.

• #3 ALP03 Proxy/Delegate Voting
• #4 ALP04 Delegation Chains

Open Issues

• Should decision domains be organized into a hierarchy?
  • Doing so would ensure that the average user would not need to make a specific delegation decision at each level, but instead could delegate at the top level only, and their influence in sub-domains would flow through delegation chains.

Proposal: Token-weighted Github Issue Prioritization

Author(s): Luke Duncan

Last updated: 11/29/2017

Abstract

A significant factor in governance is the visibility and discussion of issues prior to any formal decisions are made. In token based communities, tying the curation of issues to a token weighted mechanism enables projects to highlight the issues that the community collectively feels are most important. This can be a catalyst for community engagement and discussion.

Proposal

At a minimum a successful implementation of this proposal would enable the following user stories:

• As an admin, I’d like to be able to have new issues automatically appear in the dApp without manual intervention.
• As an admin, I’d like to be able to manage which issues appear in the dApp based on “labels”.
• As a token holder, I do not want to lock my tokens
• As a token holder, I want to keep my tokens on a hardware wallet
• As a token holder, I want to be able to signal for multiple issues simultaneously

Rationale

Pros

• Users can only use their tokens to signal for one one issue at at time, therefore they must make an economic choice in which issues they signal for. The result is a prioritized list based on token holder feedback.
• Signaling is stake-weighted, so we can assume that the priority should to some degree align with the interests of token holders.
• Token-holder and Developer attention can be focused on the discussion and implementation of issues which the community has deemed most valuable.

Cons

• Token-holders are not necessarily the same group as the networks users, and in particular “whales” have a huge influence in this process.

References

A similar approach has been taken by district0x with their district proposal process. Their implementation has been live for quite some time now, and it appears it has been a large part of their community engagement. The code is also available in the District Voting repo.

Open Issues

There is a lot of overlap with ALP01, in that both can use a carbon vote inspired signaling mechanism. It may make sense for these issues to be combined into a single interface.

Proposal: ALP05 Off-Chain tabulation

Author(s): Luke Duncan

Last updated: 12/5/2017

Abstract

In order for a vote to be used to execute an action such as calling an arbitrary function, the result of the vote must be tabulated. Doing this tabulation can be expensive. Votes can be tabulated when cast, distributing the cost across all voters, or votes can be tabulated in batches at the end of a poll. Tabulation at the end lends itself well to off-chain scalability solutions, in particular interactive verification solutions like Truebit seem like promising approaches that could reduce voting cost significantly.

Proposal

At a minimum a successful implementation would enable the following user stories.

• As a voter I want the cost to vote or delegate to be consistent and minimal.
• As a participant I want to be able to securely tabulate the results of a poll.

Rationale

Carbon-vote style applications are relatively simple, and the cost to participate is low. They can include both direct voting and delegation, including complex delegation chains. By moving the logic for validation and tabulation off-chain we minimize the amount of calculation that happens on the main chain which may present significant cost savings.

It is unclear how expensive computation will be on the main chain in the future as things like proof-of-stake and sharding come online, but it is almost certain that it will be more expensive than computation that are done in second-layer solutions.

References

• Currently it looks like truebit is the most promising solution for general verifiable off-chain computation.

Open Issues

• The party that calls the tabulation function will need to pay for the process of tabulation, which despite being cheaper overall, would be more expensive than individual voters paying. Some mechanism that would allow an anonymous transaction under specific circumstances to trigger the vote and have the organization fund tabulation would be necessary.
• This may not be a huge issue in the short-term assuming gas prices for voting applications remain manageable, but it would be useful to explore the potential cost differential between approaches.

Proposal: Carbon Feedback for Github Issues

Author(s): Luke Duncan, Aragon et. al.

Last updated: 11/29/2017

Abstract

Many community governed projects are open source and use Github for project planning and discussion. However, it can be difficult to judge community consensus related to open issues. This proposal suggests using a Carbon Vote inspired mechanism to give a communities token holders the ability to signal their support of an issue.

Proposal

At a minimum a successful implementation of this proposal would enable the following user stories:

• As a repo admin, I'd like to be able to enable token-weighted signaling in support of issues
• As a repo admin, I'd like to be able to configure multiple voting options for an individual issue (e.g. approve option X, approve option Y, disapprove)
• As a token holder, I do not want to lock my tokens
• As a token holder, I want to keep my tokens on a hardware wallet
• As a token holder, I want to be able to signal for multiple issues simultaneously

Rationale

Pros

• This is a safe and inexpensive mechanism for getting community feedback, and provides immediate utility for token holders. There are no tabulation costs for votes, and security risks are minimized because tokens never leave the users wallets.

Cons

• Lack of on-chain tabulation means that this cannot be used to give fully decentralized authority to token holders.

References

Aragon Signaling App - An initial version of this proposal has already be developed by Aragon for use by ANT holders to participate in governance decisions. It may need some UX improvements to be ready for general use by other organizations.

Proposal: ALP07 Futarchy

Author(s): Luke Duncan

Last updated: 12/8/2017

Abstract

We agree on a quantifiable metric that determine how effective certain policies are, then we rely on prediction markets to determine which policy is likely to result in a higher metric at some point in the future. By putting the decision making in the hands of a market, we create a profit incentive for only those with the greatest knowledge and expertise about the decision to participate.

Proposal

Globally we define the prediction market implementation we want to use (augur, gnosis, etc). This will be used for all decisions.

For any given decision we specify a metric, an oracle to settle the market, a decision time, and a settlement time.

For each decision we create one prediction market for each alternative choice, e.g (accept proposal, reject proposal). Prediction markets have the property that the market price reflects expected value of of the chosen metric at settlement time, therefore, if we want to maximize our chosen metric we should pick the policy that corresponds to the prediction market where the price is the highest.

When we do, since there is no way to settle the market that didn’t win we revert all trades within the losing market.

At settlement time the chosen oracle feed is used to fetch the metric which is used to settle the winning market. Participants holding tokens of the correct value are paid with funds collected by those who hold the incorrect value.

At a minimum a successful implementation would enable the following user stories.

• As an organization, I want to be able to deploy multiple prediction markets based on a decision.
• As an organization, I want to be able propose a decision and specify the metric, oracle feed, decision time, and settlement time.
• As a market participant, I want to be able to send a call to settle the market after settlement time.

Rationale

Decisions can be nuances and complex and require expertise to really understand what impact they may have, most voters do not have the expertise to carefully consider each outcome of each decision, nor do would it be rational or efficient for them to try. Rather than force them to make choices on topics they do not understand, futarchy enables the community to decide on the metric or goal, and relies on efficient markets to decide which approach to reaching that goal is better.

By moving the decision process to a market the hope is that competition and profit-seeking behavior will attract individuals with the most expertise and information about a decision and its likely outcomes to participate, and reduces noise from those who have a limited understanding of the likely outcomes of a decision.

References

Daos, Democracy and Governance - Ralph Merkle
An introduction to futarchy - Vitalik Buterin
Gnosis Futarchy Cryptoeconomics

Open Issues

• Should voters be given the ability to veto a market decision and revert trades?
• Are current prediction market implementations and oracle feeds sufficiently mature to support experimental futarchy implementations?