Decision

See #33 (comment) and #33 (comment).

Goals

To what degree do we want to support old Rinkeby users when we release contracts built on aragonOS 4 alongside the mainnet release? How much effort should we spend providing a smooth migration path?

Description

aragonOS 4 introduces a number of breaking changes from aragonOS 3. We'll be deploying these new, backwards-incompatible contracts on both Rinkeby and Mainnet together.

At the moment, most features should just work, but there are a few breaking changes:

• Old users won't be able to upgrade to new versions of any contracts (either internal to aragonOS, like the Kernel or ACL, or any Apps), without there being huge data problems.
• Potentially ACL write functionality may not work
  (aragon/aragonOS#223)
• Old users won't have access to the recovery vault functionality
• Some functionality not currently exposed in the UI

As well, we are thinking of deploying completely new versions of APM, which would also increase the burden of supporting old DAOs.

Given the difficulty migrating, there's also the question of whether we should start a new root ENS registry for the new DAOs or continue reusing the old one?

Potential paths

1. Warn the user if we detect they have a DAO older than X date, and suggest them to spin up a new DAO
2. Maintain an "old" version of Aragon Core for those users to use (e.g. old-app.aragon.org)
3. Ignore old DAOs, silently (or more explosively) fail if they try to access functionality

[Please suggest more :)]

Goals

• Replace most part of the Aragon HQ meeting with publicly-accessible slides
• Leave all discussion related to the Aragon HQ meeting to the Community meeting, in order to unify them and reduce the time we spend on calls and "office" bureaucracy

Description

You can learn more about our governance model at the wiki. The tl;dr about the HQ meeting is as follows:

Discussion about the state of Aragon, near future plans and decisions that need to be made. 10 min presentations with slides from team members, in which each one will run through the most important things we have done during the month

Since we're mostly running through slides, it makes sense for all team members to just work on them and publish them online. We can publish them on Mon, and then leave the whole week for the community to review it and prepare questions for the Community meeting on Fri.

Every team member should look at each other's slides and prepare for the call, asking any questions that may have emerged. The community should do the same.

This way, we both save time in meetings, while being even more accountable, since accessing slides would be easier for the community than watching a very long call.

We intend to use this issue along with ANT signals from the survey app to gauge community sentiment.

We would like to understand if the Aragon Manifesto as presented by the Aragon One Team aligns well with the Aragon community. Please use this issue for discussion and the Survey app to signal support, you can split your vote between yes or no to express mixed sentiment.

Goals

Avoid "political deadlock" situations caused by unmet quorum.

• Allow survival and normal functioning of organizations with (unexpectedly) passive majority
• Protect organization founders from severe consequences of suboptimal choice of quorum numbers (both too high and too low)

Description

Exponential backoff is an algorithm that uses feedback to multiplicatively decrease the rate of some process, in order to gradually find an acceptable rate.

In case of governance we may use "multiplicative decrease" of quorum number.

As vitalik buterin highlights in his post, Low Voter Participation is a real thing in cryptocommunity. It may be reasonable to assume that Voter Participation may vary significantly between organizations, or during different phases of organization's existence.

If quorum number is a moving target, then choosing reasonable value would require manual adjustments, and expertise (mistakes), and political will (moral hazard threat - one may be blamed for attempt to adjust such fundamental things as quorum numbers).

Speaking of quorum number it is easy to imagine situations where quorum number is too big, leading to political paralysis, or too small, leading to disastrous decisions. Dynamic quorum may be adequate answer to those challenges.

Uncertainties

Even if exponential backoff quorum discovery is a good idea, the question is - where should it be applied? First answer that comes to mind is - "critical" aspects of organization politics. Where critical means "existential threat/importance" and "time sensitive".
Time sensitivity is another complex aspect of the problem, as "frequency" of "backoff" should be defined.

Goals

This AGP's goal is to support a possible changelog strategy for Aragon projects by using automated tooling that relies on commit message conventions.

Therefore:

• finding consensus on using commit message conventions across Aragon projects
• ideally decision making for a convention

are needed.

Description

In order to implement aragon/aragonOS#180 Aragon projects could rely on tooling to automatically generate changelogs from the project commit histories. There are basically two parts to make this work:

1. Commit Message Convention
   A convention or format of the commit message that can be parsed and then output in another arbitrary format that can be consumed as changelogs.
2. Tooling
   A tool that knows how to read commits from a Git repository, parse the commits and creates a dedicated output that could essentially be a changelog.

Tools for this strategy do already exist and are battle-tested in real-world project for many years. The Angular projects for example introduced semantic commits + conventions in order to generate changelogs, for the first time in the JavaScript space. Another example can be seen here in the MachineLabs project, which happens to be a mono repository with multiple sub packages. The linked file gives an idea of what a changelog could look like.

Automated changelogs introduce some nice properties as well:

• More awareness in the importance of "good" commit messages (contributors will send pull requests with well-defined commit messages)
• Commit(s) (histories) are easier to read, follow and work with
• Almost no manual maintenance needed
• Generated changelogs include information and links about which commits relate to which features/bugfixes/breaking changes etc.

Commit Message Convention

