aragon / client

(Aragon 1) Create and manage decentralized organizations on Ethereum.

Aragon Client

🌎🚀 Trusted by over 1500 organizations, securing more than $300MM in funds. Try it out.

• 📚 Read the User Guide first, if you have any questions as a user.
• 🏗 If you'd like to develop an Aragon app, please visit the Aragon Developer Portal.
• 📝 Please report any issues and feedback in the support channel on Discord.
• 🔧 For technical stuff, use this project's issues or join the technical conversation in the hacker hangout channel on Discord.
• 📖 To learn more about contributing to the Aragon client itself, please check the contributing guide.
• 🚢 For an overview of what changed with each release, check the releases.

Quick start

Install with yarn and launch the app with yarn start. By default, the app is configured to connect to the Ethereum Goerli testnet.

For connecting to other chains / deployments, a few useful npm scripts are provided:

• Ethereum Mainnet: yarn start:mainnet will launch the app, configured to connect to the Ethereum mainnet
• Local development: yarn start:local will launch the app, configured to connect to our aragen local development environment. It will also use the local IPFS daemon, if it detects one exists. If you're using the aragonCLI, you'll want to run this to connect to its local chain.

Note: Windows users may need to install the windows-build-tools before installing this project's dependencies.

More configuration options are available, and depending on your needs, you may find the frontend development setup guide helpful.

Releases

The Aragon client is automatically deployed to IPFS with each new commit to master, via Fleek. The latest builds are available at client.aragon.org or through an IPFS gateway, like ipfs.io/ipns/client.aragon.org.

aragonPM

"Checkpointed" releases, tagged in our releases page, are published on-chain onto the aragon.aragonpm.eth aragonPM repository for all supported Ethereum environments (mainnet and Goerli testnet).

For a long time (2018-2020), these releases were our primary "official" builds. With Fleek, however, we now relegate these on-chain deployments as historical backups in case a user wants to use an older version.

Secrets

A number of environment secrets are required during publishing and these are sometimes different per network.

You may either specify these secrets as environment variables or use a .env.

Contributing

👋 Get started contributing with a good first issue.

🎓 You may be interested in the Aragon client architecture guide if you're not familiar with how the project is set up.

Don't be shy to contribute even the smallest tweak. 🐲 There are still some dragons to be aware of, but we'll be here to help you get started!

For other details about contributing to Aragon, more information is available in the contributing guide.

Issues

If you come across an issue with Aragon, do a search in the Issues tab of this repo and the Aragon Apps Issues to make sure it hasn't been reported before. Follow these steps to help us prevent duplicate issues and unnecessary notifications going to the many people watching this repo:

• If the issue you found has been reported and is still open, and the details match your issue, give a "thumbs up" to the relevant posts in the issue thread to signal that you have the same issue. No further action is required on your part.
• If the issue you found has been reported and is still open, but the issue is missing some details, you can add a comment to the issue thread describing the additional details.
• If the issue you found has been reported but has been closed, you can comment on the closed issue thread and ask to have the issue reopened because you are still experiencing the issue. Alternatively, you can open a new issue, reference the closed issue by number or link, and state that you are still experiencing the issue. Provide any additional details in your post so we can better understand the issue and how to fix it.

Contributors

Thanks goes to these wonderful people (emoji key):

Pierre Bertet 💻	Brett Sun 💻	Gorka Ludlow 💻	Jorge Izquierdo 💻	Luis Iván Cuende 💻 🎨 🤔	Oliver 💻	ßingen 💻
Daniel Norman 💻	John Light 📖 🐛	Tatu 📖	Patricia Davila 🎨 📓	Jouni Helminen 🎨 📓	Luke Duncan 🤔	Daniel Constantin 💻
RJ Ewing 💻	Paul Henschel 💻	Rodrigo Perez 💻	gasolin 💻	Adam Soltys 💻	Arun Kumar 💻	Beer van der Drift 💻
Daniel Caballero 💻	Deam 💻	Ilia Smirnov 📖 🔧	julsar 📖	Pascal Precht 🔧	Rudy Godoy 📖	Yalda Mousavinia 💻
decodedbrain 💻	jvluso 💻	mark g romano 💻	mul53 💻	Jon 💻	Abhinav Sagar 🚧	geleeroyale 📖
Otto G 💻	Adam Boro 💻	Emilio Silva Schlenker 💻	Olivier Sarrouy 💻	delfipolito 💻	Enrique Ortiz 💻	Fabrizio Vigevani 💻
Mathew Cormier 💻	Mick de Graaf 💼	iwaduarte 💻	EC Wireless 💻	owisixseven 🎨	Andy Hook 💻

