Home

Ethereum Governance Phase 1

Target Proof-of-Concept Date: 2016/07/02
Target Deployment Date: 2016/07/09

Summary: Phase 1 Will enable the submission of propositions which can then be efficiently explored and signaled upon. Signals can be negative or positive. Ethereum account holders will be able to create signaling accounts which can then hold positions against propositions creating a signal level proportional to the account balance. Anyone can then browse the current state of propositions and their respective signal levels over time. Ethereum users who have associated an account with the Signal contract will be able to see a short-list of just the propositions they are tracking and/or holding an active position in or browse the entire active list sorted by date or magnitude of signal (positive signal + |negative signal|).

Contracts

Contract: Proposition

Data Model

• Propositions
  • string title : short summary of the proposition
  • string text : complete proposition text
  • bool active : true if proposition is still active
  • address proposer : ethereum address used to submit the proposition
  • uint256 deposit : qty. of ether deposited

Actions

• submitProposition(title, text, deposit)
• deactivateProposition(propId)
• getNumPropositions()
• getProposition(propId)
• TODO have way to transfer deposits

Events

• PropositionSubmitted(proposer, title, text, deposit)
• PropositionDeactivated(propId)

Upgrade Path

• A new version of the proposition contract will upon instantiation, in its constructor, call this version of the proposition contract in order to migrate all necessary data in an auditable way.

Contract: Signal

Data Model

• mapping account -> deposit

Actions

• openSignalAccount(sigAcct, deposit)
• closeSignalAccount(sigAcct) // deposit is returned
• setPosition(sigAcct, propId, weight)

Events

• SignalAccountOpened(sigAcct, deposit)
• SignalAccountClosed(sigAcct)
• SignalAccountSetPosition(sigAcct, propId, weight)

Browser Context

State

The first time a browser visits the site, it will construct the current state of all propositions and signals via interfacing with an ethereum node instance. Once the initial state is reproduced updates will be received via events. The browser local state data model used by the User Interface will be a JOIN of the data made available by the events generated by the Propositions contract and the Signal contract as defined below (in the Data Model subsection). Note the negative and positive signal histograms are tracked separately rather than interfering with each other. Otherwise equal positive and negative sentiment would look like no interest.

Data Model

• Propositions
  • string title : short summary of the proposition
  • string text : complete proposition text
  • address proposer : ethereum address used to submit the proposition
  • uint256 deposit : qty. of ether deposited
  • Dictionary acct, weight
  • uint256 negSignal[Nintervals] // histogram
  • uint256 posSignal[Nintervals] // histogram

User Interface

• WIRE FRAMES GO HERE

User Interfaces

• Submit a proposal
• List proposals (can sort by age of proposal and/or show only proposals where (you have an active position or are tracking))
  • Show voting stats (signal) and meta-data (age of proposal)
  • Add a position
  • Withdraw a position
  • Update position (withdraw then add)

Issues

Notes

• The browser local data model histograms should be deterministic, that is every browser should produce the exact same histograms. This means that the account balance and weight values will be scraped from the blockchain appropriately from events and balances using the blocks time stamps.