As the changelog generation is based on a repository's commit, it's crucial that a repository's commits are all well formatted an follow a particular convention to make the system work. There are no restrictions in what the conventions look like as long as they can be parsed to extract the needed information.

The standard convention is the one that is most widely used and probably the best one to go with as there's no additional work needed to make the tooling learn a custom convention.

The convention is pretty straight forward. Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

The header is mandatory and the scope of the header is optional.
The footer should contain a closing reference to an issue if any.

Example:

docs(changelog): update changelog to beta.5

fix(release): need to depend on latest rxjs

Some message that gives more details about the change.

Type

Types can differ from project to project as needed, but generally every project could make use of the following types:

• docs: Documentation only changes
• feat: A new feature
• fix: A bug fix
• refactor: A code change that neither fixes a bug nor adds a feature
• test: Adding missing tests or correcting existing tests
• chore: For changes that are neither fixes, features, refactors etc. and unlikely to be noticed by the consumer of APIs

Other types might be perf, styles, build, ci etc. For more custom types, take a look at MachineLabs guidelines.

Scope

Scope really depends on the project as well. In a mono repository, it could be the name of the npm package affected (as perceived by the person reading the changelog generated from commit messages. For inspiration, again, take a look at the linked MachineLabs guidelines.

Footer

The footer is a great place to put comments about which issues are being fixed or closed by the commit. Another information that should go in there are breaking changes, in case the commit in question introduces any. Those can be nicely documented with before and after blocks.

Those breaking changes will show up nicely in the generated changelog as well, making it very easy for developers and consumers of Aragon's API to follow what needs to be done to upgrade their code base.

Privacy is important, more important to others especially on a public blockchain. How quickly should be prioritize adding privacy features to Aragon products such as Aragon Core and aragonOS?

• Short-term
• Medium-term
• Long-term
• I don't care about privacy

Do you like RocketChat as a chat platform for the Aragon community?

• Yes
• It's okay
• No

AGP: 19
Title: Documenting Aragon repository governance
Author: John Light
Status: Draft
Created: 2018-06-18

Description

Each repository under the Aragon organization on GitHub (github.com/aragon) should have a GOVERNANCE.md file that documents the governance status and process of the repo. Information in this file should:

• Make clear who is the maintainer and who has commit access to the repository
• Document how and when current and past maintainers and those with push access gained their privileges
• Document how maintainer and push roles can be changed (or if they can’t be, state as much)
• This information is lightly documented in the wiki (see “Owned by” labels in http://wiki.aragon.one/dev/) but I think this could be formalized a bit to make it clearer.

Example

The GOVERNANCE.md file in a repo might look something like this:

Current maintainers

Alice (github.com/alice)

Current push access

• Alice (github.com/alice)
• Bob (github.com/bob)
• Carol (github.com/carol)

Changelog (from most recent)

• 2018-06-03 Alice (github.com/alice) gave push access to Carol (github.com/carol)
• 2018-05-01 Alice (github.com/alice) removed push access from Sarah (github.com/sarah)
• 2018-04-01 Alice (github.com/alice) removed push access from Eve (github.com/eve)
• 2018-04-01 Eve (github.com/eve) gave maintainer role to Alice (github.com/alice)
• 2018-03-01 Eve (github.com/eve) gave push access to Alice (github.com/alice)
• 2018-02-01 Eve (github.com/eve) gave push access to Bob (github.com/bob)
• 2018-01-01 Eve (github.com/eve) created repo on behalf of Aragon Foundation

Governance rules

• Maintainers of the repo are first appointed by the Aragon Foundation.
• Maintainers can appoint new maintainers and assign or revoke push access to the repo.
• The Aragon Foundation can override any decisions made by the maintainers.
• Forks of this repo are governed by the LICENSE.md file in this repo and whatever additional governance process is put in place by the maintainer of the forked repo.

CODEOWNERS (Optional, only if there is a CODEOWNERS file in the repo)

You can find the code owners for this repo in the CODEOWNERS.md file in this repo.

Create a CONTRIBUTING.md file and contributor guidelines for this repo.

• Lets people know how to contribute.
• Lets people know what contributions will likely be accepted (which is separate from what contributions will ultimately be approved by the community) i.e. what qualifies as an appropriate issue for an AGP?

This proposals is intended to discuss and gauge sentiment of the community on how to prioritize between 3 short term features for Aragon Core.

Identity App

Currently users are identified by public addresses which does not provide an ideal user experience, the Identity app would enable users create a profiles and associated with their public key. Other apps would then be able to reference profile data rather instead of public addresses when identifying entities within an organization.

Permissions App

Currently manipulating and changing permissions within an org cannot be done within the front-end. The permissions app would enable standard types of permissions to be added and re-assigned to entities using the ACL.

App Manager

Currently there is no way to install new application or instances of existing applications from the organizations front-end. The app manager would enable this functionality, and when combined with the permissions app all organizations to create complex organizational structures within the user interface.

Goals

• Migrate the community from Slack to Rocket.Chat or Riot
• Create a Rocket.Chat client app in collaboration with other Ethereum projects with a project selector if Rocket.Chat is the chosen platform

Description

As Slack was designed for internal use of projects, the tools to run public facing communities are lacking in features that these projects would benefit from having. Migration to a open source project, Rocket.Chat or Riot, will help us manage and govern our communities more efficiently.

Our idea is to fork of the Rocket.Chat Electron app and together in collaboration with other interested projects create a new app for the Ethereum community to have a project selector similar to Slack. The selector could be pre-filled with a list of Ethereum community projects for ease of use. This would help community members by only having one app for the projects that choose to use Rocket.Chat instead of other alternative chat apps and thus bringing the community closer to each other by using a shared tool that can be updated by anyone via Pull Requests to the community driven repository. Projects using this could also pool resources together and support the development of Rocket.Chat, as well as making it more usable.

Initially we would like to hear from other projects in the space to see how much interest there is in such a tool and migration process. Setting up Rocket.Chat requires projects to set up their infrastructure for the service, more information can be found in the Rocket.Chat Documentation and there's an Import tool that can easily migrate your users and channels to Rocket.Chat (but not DM's and private channels).

Riot does not require such efforts as Rocket.Chat, but has the option to run your own infrastructure.

Uncertainties

• Are other projects interested in such an effort We now have support from 5 projects
• How will our community members react to the migration from Slack to Rocket.Chat The Aragon community has been positive about possible migration to another platform

Situation update

I have now created and updated the documents so projects can evaluate the features and possibilities provided by the two open source projects, Rocket Chat and Riot.

Read about RocketChat.

Read about Riot.

If you have anything you want to add or change in the files, please do so via a Pull Request.

Projects supporting this migration

• Aragon: 6k members
• Decentraland: 3.5k members
• Cofound.it: 5k members
• 0xproject: 4.3k members
• Indorse: 3.3k members
• Auctus Project: 1.3k members
• TenX: 12k members
• FOAM: New, some members
• Colony: 4.4k members
• Santiment: 3k members
• Auctus Project: 1.3k members
• OmiseGO: 10.9k members
• Golem: 9.9k members
• Streamr: 1.5k members

Goals

• Create a ranking/rating system that tracks a voters accuracy
• A ranking/rating system that can also act as a reputation system

Description

Since the governance is based a lot on Game Theory in many aspects, why not use a ranking/rating system that has been created for games.

I would suggest Glicko-2 as a viable option for a ranking/rating system that can keep track of how well voters perform and that value can act as a kind of a reputation system. The reputation could then also be used for validating the Judges for ANJ Supreme Court, or even have the 5 random Judges on Decentralized Court have a higher change of getting picked by weighting the odds a little by the reputation system.

Glicko-2 could be implemented for all Yes/No votings at least.

The Glicko rating system and Glicko-2 rating system are methods for assessing a player's strength in games of skill, such as chess and go. It was invented by Mark Glickman as an improvement of the Elo rating system, and initially intended for the primary use as a chess rating system. Glickman's principal contribution to measurement is "ratings reliability", called RD, for ratings deviation.

The RD measures the accuracy of a player's rating, with one RD being equal to one standard deviation. For example, a player with a rating of 1500 and an RD of 50 has a real strength between 1400 and 1600 (two standard deviations from 1500) with 95% confidence. Twice the RD is added and subtracted from their rating to calculate this range. After a game, the amount the rating changes depends on the RD: the change is smaller when the player's RD is low (since their rating is already considered accurate), and also when their opponent's RD is high (since the opponent's true rating is not well known, so little information is being gained). The RD itself decreases after playing a game, but it will increase slowly over time of inactivity.