This project follows the all-contributors specification. Contributions of any kind welcome!

Re-usable foundations

Amongst other dependencies, the Aragon client is built upon these packages that you may also find useful for your projects:

• aragonUI: React component library used to build user interfaces within the Aragon design system
• token-amount: utility class for encapsulating and formatting a token amount
• use-inside: React utility that allows a component to be aware of being "inside" the subtree of another component
• use-token: React utility for fetching information related to tokens on Ethereum
• use-viewport: React utility providing the current window size and convenient functions for responsive apps
• use-wallet: React utility aiming to make the integration between your dapp and your users' web3 wallets as straightforward as possible
• web3-react: a simple, maximally extensible React framework for supporting arbitrary web3 wallets

client's Issues

Settings app design UX

Fundraising module allows raises in different tokens

Features

• Fundraising module will be kept basically the same for 0.4.
• Needs to allow to do the fundraise in any ERC3 token.
• Probably adding a new fundraise mechanism similar to the Aragon Sale in 0.4.

Initial steps

@izqui to lock interface for new fundraising functionality.

Adapt Voting app to new logic

Changes described here: #21

Multi-organization client

Right now, the Aragon client only supports an organization, and in order to interact with another one, you first have to unlink the previously set organization, and link with the new one. That's clunky.

I propose this new flow:

1. For each organization loaded into the client, we will create a different database for caching its state
2. The kernel/DAO address could be a URL parameter, so the URL would look like beta.aragon.one/{daoAddress}/{appId}
3. Then, switching DAOs is as easy as going to a different URL, so you could have different instances of the client opened in the browser. It would also play nicely with our Electron client.

Responsiveness

Had a meetup yesterday, we tried to use the desktop app on an ancient computer, but the resolution was so small that the two sidebars overlapped the centre column.

Better handling of smaller screen sizes would be great, especially since Aragon is integrated into Status.

Ownership app design UX

My UX proposal:

Ownership:

• split into two main tabs (Overview and Stock Classes)
• Table columns (Shareholder, Stock class, Tokens, Voting power, Economic rights, Actions)
• Table content grouped by Shareholders

Action modal:

Stock Classes:

Incentives for developers of Aragon modules

We are working to create a module system to let other developers extend Aragon. The basics for that are being built, starting with #19.

Of course users will want to use modules that add value to them, but we should also think about developers and how they may benefit from it.

A few ideas:

• Users pay a fee, depending on their organization's revenue, to an insurance contract, which will provide a bug bounty program for possible attackers that discover vulteoabilities in that module. If no vulnerabilities are found for each X period of time, part of that money pool goes to the developer

• Users could buy a governance token to have a say in the features that get implemented in the module

• Users could buy a support token to get support directly from the developer. As the developer's time is limited, this token would appreciate if there's a lot of demand for it.

This is just a few ideas, some probably inspired by the call I had yesterday with @jbrukh. Any new ideas/suggestions are greatly appreciated!

Metrics

We need to know how people are using the product in order to improve it. But we need all the analytics to be fully anonymous and untraceable. Any ideas?

Small spelling error.

"In Ethereum, code is immutable and everything is explicitely encoded. It is not up to random interpretation."

"explicitely" should be "explicitly"

0.4 feature freeze

According to the Development Plan, 0.4 should include:

