## Decisions for the Voting Mechanism PoC

### Made discretionarily by BlockScience

Those decisions were made for the sake of completeness and with minimal consultation. They're based on our best judgment as per expressed requirements and discussions. As an rule of thumb, we'll bias for a decision that is simpler rather than complex (Occam's Razor)

- After all Votes are cast, the Voting Power applied to a project is summed up and evaluated based on whether it is positive, 0 or negative. **A positive cumulative Voting Power results in a signal for "Yes"** (this project should receive funding), 0 means the community is split and can not render a decision, a negative result means "No" (this project should not receive funding)
- This could be changed later to require a certain threshold of Voting Power to be required for a succesful decision. Alternatively, more complex decision making could later be applied by e.g. requiring a positive cumulative Voting Power evaluated based on a function of the amount of participating (or potential) Voters.
- For the PoC, **we require a minimum of 2 Voters** to vote on a project for a "Yes" decision to be rendered, else "No" is to be rendered. The number "2" was chosen primarily to exclude decisions to be made by single voters and should be iterated on later.
- For both the Reputation Neuron as well as the Prior Voting Neuron decisions were made to scale Voting Power.
- Reputation Neuron: To show similarity to Stellar Organizational Tiers, Users can fall into Tier 1 (`0.1 Voting Power`), Tier 2 (`0.2 VP`) or Tier 3 (`0.3 VP`) respectively depending on the badges they collected. This is just an initial configuration and should be discussed further.
- Prior Voting Neuron: To reflect earlier discussions having participated in several prior rounds adds additional voting power. For the PoC Spec, a User can have participated in three prior rounds, with values set to: r(1): `0.0`,r(2): `0.1`, r(3): `0.2`, r(4): `0.3`. This means, that a User participating on multiple rounds has his Voting Power added up for all those respective rounds. This decision needs to be iterated on.
- We assume that Floating Numbers is an admissible data type for the implementation.
- All Neural Governance Modules are active with no user option to disable it.
- This could be changed later to allow Users to decide themselves which data they want to use for additional Voting Power.
- A User Quorum should be composed of Distinct Users. No Duplicates are allowed.
- This could be changed later to accomodate contextual overweighting of voices in the Quorum.
- If a User Quorum size is less than 5 (after filling up from the larger set of the potential Users to be included in the Quorum), then any missing slot is replaced by Absent votes.
- The Aggregation over Neurons will be Additive.
- The Raw Trust Bonus will be defined as the Canonical Page Rank over the Trust Graph with Damping Factor of 85%. The values will be normalized through MinMax to `[0, 1]`, and re-scaled to `[0, 1]`, and this will be the Actual Trust Bonus.
- This means that the top individual in terms of Trust Importance will have its voting power boosted by 100%.
- The decision on using the Canonical Page Rank was made jointly and using Iterative Simplicity as an criteria. This should be studied and changed over time.

### Questions raised and decided in discussion with SDF

Those decisions were determined through discussion with SDF. All decisions should be understood as applicable specifically to the PoC and can be overriden on future iterations as more insights come into play into the future.

- Q1: Is Quorum Consensus determined through Vote Consensus or Voting Power Consensus?
- **Decision**: Vote Consensus. Instead of requiring Users to keep up with changes in Voting Power, a decision was made to decide Quorum internal consensus based on "1 member 1 vote". This prevents single Quorum members from dominating Quorum decisions based on outsized Voting Power potentially unknown to the User delegating to the Quorum and reduces complexity in computing Quorum consensus.
- Q2: Should Quorum Consensus be based on Absolute Agreement or Relative Agreement? Or both?
- **Decision**: Minimum Threshold of Active Voters (67%) followed by Relative Agreement (Simple Majority). The minimum threshold prevents Quorum from rendering decisions with only minimal active voters.
- Active Voter for an Given Project: Someone that actively chose an non-abstaining Vote Action (eg. Yes or No)
- In the absence of Consensus, the delegated decision is to be Absent.
- Q3: What happens if there’s no Quorum Consensus on voting “yes”? Should it render an “absent” position or an “no” position?
- **Decision**: Consensus being Yes/No gives Yes/No decisions. Else, Abstain. This decision was made to accurately represent the notion of Yes and No decisions being decisively different from abstaining, accurately representing the decision of the Quorum.
- Q4: How should the Quorum Voting Neuron resolve circular delegation?
- **Decision**: People will indicate before the round whatever they'll Vote or Delegate. Users can choose more than 5 people for the quorum but only the top 5 that are non-delegating will be considered. This "softly" circumvents by reducing the risk of a User choosing other Users for their Quorum who all (or too many for the threshold) delegate themselves. Note that this only reduces the risk, but does not entirely resolve it. The remaining risk is considered to be acceptable for the PoC, leaving a notion of accountability of Users to choose their Quorum in a way that allows for succseful votes to be rendered.
- Q5: Is it admissible or desirable to modify someone’s Bonus solely by the action of trusting another?
- **Decision**: Undesirable for PoC but non-blocking for future iterations. Made for reasons of simplicity and lacking requirements for more complex trust relations.
- Q6: How strongly should the Bonus be transmitted on successive trust relationships?
- **Decision**: Undesirable for PoC but non-blocking for future iterations. Made for reasons of simplicity and lacking requirements for more complex trust relations.
- Q7: Should the Bonus be back-propagated?
- **Decision**: Undesirable for PoC but non-blocking for future iterations. Made for reasons of simplicity and lacking requirements for more complex trust relations.
- Q8: Should the Bonus be capped or diluted?
- **Decision**: For the PoC, no hard capping or dilution will be used. However, a soft cap of a maximum score for the Neuron is used. This allows for newer users to more quickly have their acquired trust status represented in Voting Power, but can be iterated in the future to address potential scenarios of individual users dominating the trust scores or sustaining trust without active participation.

### Other Decisions

**Voting Power Delegation Function**
- Is a voter's voting power enhanced (some aggregate of delegatees' voting power) or simply applied?
- **Decision**: Applied. For simplicity reasons we decided against more complex applications of Voting Power delegated as a function of the delegatees Voting Power.

**Anonymity:**
- One desirable raised for the Voting Mechanism is the possibility of anonymous voting. For the PoC, limited anonymity was chosen due to several considerations.
- Discussions raised another desirable of "Accountability" for Voting Decisions made by community members. Especially for Delegation Mechanisms, Accountability plays an important part in allowing Users to make sustainable Delegation decisions. Additionally, using prior Voting Decisions (and their outcomes) as a factor in future Voting Power was considered as a potential Neuron for future Decisions (rather than just the "act of voting participation"). While there are ways to cryptographically conceal decisions while using them as inputs for computation on Voting Power, those were determined to be out of scope for the purpose of this PoC.
- One main consideration for anonymity was the need for User protection of vote bribery and coercion. Additionally, the Voting Process was determined to potentially need anonymity ("Voting Tally Anonymity") to protect against voting process attacks. These considerations are taken into account, but are not implemented in the PoC yet until further discussions were held on the extent of anonymity needed and desired by the community.
- A specific consideration for anonymity relates to the Quorum Delegation. It is currently considered preferable for Delegates not to know the extent of Voting Power delegated to them, leading to the design choice of client side automation for Vote Delegation - a User specifies the Users making up their Quorum, allowing them to "automatically" vote with their choice, rather than explicitly delegating on-chain Voting Power to the Quorum. At the same time, Users specify whether they will vote or delegate, circumventing softly some concerns around circularity in vote delegation.