The Glicko-2 rating system improves upon the Glicko rating system and further introduces the rating volatility σ.

Further reading about Glicko-2:
Example of the Glicko-2 system -paper with formulas: http://glicko.net/glicko/glicko2.pdf
Glicko rating system on Wikipedia: https://en.wikipedia.org/wiki/Glicko_rating_system
Glicko-2 Javascript implementation: https://github.com/mmai/glicko2js

Uncertainties

This was a thought and an idea of what might work, i haven't had time to really get into thinking how this would actually work, so further research and feedback on the matter from others too would be appreciated.

How much capital should Aragon spend yearly on Nest grants?

• None
• 1% of reserves
• 2.5% of reserves
• 5% of reserves
• 10% of reserves

Title: Formalize ANT Holder Veto for Foundation Funding Proposals
Author: Luke Duncan and Luis Cuende
Status: Draft
Created: 2018-08-19

Goals

• Start transitioning Aragon’s governance from a highly centralized model to a more decentralized one
• Experiment with community participation while still ensuring the safety of the project
• Document and formalize this new process so governance stakeholders can be kept accountable

Description

This AGP is related to a discussion on the research forum about possible practical first steps towards decentralizing the projects governance. At a high level this AGP would require the Aragon Association (formerly called the Foundation) to make proposals to ANT holders in order to allocate funds and assign executive responsibilities.

This process can be accomplished by deploying an Aragon DAO with the following Applications and Permissions:

• Voting App (ANT Veto): An instance of the Voting app would be deployed using ANT as the voting token. Support Required: >50%, and Minimum Quorum is set to 1%.
• Voting App (Proposals): An instance of the Voting app would be deployed along with 3 non-transferrable tokens. One token would be assigned the instances of Voting app used for ANT Vetos (above), one would be assigned to the Foundation multi-sig, and one would be assigned to the Community Multi-sig. Support Required: >50%, and Minimum Quorum is set to 33%.
• Finance app and Vault : An instance of the Finance app and Vault is used to store funds, the only entity with permission to move funds is the Voting App (Proposals) described above.
• Survey App (ANT Surveys) : An instance of the Survey app would be deployed using ANT as the voting token. The Foundation multi-sig would be granted permission to make proposals.