• Economic abstraction: Orgs should be able to hold and interact with any standard value-holding token
• Improved budgeting and accounting
• Dividends for the organization token holders
• Fundraising with tokens, not only ether
• Funds vault: The only part of the company that is not expected to change, making upgradeability easy while maintaining the access to the funds.

0.4 is crucial, because it will be the first release that gets deployed to the mainnet.

https://github.com/aragon/aragon-core/issues/44

aragon/aragonOS#44

Vote, not Voting

As suggested by skwp on RocketChat, seems like voting is not even a word, so we should replace it with vote everywhere.

Voting app design UX

Throttle polling to web3 provider

~25% CPU cycles are spent on polling the web3 provider

Cache app frontend using service workers to avoid loading from IPFS on every load

Not sure how this would play out if using IPFS, but it'd be recomendable to use Service Workers to cache the dapp so it can work while fully offline

v0.4 Voting changes (also voting bylaws)

Part of the changes in the aragon-core refactor was adding MiniMe Token for governance of DAOs, which simplifies voting greatly as we don't need to lock token balances to avoid double-voting.

I took advantage of the situation to fully refactor voting and make it even more simple. Full PR with changes: aragon/aragonOS#32.

Significant changes product wise:

• Votings can now only be binary (Yay or nay). Current version supported multi-option but we never needed it in any usecase and no one missed it.
• All percentages in the smart contract are base 10^18 percents, that means for specifying that a certain action requires a 30% approval, that is represented with 30 * 10^16. This replaces the need for manually specifying the base of the fraction in every bylaw.
• The relativeMajorityOnClose option has been replaced by minQuorumPct (also a 10^18 percent). If set to true, relativeMajorityOnClose would allow for a voting to be successful on close if among the voting quorum it was successful, if set to false it meant you always needed at least that x% of the voting power to vote in favor. Minimum quorum is more flexible since you can specify what % of the voting power has to vote for relative approval to be checked. Old relativeMajorityOnClose can be done with minimum quorum, 0% being old false and 100% being true. But allows a whole new set of grays that makes it more flexible
• Minimum voting time has been replaced to a block number magnitude.
• Added a new minimumDebateTime setting in voting bylaws. Voting will start after a certain number of blocks so people can make their mind. Old behavior can be replicated setting it to 0.

Implementation details:

• Removed voteOnCreate and executeOnDecided options from the DAO logic. Those can be checked off-chain and send a parallel transaction to do a vote or execution right after the vote.
• The createVote action needs to be called from the DAO entrypoint (apply bylaws) while voting actions can be done executing the VotingApp directly, which will result in gas savings for a common action.

This voting app will be more than enough for most organizations, there is still space for a more complex voting app (delegate voting, weighted voting, multi-option votings...) that we could build ourselves or 3rd parties. Good thing is that the new architecture allows for installing another voting app and the rest of the system will work well.

Fundraising app design UX

New Fundraising:

Open Fundraising:

Infura isn't working properly...

Web interface fails, but it still deducted ETH from the wallet;

Bylaw and stock issued 48 years ago.

Using web version. Does that make sense?
I can provide more info if needed.

Add node-aragon

Add node-aragon wrapper and initialize it

Finance- app design UX

UX Solution:
I have merged an "Accounting" and the "Payments" into one module.

Remove top bar at the wrapper level and move instances to side bar

Right now the wrapper consists of the side bar, signer view and the top bar.

The top bar consists of the app name, a dropdown of the instance of the app and a button for common actions for that particular app.

My proposal is:

• Remove the top bar from the wrapper, instead let developers implement it with the UI toolkit inside their app, if they want
• Remove the app instances dropdown and replace it with a collapsible to the side bar. So, if you click over Tokens, the collapsible would unfold to the bottom and show you the different instances.

Pros: Easier to implement, less development time, more control to the dev, navigation unified in the side bar

Cons: We lose the ability for devs to declare main actions of their app that later can be used for some shortcuts or other UX sugar

Fundraising: could only set stock price to whole number (not decimal)

Surely we should be able to set stock price to decimal number?

Payments app design UX

Aragon Versioning Protocol

Goals:

• Fetch a code packages
• Automatically update code packages with new versions
• Know that you have the developer-published version of the package
• Isolate the modules from the rest of the modules/the application

Requires:

• Decentralized storage system: IPFS/Swarm
• Trustless identity system: Ethereum accounts
• Trustless timestamping system: Ethereum
• Sandbox to execute JS

Proposed flow for releasing a new version of a codebase:

What would be included in a transaction to the Metadata repository would be:

• URI where that code package could be found
• Hash of that code package

Since the hash of the payload is embedded on the Ethereum transaction, we don’t care about who owns the IPFS keypair, for example. Maximum security can be enforced at Dev, for example making Dev a multisig. That way, you can enforce however much security do you want by writing or using a contract. It also helps abstract the underlying storage system. This could work with any kind of storage, but of course decentralized storage protocols are preferred.

App would be listening for events in multiple repos and fetch new code packages accordingly.

This base protocol would be pretty generic and agnostic. But knowing that, in our case, we will primarily work on with JavaScript and web tech, we could go a step further and implement a full replacement for NPM.

This would be as simple as having a package.json manifest in all packages, where you can declare a package’s dependencies, and then fetching those dependencies. You could either state them with the Ethereum address of the Metadata repository where it lives, or… you could use ENS! We could own something like aragoncodebases.eth and give out developers subdomains for their Metadata repositories. Then you could just point to that subdomain as a dependency.

Asks:

• @harshjv to look into the sandboxing part, but I think it's safe to assume that it will have no impact on this protocol
• We need a better name 📦
• Thoughts? Ideas?

Endless hangs

When I try to change a role, I hit save and then it shows a progress wheel forever. Same on voting, issue shares, etc. If I click out of the screen to a different menu item, then go back, nothing is saved and I have to start all over again.

Move away from Meteor

Meteor has many flaws:

• Community is slowly dying
• Focus is on making server-client interaction easy. Aragon is serverless
• There are weird bugs all the time, and debugging is really complex, as we sit over a lot of abstraction layers
• Blaze is being kind of deprecated, Flow Router was deprecated, etc.
• It's extremely heavyweight
• Takes ages to build, which makes a terrible development experience

Let's move away from it to Vue. Let's discuss the approach here

Aragon Chat ...where has it moved to?

Limit/ban past date selection

As per @jonlac's suggestion and discussion with @luisivan; banning past dates in 'Round closes' is a good idea.

Thanks, @jonlac.

manifest.json for the Aragon Package Manager

The Aragon Package Manager will define and provide:

• A standard Web App manifest with some new keys we will define here
• A code package loadable by the Aragon app, which should be a browser-runnable web app which entry point is index.html

The new keys for manifest.json will be:

• permissions: It should be an array of call signatures that the app will use. We should inform the user before installing a new app, showing the permissions it requires
• contractsFactory: An Ethereum address that can be used to deploy a new instance of the app's contracts
• dependencies: An array of objects with properties signature and suggestions, indicating which signatures the app needs in order to work and some suggestions for apps that provide them

I think that's it. Please send feedback if anything seems to be off

Roles app design UX

Organization onboarding

Steps:

• List DAO available templates (Factories)
• Execute factory.newOrganization(params)
• Allow organization to get a name in an organization registry

Home app design UX

Home screen wireframe:

• shortcut for main actions
• notification element
• Your tokens

Use Prepack

This should speed things up, when the 0.5 refactor is done https://prepack.io

Bylaws app design UX

Bylaws:

IPFS/Swarm storage layer for organizations

This is something that is in our development plan, and we should slowly start brainstorming and collecting resources about tools to make it possible. I found this today https://github.com/orbitdb/orbit-db

Aragon modules and the web version

Aragon will support 3rd party modules at some point, but it does not seem to be possible for the web version.