The foundation would move funds from the Foundation multi-sig into the Aragon DAOs vault. At which point any further movement must go through the Voting app (Proposals). The specific configuration ensures that if ANT holders vote to veto the proposal it cannot go through, unless the community multi-sig overrides the veto.

For decisions which are not directly related to moving funds, or which require some legal action on behalf of the Association the Survey app can be used.

This process would be too cumbersome for most regular administrative tasks, so the intention is for this process be used to approve lump sum operating budgets for organizational functions or approve delegation of responsibilities for organizational functions periodically.

The following are specific actions and how they would be carried out under the proposed process.

Nest grants

We can transform the Nest grants program into its own DAO.

The funding of that DAO would work as follows:

• Nest would have a yearly budget approved by the Association
• The Association would create the transaction to fund the Nest DAO
• ANT holders could veto it

And its governance:

• The Association would propose delegates who would run the program for a year
• ANT holders could veto the proposal

Funding Development

Thanks to the split between the Association and the development teams, the Association will perform a few monetary transactions per year, therefore making it possible for ANT holders to have direct veto power.

Examples:

• Giving out a sizable grant to an Aragon development team
• Sending money to the Nest grants program

Social media, Aragon Chat

• The Association would propose delegates to run the social media accounts and maintain the Aragon Chat for a year using the Survey App
• ANT holders could veto the proposal

Repositories

• The Association would propose delegates to maintain the repos using the Survey App
• Repos would be software repos but also include the multiple websites that are statically hosted
• ANT holders could veto the proposal

Once Pando is ready, this process could be converted to use the Voting app as a binding on-chain action.

Legal terms

Binding, with direct veto

• The Association would propose versions using the Survey App for
• The Trademark Policy, that lays out how to use the Aragon brand
• The Licensing Policy for significantly changing the licenses of the software or content
• ANT holders could veto the proposal, in which case they would remain unchanged

In order to make this binding, the Association would sign a legal agreement stating that it will adhere to the results of the votes for updating or not updating these legal docs.

Uncertainties

As with any token-based voting mechanism, there can be perverse incentives so holders want to veto proposals for their short-term benefit. I believe this is mitigated by making veto the first step, and not full control, therefore giving the Association the power to propose.

Also this should be seen as a transition state, one of the key funding proposals may be to move funds into experimental DAOs that have different governances processes and expectations for ANT holders.

The proposal has the ANT Veto app configured to require 51 percent support and 50% quorum, which based on participation rates in past surveys may need to be adjusted.

This proposals is intended to discuss and gauge sentiment of the community on how to set the default order/sorting of apps in the upcoming App center.

• Chronologically: Latest to oldest
• Alphabetically: From A to Z
• By installations: Most installations to least installations

Many things like app stores suffer from the issue that the most popular things become popular due to how content is shown to users. This can be manipulated to fill certain needs or to better serve those who wish to abuse it, thus we should get a signal from the community on how they would like to see sorting of apps done.

> MERIT

Goals

A system whereby members who themselves have a certain amount of trust (this may be negligible) may be allowed to give a subject (be it a survey or anything else) merit for relevancy, quality and/or personal feelings of a positive nature. On the other spectrum... in cases where members come across frivolous, unjust or by their standards (Item or case in question) of unacceptable quality may take an equal amount of merit away.

• Goal 1: To prevent information, in any form, from becoming exclusionary to the judiciary foundation of Aragon.
• Goal 2: Accountability. No one individual, shall need to posses any greater amount of influence than any other. This system has a goal to keep all members equally accountable no matter their role.
• Goal 3: Quality control. This system goes beyond individual merit to each and every aspect of Aragon. If I wish to buy something on "example1 com" I most often look at consumer ratings or the like. Why? Because I need to know what to expect. The goal of Merit is just that, preventing the unexpected.

Description

"The Merit System" As judiciary matters can be of a pressing and costly nature, merit itself must be earned in order to be given. Merit will be given from one's own personal merit "account", as well when merit is deemed necessary to be deleted, the one issuing the subtraction will need to have an appropriate "merit" balance. This is not only to ensure there will be no unjust or corrupt merit deletions, yet also because in order to subtract from another's merit, you will need to use your own as a "deposit" for a time to be set. This way if the other party feels the action was unjust they may appeal, and there will be "merit" for refunding if it is deemed to be so done. If either no injunction is filed, or the filer loses then the merit is returned. This system may have a wide range of applications for Aragon. This is an initial (and my first ever anywhere) offering which can be built upon, and I believe it will better Aragon.

Uncertainties

UPDATED
While I see no forseeable downside to having a system that allows everyone to vote on the merit of topics and what ever else Merit may apply to, I can always see the point where human nature and the vindictive nature of it come forth. That is why I set up the balance system, so merit is actually meaningful and not just an empty number. To give, you must really believe it is deserved, and to take, you will have undoubtedly a very good reason as it will not be a swift process. Everyone deserves a fair shot, and having a Merit system allows an equal playing field, with some fine tuning it could be a great addition. -Also Merit is not and will not be a currency, simply a point system.