Since the front-end part modules are written in JavaScript and should be easily integrated into the ÐApp, it would make sense that the Aragon "app store" displays certain Node.js packages from the npm registry (e.g. based on certain tags).

However, since modules would require npm in this case, and since npm does not run in the browser, this makes the web version impossible (at least with modules).

Furthermore, modules may leverage certain Node.js APIs that would not be translateable to the browser.

This puts the plans for modules in Aragon at a sort of crossroads. There are severals paths:

• Aragon will be desktop only
• Aragon will install modules in some other way
• Aragon will be desktop and web, but the web version will not support 3rd party modules

Do you have any thoughts on this?

Setup wallet step is skipped on the web version

If you click "Create a new organization" and you're not signed in into MetaMask, you get no error message. (Unless you open the dev tools)

Current behavior:

Expected behavior:
Go through the "Setup your wallet" screen (like the electron app):

Save button not visible in Roles

On linux client the save button(in Roles) is too far down to read. It's just a half-button that is purple.

User onboarding for Aragon ID

Steps:

• Check whether address has a valid identity mapping (address <=> ENS name). If not, register an identity:

  • Prompt user to register a username
  • After address has a name, use ReverseRegistrar to finish double mapping.

• Allow to join an existing organization or create a new one taking the user to the #55 flow

Show Ether price in selected currency on home page

Implement 'executeOnApproved' logic as a separate transaction

New voting logic removed the ability to send a 'executeOnApproved' boolean that would make the smart contract execute the voting if it had enough support.

This logic can be moved outside of the contract and send another execute transaction just after the first one (depending on nonce ordering).

New 'fundraise' have to ask for what token is the fundraise accepting. Token picker UI.

We could reuse the UI from 'New stock class' wrapped token.

It could be cool to have a list of common or recently seen tokens.

Accounting app design UX

Fundraiser doesn't create a new voting instance

There's some bug in creating a new Fundraiser, it doesn't work, no new vote is created even though the app says it is.

Got two user reports about this at Slack, issue has happened on OSX and Linux version of the app as well as the web version.

New Payments module

As discussed with @izqui, we should leave Accounting just as a ledger for past transactions, and create a Payments module that is just of issuing payments and payroll.

The reasoning is that payments will get complex in the future. A few possibilities that we could support in the future:

• English-written contracts that will be attached to an "invoice" and reviewable by the Aragon Network court if a dispute arises
• Payments that are done only when another action happens (such as an oracle seeing a GitHub PR closed, an address owning an ENS name...)
• Probably more to come

Will discuss with @owisixseven what's the best way to make this possible without replicating much of the UI -- aka, not listing payments in the Payments module and doing it again in Accounting

Get token holders directly by listening to Transfer(address,uint256) events

Migrating from our own GovernanceToken to a generic token standard, MiniMe, we have lost the ability to ask the contract for all the holders.

Now we need to locally cache the list of holders by listening to transfer events. All tokens of the DAO can be accessed using the TokenOrgan (https://github.com/aragon/aragon-core/blob/master/test/integration_ownership.js#L50)

Will be adding a TokenAdded and TokenRemoved at the DAO level to make it easier to listen to changes.

App list component with real data from node-aragon

Load list of app instances from node-aragon and show in sidebar.

Dapp needs to keep track of DAO installed applications

Blocked by aragon/aragonOS#40

Some calls (specially getters) can be directly done to the installed applications instead of going through the DAO.

The dapp should listen for the 'InstalledApplication()' event by the DAO, and save all the application addresses.

New Accounting module

Features

• See balance of organization in its multiple held assets (multitoken)
• Make one-time or recurring transactions in multiple tokens
• Allow transactions to be time delayed for security (big transactions can need 1 week to clear, and they can be cancelled in this period).
• Allow to set accounting settings to be enforced automatically (budgeting, dividend sharing threshold).
• Allow holders to receive dividends.

Initial steps

@izqui to provide smart contract interface and features for accounting
@owisixseven to design new module (@luisivan to help laying out the features)
@harshjv to start implementing module logic as soon as @izqui finishes interface