This proposals is intended to discuss and gauge sentiment of the community on how to set the default order/sorting of the surveys.

• Chronologically: Latest to oldest
• Alphabetically: From A to Z
• By participation: Most votes to least votes so far

Many things like app stores suffer from the issue that the most popular things become popular due to how content is shown to users. This can be manipulated to fill certain needs or to better serve those who wish to abuse it, thus we should get a signal from the community on how they would like to see sorting of surveys done.

We intend to use this issue along with ANT signals from the survey app to gauge community sentiment.

We would like to hear from the community what types of grants we should be pursued by the Nest program.

We have bucketed the existing grants into the following categories:

• Aragon Apps
• Ethereum user experience
• Ethereum scalability
• Dev Tooling for Aragon and Ethereum ecosystems
• None of the above

Goals

• Incentivize educated and motivated voters.
• Separate holders only interested in speculating from holders that care for the vision of the AN, and have them make the decisions.
• Disincentivize big centralized exchanges (that hold tokens on behalf of the customers) from participating.

Description

AVT is a new token that gets minted by staking ANT in a exchanger contract. Exchanging ANT for AVT has no cost but there is a waiting period in which the holder doesn't have access to their ANT nor their AVT, so it has certain opportunity cost. Converting AVT back to ANT has also a certain waiting period (could be the same or different than the AVT creation period).

During the waiting period for exchange, a holder can expedite their order incurring in a fee in ANT (proportional to a f(x) = 1 / x type curve to the remaining exchange time) that would be split among current AVT holders.

Cancellation of exchange intent during waiting period should also be allowed, receiving their original tokens back (AVT or ANT), without being penalized (or just having half the expedite penalization?).

This creates an incentive for staking ANT and holding AVT, and makes people who are not speculating with ANT the decision makers for the Aragon Network.

AVT details

• AVT is non-transferrable.
• ANT and AVT have a 1:1 exchange rate. Expedited exchange penalization can make a holder to lose part of its stake.

Nice side-effects

• Legit non-speculative holders can earn ANT for just staking, taking ANT from speculators and distributing it among voters.
• Exchanges aren't incentivized to vote with its customers tokens as they need instant token liquidity in case of a withdraw. The 1/x type penalization makes it really expensive for someone that needs instant conversion.
• AVT exchange removes ANT from circulation.

Uncertainties

• AN could mint additional ANT (or AN could allocate some of its ANT holdings) to incentivize voting when total voting quorum is too low. Every marginal voter would make the reward less and less, so it could find a natural equilibrium.
• Should we incentivize actual voting besides just holding AVT. Should penalization rewards go only to holders who vote?
• Should a holder be forced to convert its full ANT balance to AVT? Could be gameable by separating into multiple addresses.
• Given the current implementation of ANT, vested token holders wouldn't be able to vote.

Figures

Penalization function

p(x, t) = x / (1 + (t * f / (w - t))

Arguments:

• x: Number of ANT or AVT being exchanged.
• t: Number of seconds since convertANT or convertAVT was called

Parameters:

• w: Total waiting time for exchange
• f: Slope factor, between 1 and infinity. 1 being a rect and bigger f results in more steep curve.

Credits to Joel Monegro for being part of the call where we came up with the idea

The Aragon Court mechanism is based on a crypto economic game where a set of judges is selected to review a dispute and return their subjective opinion on a case. The dispute is resolved in favor of the party which has the majority of support from judges. Judges in the majority are rewarded, and those which present outlier opinions are penalized. The system uses a commit-reveal voting mechanism and random judge selection to prevent coordination between judges.

This mechanism works well if we assume that the majority of judges will act honestly and that this mechanism successfully prevents coordination between judges. However, in reality smart-contract based bribes may have a significant impact on the behavior of judges.

P + epsilon Attack

The “P+Epsilon Attack” is a bribery mechanism that can be used to influence outcome of a vote, where voters who are in the majority are rewarded and voters in the minority are punished. The attack requires a high budget, but if successful does not the cost the attacker at all.

In this scenario an attacker makes a credible pre-commitment to bribe judges that is only paid out in the event that the preferred action is in the minority of judges.

The attack creates a prisoners dilemma situation where judges are incentivize to take the bribe because they expect other judges to do the same, even though collectively judges are better off acting honestly.

Thus, the system can be manipulated with a sufficiently large budget, but ultimately zero cost. This attack was described much more thoroughly by Vitalik on the Ethereum blog.

Payoffs for Attackers

• A: Bribe is successful (cost = 0 for attacker)
• B: Bribe is successful, but someone pays “A” to appeal (cost = 0 for attacker).
  • The attacker may choose to bribe again to try and influence the appeal, or stop.
• C: Bribe is unsuccessful (cost = P + epsilon for attacker)

How impact of bribes can be mitigated

Proving a judge has taken a bribe

If we can prove a judge has taken a bribe then we can punish them, decreasing their willingness to accept a bribe and forcing the attacker to make a larger pre-commitment in order to effective influence judge behavior.

Unfortunately, It is straightforward for someone to manipulate the outcome of a dispute using either a basic bribe or the P + Epsilon Attack without having to make contact with judges directly, they simple create an Ethereum contract and deposit funds, then have a function to release funds which can be called by anyone after the dispute is settled and automatically pays out to judges or returns money to the attacker depending on the outcome. This means that no action is required from a judge directly, making it impossible to prove that a judges vote was influenced by a bribe.

This makes it very difficult to punish judges, which means that high security deposits or a judge reputation mechanism probably won’t be particularly effective at mitigating impact of bribes.

Appeals Process

We can introduce a multi-tiered appeals process, so that if the result of a arbitration is questioned we retry with a larger number of judges, or require judges to have more stake/reputation to participate in the appeal.

This will increase the amount P+epsilon would need to be in order to effectively influence the dispute. This process can be repeated until there is no desire for an appeal, or increasing the required stake would reduce the number of judges eligible to participate bellow a certain threshold.

Areas for Improvement

1. It is difficult to punish dishonest judges. How can we make it more difficult for judges to accept bribes passively?
2. Appeals require a deposit from an honest party. That honest party is taking a risk, as they may lose their deposit if the case is not-overturned, and the attacker may double down on their bribe and successfully influence the appealed case as well. How can we make compromised disputes more likely to be appealed?

Proposal: Judges privately report if dispute has been compromised by bribery

Introduce a new mechanism that enables judges, in additional to voting on how to resolve the dispute, self report when they suspect that a bribe has compromised dispute, the more judges which report a bribe, the cheaper an appeal becomes, and if a majority of judges report a bribe an appeal is automatically triggered.

The result enables judges to act honestly with less risk of ending up in the minority without an appeal being triggered (where they would lose reputation or their part of their staked deposit).

This modification makes it riskier for attackers to bribe, as judges are more likely to act honestly increasing the likelihood that the bribe will need to be paid out.

The combined effect should result in much more fair dispute resolution.

In order to implement a way for judges to privately indicate if they suspect a bribe has influenced the dispute, I’ve outlined two solutions bellow, both approaches essentially do the same thing, but have different strengths and weaknesses.

Possible implementations:

Anonymous Voting with ZKP

This mechanism is credited to the work @stonecoldplat and his work on Anonymous Voting which can be found on his Anonymous Voting repo where he implements the voting protocol in described in this paper.

It uses ZKP and homomorphic encryption to make it impossible for other contracts to know which judge reported being influenced by a bribe without the judge revealing publicly how they voted. Since there would be no reason to reveal this information other than to coordinate with an attacker, we can use this to identify and punish judges who accept bribes.

The main problem with this approach is that a judge can still choose to reveal their vote to an attacker. Which means attackers could write contracts that only allow judges to claim bribes if they confirm that they did not submit a bribe alert. This is still better than before because it requires the judge to interact with the attacker onchain, making it easier to prove the dishonest judges acted maliciously, however they can simply wait to claim a bribe until they have withdrawn their deposit to avoid or delay punishment.

Using Keep or another mechanism for secure multiparty computation

Using the approach described above Judges can still collude with attackers to accept bribes.

It would be more secure if we make it so judges are incapable of revealing their committed alert. Using a mechanism like keep.network to create private storage and execution environment for a smart contract we can have judges encrypt their votes using the public key of the keep, then using the keep to privately decrypt and tally the votes. Returning the result back to the smart contract securely.

This mechanism is objectively better at preventing bribery attacks, but requires sMPC which does not appear to be ready for a production implementation at this time.

Goals

Execute a Reserve Strategy and publish forward guidance to the market in order to incentivize stable growth in the overall value of Aragon.

• Develop reserve ratio strategy and timeline
• Publish stated goals/ forward guidance for the market
• Execute strategy in given time periods, using trades to stabilize and increase Aragon valuation

Description

The strategy proposed is to create target ratios for reserves of Aragon assets, primarily ETH/ANT ratios, as valued in $, and provide a timeline for each ratio to be achieved.
Utilizing liquid assets (ETH) to create market orders to buy ANT at low limits, as well as ANT sell orders at high limits, The variability of ANT price (relative to ETH) is limited and a growth trend can be established for ANT valuation while avoiding variable spikes.
Significant market sell orders at high limits are created prior to the announcement to ensure no extreme variability of price on the upside.
Increase of holdings of ANT by multi-sig benefits all current ANT holders, who get a larger voting share as a result.
Increase in valuation of ANT benefit Aragon as well as ANT holders.
Ample ETH reserves are maintained for payment of developers and necessary functionality.
Gradual change in Reserve ratios over given time periods ensures a steady increase in value of ANT market cap, attracting additional investors and developers.
Using reserve assets to place large buy/sell orders at the low/high limits decreases volatility and ensure the reserve re-allocation is done in a responsible and gradual process where trades only take place on behalf of Aragon which benefit Aragon.

Proposed Reserve Re-allocation Timeline:

Stage 1 -0-3 month timeframe - 5:1 ETH:ANT $ Valuation Reserve target
Stage 2 -3-6 month timeframe - 4:1 ETH:ANT $ Valuation Reserve target
Stage 3 -6-9 month timeframe - 3:1 ETH:ANT $ Valuation Reserve target
Stage 4 -9-12+ month timeframe - 2:1 ETH:ANT $ Valuation Reserve target

Going forward
By next year, ideally, the ANT holders will have the operability to vote on proposals in order to maintain or alter the Reserve Strategy.

Uncertainties

-The primary uncertainty is what limits to set in order to achieve the desired goals. Ideally, these should be purely mathematical, but practically, a competent trader could achieve these goals without strict mathematical limitations, other than the general guidance to achieve the target Reserve ratio by the end of the Stage period (within a certain variability, say +/- 5%), using a basic 3-month trend line for guidance for trades.
-Another uncertainty is trading pairs. Ideally, trade could be done using the ETH/ANT trading pairs, rather than converting to BTC as an intermediary. While this volume would benefit the adoption of ETH trading pairs (BTC is unnecessary as intermediary, it is simply the most trafficked), and would be entirely feasible as the means to incentivize the market to adopt this trading pair, it might not be entirely practical. If the ETH/ANT trading pairs are used solely for the revaluation of reserves, the free market will arbitrage any spread to ensure the adoption takes place, but that arbitrage will be at the expense of Aragon, so it may be prudent to do some trade in BTC as well as ETH pairs to ANT, if not entirely necessary.
-Trend lines to determine market orders, as well as the mathematics behind these decisions are a uncertainty as well. This could be done algorithmicly, but lacking the expertise, a competent trader can execute the strategy to achieve the desired reserve ratio requirements gradually while profiting Aragon from the limit orders which limit variability on the high and low side. Something on the order of +/-33% above and below the trend line toward the next reserve ratio to place buy/sell orders is one (somewhat arbitrary) suggestion.
-The execution of the strategy requires a dedicated manager who is trusted to manage the orders and reserves. They should be given limited access to funds on designated trading platforms in order to achieve the stated goals. Amount of liquidity available to manager should be limited relative to total reserves, while ample enough to achieve stated aims, and allocation should be re-adjusted every 3-month stage.

Goals

Implement a model, in which token-holders of organization always have access to their fair share of liquidity reserves thanks to reserves being implemented with Bancor formula.

• Increase value of the issued tokens by providing liquidity
• Allow attracting more capital by decreasing negative perception of "over-funded" projects
• Allow minority investors to exercise their freedom to leave organization with their fair share of reserves
• Increase transparency and accountability of crowdfunding initiatives, by implementing step-by-step reserves-to-budget transfers.
• Allow additional trajectories of governing dynamics

Description

When tokens issued by organization are backed with liquid reserves, then the whole process of organization formation may be seen as a process of initial reserves formation.

After initial formation such organization may have a vote about transferring part of the reserves into budget of organization for operational needs (next stage of product development for example).

So organization development may be seen as step-by-step growth of investor's trust, and gradual access of organization to reserves of founding community.

However, when token is backed by liquid reserves, minority investors will be capable to leave organization with their fair share of reserves without consent of majority investors to do so.

In this model liquid reserves would represent degree of investors trust in organization's achievements and path chosen.

Organization members would be able to diverge from "general line of the majority" and to form alternative organizations to pursue alternative approaches.

Responsible, accountable and transparent organization would be able to gradually access funding from reserves. For example, crowdfunded organization created for software development project would be able to access additional funding from reserves on each milestone of the project.
So reserve ratio (decreasing from 1 to whatever limit or maybe even to 0) would reflect minority investor confidence, while giving them freedom to "vote with their feet".

Both initial and current reserve ratio may may be exposed via Token's contract API (and crowdfunding UI).

Obviously, every voting that affects parameters of the reserves is a potential threat to the interests of minority that is loosing the voting. Having reasonable delay (24-72 hours) before changing reserves would give loosing minority time to leave with their fair share of reserves.

Uncertainties

Such degree of minority's freedom is quite uncommon, and some organization founders may prefer to avoid usage of such feature.

Goals

I would like to propose a system of judging issues that are subjective and based on shared personal values in a limited population.

Description

Suppose an Aragon company CEO has a clause in his contract that states the board members can terminate him at any time, without any sort of compensation, if he publicly engages in "inapropriate behavior while representing the company". Now this is usually a typical clause in a traditional contract, but something very hard to enforce in digital blockchain companies.

Now let's imagine that the CEO organized a party with strippers on the company headquarters, which was amply photographed and shared on social media, and the board has decided this violates the "inappropriate behavior clause". The CEO, believes that the board wanted to get rid of him any way, and that this is just an excuse to avoid paying him the million dollar compensation for being fired, so he will try to fight it.

How can a contract define "appropriate behavior"? This will deeply depend on personal moral views on employment of sex workers: while some group of people might see this as extremely innapropriate, others believe that this is a perfectly honest job. Even among those, the line is blurry: what if it was a prostitute instead of a stripper? What if the CEO actually paid them for a private service?

This is where this sort of oracle could come in:

• The system picks a mersenne prime (2^n-1) number of judges to make a decision

• If one of the party disagrees, they can increase the bond and call a higher instance that increases the number of judges.

• The judges of each instance will be rewarded/punished by comparing their decision with the instance in which the trial ended. So the rule of each level of judges is not only to follow what they believe but also what they think other judges will think, so there's an incentive for them to look at past judgements and a system of precedents. If their decision was overturned then they'll be punished (by loss of reputation, payment or some other way) in accordance to how much their group's proportion was out of bounds.

• If an issue is very controversial, or if one of the parties has a strong incentive to fight, the number will increase so much that it would be more similar to a jury system, and then finally a popular vote. Since larger votes also set precedents, there is an incentive for third parties to work as "rights group" and help pay the bond of what they believe to be an unjust trial.

• The ultimate vote would be a set of judges so large that it becomes effectively a popular vote. Since this is the last appeal, then each voter can vote according to what they believe should be the new precedent. A large vote means that if the population (at least the population's) belief and attitude towards that particular matter can change and contradict past judgements.

Uncertainties

The system depends a lot on how voting is decided or weighted, as it only works if voters are a diverse set of people that have a stake in the future of Aragon. It might also fail if ultimate voters are swayed by external events or can be bribed via smart contract

Goals

We want a productive, happy and agile community that can welcome and bring forth new ideas.

We will rely on 5 key principles:

• Independence
  • Decision-making structure
  • Independence from employment relations
• Pluralism
  • Diversity of contributors
  • Management of conflict
  • Determination of leadership—processes and turnover
• Representation
  • Membership structure and rights
  • Ways in which those in authority are accountable to contributing members
  • Degree to which members can exercise voice on community members
• Decentralized decision-making
  • How contributors gain code commit and #frontline rights
  • How contributors gain access to the project’s decision-making structure
  • The degree to which project communications and activities are publicly available
• Autonomous participation
  • Newcomer joining rate
  • Newcomer socialization opportunities
  • Rate of idea generation

Description

Our Code of Conduct and Community Guidelines act as a basis for all our community activity, how to participate, how to grow our community, how to represent Aragon to others outside the community.

Proposed meetings:

• Dev meeting: Bi-weekly, Fridays on uneven weeks. Time 14.00 CEST.

  • Discussion on current technical development, what has got done, what needs to get done for the next release etc.
  • Facilitator: Tech Lead
  • Participants: Aragon Dev team + Any Aragon team members who want to participate + possible relevant contributors
  • Viewers: Public on Youtube

• Aragon HQ: Monthly, Last Friday of the month. Time 15.00 CEST.

  • Discussion about the state of Aragon, near future plans and decisions that need to be made. 10 min presentations with slides from team members, in which each one will run through the most important things we have done during the month, the problems they have found, and what they plan to do next month (that can be a bit blurry, and that's fine)
  • Facilitator: Project Lead
  • Participants: All Aragon team members + possible relevant contributors
  • Viewers: Public on Youtube

• Team hangout: Weekly, Friday. Time 15.00 CEST

  • Relaxed weekly meeting with the team where anyone can talk about things they feel are current
  • Facilitator: If needed, any of the participants
  • Participants: Project Lead + anyone from the Aragon team who wants to participate
  • Viewers: Non-public

• Community meeting: Monthly, second Friday of the month. Time 16.00 CEST.

  • Discussion about Aragon, questions from the community members answered by the team. AMA will be conducted in /r/aragonproject
  • Facilitator: Project Lead/Community Lead
  • Participants: Project Lead + Community Lead + Aragon team members who want to participate
  • Viewers: Public on Youtube

Structures:

• Project Lead or Tech Lead will have final call on all things pertaining to their area of expertise.
• Decisions made after thorough conversation on Meetings, informal vote to be taken if necessary, possible conflicts discussed if necessary, final vote if needed and decision confirmed by Project/Tech Lead.
• Facilitators are responsible for gathering the agenda for the Meetings where applicable, as well as either taking notes of the Meeting and decisions made or delegating this responsibility to another participant
• Use (The Etherian’s or our own) Colony to have community members participate and get rewarded for their non-code contributions
• Implement a system similar to Maker’s Actions and post a monthly transparency report about the use of funds to the blog
• Institute Aragon Improvement Proposal, AIP, system for community members to create proposals about Aragon. Take a similar approach for governance with Aragon Governance Proposals (like this one). GitHub Issues will be used as a forum to discuss proposals by community and team members
• Proposals and ideas from the team and community members will be go through the AIP/AGP process and will then be discussed in the relevant Meetings
• Community Meetings will be AMA styled video meetings where team members will answer questions by the community members. Questions will be submitted through Reddit and answered live
• We’ll have templates that can/will be used for the basis of agendas in Meetings so the Facilitator can easily fill out each Meetings info, like who will be presenting what, who has slides etc.
• Facilitator of the Meeting will make sure that the discussion stays on rails, everyone gets a chance to speak their mind, everything on the agenda is discussed, necessary decisions are made and that the Meeting length stays on a reasonable length

Uncertainties

Any right now, but feedback is very welcome! And thanks @kennyrowe for the feedback on this and @Smokyish for the initial draft and putting everything together!

We intend to use this issue along with ANT signals from the survey app to gauge community sentiment.

We would like to understand how ANT holders feel about EIP999, as it is a significant discussion within the wider Ethereum community that impacts the Aragon project and its community members. Please use this issue for discussion and the Survey app to signal support, you can split your vote between options to express mixed sentiment.