aragon / aragon-apps

(Aragon 1) Aragon apps developed by Aragon Core Devs (smart contracts + webapps)

Aragon Apps

Apps

This monorepo contains the following apps:

• Agent: Hold assets and perform actions from Aragon organizations.
• Agreement: Govern organizations through a subjective rules.
• Finance: Send payments and manage expenses with budgeting.
• Tokens: Manages an organization's token supply and distribution.
• Vault: Securely owns and manages tokens on behalf of a DAO.
• Voting: Create votes that execute actions on behalf of token holders.
• Disputable Voting: Create disputable votes that execute actions on behalf of token holders.
• Open Enterprise Apps:
  • Allocations: Create proposals for financial allocation.
  • Address books: Map Ethereum address to human-readable names.
  • Projects: Allocate funding to Github issues.
  • Dot Voting: Cast votes for Allocation or Issue Curation proposals.
  • Rewards: Distribute payments to token holders.
  • Standard Bounties: Issue bounties for tasks.

Each of the individual apps come with a frontend that is intended to be installed and used through the Aragon client.

You can read more about how each of the individual apps work in the Aragon user guide.

Quick start

aragon-apps uses yarn workspaces and lerna to manage its individual app workspaces.

To bootstrap, run:

yarn

This will initialize and install each of the individual apps, hoisting their shared dependencies into the root node_modules/ directory.

💡 If you're only interested in bootstrapping one package, you can go to that specific package workspace and use yarn install --focus

Smart contracts

Running tests on all apps can be done by running yarn test at the root directory (note that this can take a significant amount of time!).

Running tests of an individual app can be done by running yarn test inside an individual app's directory, or through the selective yarn test:<app> scripts.

By default, tests are run on an in-memory instance of testrpc.

Frontends

Each app's frontend is encapsulated inside of that app's own app/ directory.

To work on frontend, you'll need to go into app/ directory and do another yarn installation. For more instructions, you can follow the "Frontend Setup" guide in the Aragon client. Note that the app itself doesn't need to be bootstrapped if you'd just like to install the frontend.

For example:

# Starting at this project's root
# Go to the Voting app's directory
cd apps/voting

# Go to the Voting app's frontend directory
cd app/

# Install and start
yarn
yarn start

Contributing

For some introductory information on what an Aragon app is, and how to build one, please read through the Aragon stack introduction and Your first Aragon app. To build Aragon client-compatible apps, the aragonAPI documentation is also available as a reference.

👋 Get started contributing with a good first issue.

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 more details about contributing to Aragon, please check 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 client's 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.

Help

For help and support, feel free to contact us at any time on our Discord.

aragon-apps's Issues

Add missing apps

Add the missing apps as they become stable

• #1: Add fundraising app
• #2: Add finance app
• #3: Add token manager app

Check and test rounding errors calculating returnAmount

Given that the calculation has to be done twice, there could be some rounding errors.

We should test to see how significant they are.

aragon-apps/apps/fundraising/contracts/Fundraising.sol

Lines 256 to 265 in d461575

	if (!sale.isInversePrice) {
	returnAmount = nonBoughtTokens.mul(price).div(pricePrecision);
	} else {
	returnAmount = nonBoughtTokens.mul(pricePrecision).div(price);
	}
	uint256 finalAllowedAmount = allowedAmount.sub(returnAmount);
	sale.soldAmount = sale.soldAmount.add(allowedBuy);
	sale.raisedAmount = sale.raisedAmount.add(finalAllowedAmount);

Add badges

Upgrade truffle and solc and use 'view' and 'pure'

Similar to aragon/aragonOS#169

In the case of the Finance app there can be some constant functions that need refactoring to convert to view, given that they modify state.

Add npm postinstall hook to run `npm run bootstrap`

Implement Fundraising dApp

Screens: https://app.zeplin.io/project/59a827960d4c4cb2274007f5/screen/59a827fdceb5217b7c8c8d79

Last priority towards 0.5 release

Limit how many tokens can an address have

After #51, adding a limit on how many tokens can a particular holder have, the Token + Voting app can start to resemble a board (a multisig).

This limit would not apply to how many tokens the Token Manager itself is allowed to have.

Language improvements: use the term Vote instead of "Voting" (when referring to an object)

[updated per @sohkai's feedback to use the term Vote, instead of the previously suggested Proposal]

Problem

In the current design of the Voting Dapp, the terminology "Voting" is used to describe a proposal-like object, which is a noun. I believe the better terminology to use is "Vote", since "voting" is a verb, hence there are grammatical errors.

Proposed Changes

This terminology should be updated throughout Aragon when Voting is used as a noun. For example, the headings such as "Open Votings" or the button "New Voting" within the Voting app, in addition to anywhere else in Aragon that discusses the object, such as the Permissions page, or Bylaws, etc.

Some stuff that needs more brainstorming

In the left menu, I think the work area can still be called "Voting", as it is fine to use a verb here. But it is debatable. Renaming it "Proposals" may be more consistent with the updated terminology, yet if Polls are included in this work area, it wouldn't totally mesh as Polls are not Proposals. Alternatively, if it was renamed to "Decisions" or "Forum", this language would make it easier to expand the work-area into different topics the DAO is considering, that may not necessarily all be up to voting yet.

Keep track of all token holders in Token Manager

This is an extremely short term solution that will allow the Token Manager frontend to load much quicker.

Given #51, which allows to have boards with just tokens, a way to quickly a list of all token holders is important.

Adding this will add ~45k gas every time a new holder is added. Expensive but might be worth it in UX terms in the short term.

Finance: receiveApproval should check from sender

From @ewingrj:

https://github.com/aragon/aragon-apps/blob/master/apps/finance/contracts/Finance.sol#L146 should have require(msg.sender == token)

Run tests in geth and parity

Same as aragon/aragonOS#171

Update aragon-core dependency to 1.0.2 and adapt tests to Byzantium

A similar PR was already merged for aragon-core which could be used for reference: aragon/aragonOS#145

Remove staking logic from Token Manager (wrapped mode)

The 'wrapped mode' makes the Token Manager too complicated. The wrapping/staking logic would be better separated into other app/s. Token Manager only purpose should be to manage a token it has controller power over.

A generic staking contract could be done that could also work for other usecases.

Token Manager loses the notion of having two 'modes' (https://github.com/aragon/aragon-apps/blob/master/apps/token-manager/contracts/TokenManager.sol#L66), and everything specific to wrapped mode needs to be gone.

Token Manager UI changes for allowing group/multisig-alike interfaces

We agreed to keep the same UI for both the Token Manager and the recently deprecated Groups app (#55).

It is a challenge to represent a group without adding some sort of arbitrary switch when deploying the Token Manager instance, which wouldn't be elegant and wouldn't allow for more advanced uses cases (we should assume that a token can represent anything, not just membership).

Groups are token instances in which all the token holders (group members) have a permission or right for belonging to it. They have the following characteristics:

• Tokens are not vested
• Tokens are equally allocated to all holders

So my proposal of required changes to the Token Manager app is:

• Rename Holder by Owner. It represents the concept better
• Detect when tokens are equally distributed, and hide the Amount column and the Ownership distribution section
• Detect when no tokens are vested, and hide the Vesting column
• In case of confusion, when creating new tokens, if the tokens will be primarily used as a Group, instruct users to add the word Group to it. I think this will happen naturally

I think this helps the user understand what it's a group, without having to add any code or custom UI for edge cases.

Rename module.json to app.json?

Set up code coverage

Move 'fundraising' out of apps directory

As we are not shipping this app in the first release of v0.5, make it easier for readers and auditors to know it is not part of the release

Implement Finance dApp

Screens: https://app.zeplin.io/project/59a827960d4c4cb2274007f5/screen/59a827fd1707a6ef5b5d5bec

Enhance bylaw logic for Voting app to allow more customized quorum and approval rules

Problem

Based on the Voting specification: http://wiki.aragon.one/dev/apps/voting/

It seems that DAOs will be forced to measure "quorum" based on the number of acceptance votes, as opposed to more standard logic for what "quorum" actually means.

Whenever you use "Quorum" terminology in the Aragon app, it will be very confusing if you are treating Quorum to mean "minimum acceptance quorum", as this does not match up to the definition of quorum for organizations/businesses, which is:

"Fixed minimum number of eligible members or stockholders (shareholders) who must be present (physically or by proxy) at a meeting before any official business may be transacted or a decision taken therein becomes legally binding." Read more here: http://www.businessdictionary.com/definition/quorum.html

Solution

In addition to this problem with the terminology, this quorum/acceptance logic should be more flexible. I see three use cases for how a DAO can formulate metrics for approving proposals:

Disable Quorum

If a DAO does not care to consider "Quorum" as a metric, then it can be disabled in the bylaws, and Approval percentage based on total token supply can be used. Quorum terminology should never be used in DAOs that do not care about true Quorum requirements. [this is equivalent to minimum acceptance quorum]

Enable Quorum

Whenever Quorum is enabled, this means the Approval Percentage is based on the all of the tokens that voted, and not on the total token supply.

Modified Quorum

If a DAO wants to be more flexible with how proposals are passed, then allow a feature called "Modified Quorum" which will serve as a conditional logic to determine when the Quorum metric should be considered and how it is treated in relation to Approval Percentage. For example, the DAO can define two ways for proposals to pass. After the time period has ended, if either condition is met, the proposal is approved:

• if Quorum percentage is met & Approval Percentage (based on quorum) is met
• if Yes votes = Quorum Percentage * Approval Percentage [this is equivalent to the "minimum acceptance quorum" variable used in the current Aragon logic]

Here is an example of how you can accommodate for the third use case. When I have more time I can try to simplify the language & mockup a screen that would accommodate to all 3 use cases I described above, but if you shared your current Bylaw screens (if you have any), that'd be helpful.

---

Move generic components used in Groups app to aragon-ui

With #16 merged, we should start moving out some of the reusable components to @aragon/aragon-ui.

@bpierre and I identified:

• Table and TableItem generialized from Entity
• OverlayPanel (renamed as SidePanel)
• AppContent / StyledApp (packaged together as DefaultApp)
• TopBar (renamed as AppBar or AppTopBar?)
• Field (able to handle labels)
• EmptyStateCard
• various components from FakeShell useful in @aragon/aragon

Prepare for solidity github syntax highlighting

github-linguist/linguist#3973 (comment)

Allow execution of callscript on votes not passing

DAO integration tests against Beta templates

Construct a dummy DAO with the current apps that will be part of the v0.5 release and interact with it asserting all parts are working as expected. There shouldn't be any surprises but a full test case would be great to have!

Blocked by #72

Add publish script

Add publish script that publishes packages using aragon-dev-cli publish.

Check access modifiers for all contracts

All functions should have an explicit access modifier (external, public, etc.).

Add gas reporter for tests

https://github.com/cgewecke/eth-gas-reporter

It would be awesome to know how much gas our tests are taking.

Execution logic in Voting app

At the moment, the result of a vote in the voting app is automatically executed if casting one vote makes the voting decided.

The problem with this is that if the executing call fails, the entire transaction is reverted and the vote isn't counted.

Possible solutions (complimentary):

• Add a boolean parameter to the castVote function to specify if the vote should be executed if accepted.
• Allow execution to fail but don't revert the transaction, similar to how the Gnosis multisig does when the execution fails (marks tx confirmation, but marks as not executed). This would require a way to execute EVMCallScripts without reverting when one underlying call fails.

Right now there is no notion of an expired voting, if it was approved then it can be executed at any point in time (by anyone). This could result in 'toxic votes' that get forgotten because execution was failing (a removed permission), but that could be used down the line if the becomes executable.

NFT Vault app smart contracts

ERC721 defines the standard for Non-Fungible Tokens (NFTs). By supporting ERC721 Aragon organizations will be able to manage NFTs.

Decentraland's LAND and Cryptokitties both use ERC721 NFTs and seems like it will become the standard for future tokens.

Check the Token Vault for reference and inspiration

Add token manager app

Add function to Finance to send tokens to Vault

If accidentally somebody sends tokens to Finance contract address directly through transfer, tokens could be locked in that contract as Finance doesn't have a way to send transactions (it's using Vault for that).
My suggestion is to add a function that allows to send all tokens in Finance to Vault anytime.

Add manifests and metadata

Add manifest.json and module.json (metadata file) for all apps

• Vault
• Group
• Voting

Set up linting

Implement Token Manager dApp

Needs aragon/aragon.js#43 and aragon/aragon.js#41

Allow to perform actions as token holder with tokens held in Vault

Sometimes the tokens being held in the Vault do not have only economic value, but also allow the holder (the DAO) to perform some actions such as voting or requesting dividends.

A way to forward actions to other contracts as the Vault to perform actions as the token holder is needed.

A more elegant approach would be just a flow of doing an approve/transferFrom with the contract that wants to perform the action as the holder, and at the end return the tokens back to the Vault. This approach wouldn't work to vote with MiniMe tokens, given that the balance is checked at a particular block height.

getRemainingBudget may fail after budget decrease

After a budget decrease, checking the remaining budget can fail because expenses are greater than the budget amount for a given token.

We should add a check on whether what was already spent is more than the budget and return 0 as remaining budget.

Integrate node-aragon in Group app

Currently the frontend for the Group app is working inside a FakeShell component with dummy data.

Needs to start using node-aragon to interact with the on-chain component of the app

Allow TokenManager to make tokens non-transferable

Add a flag to the TokenManager app to block all token transfers besides initial minting, assignments by the TokenManager and burning of tokens.

Voting app events

Done We should add an event to log when the changeMinAcceptQuorumPct happens.

Also we should the number of votes that got casted in the CastVote event

Add finance app

Make app storage layout more graceful to app upgrades

See my explanation: https://youtu.be/sJ7VECqHFAg?t=9m27s

Basically convert arrays to mappings.

Implement Voting dApp

Screens: https://app.zeplin.io/project/59a827960d4c4cb2274007f5/screen/59a82800d913ba794a4a5b4a

Hoist @aragon/aragonOS

This is not possible at the moment due to trufflesuite/truffle-resolver#7.

Deprecate Group app

#51 + #52 + #53 allow the same functionality as the current Group app, plus a multisig (closes #17) and different board structures when combined with a voting app. All this, plus removing a lot of code!

Membership to a group would be expressed by ownership of a non-transferable token. Actions as a group member can be forwarded with the forward function of the token manager!

Note: will also close #35.

Assert that calculatePrice function is running in correct period

calculatePrice(...) is only called by functions that have already transitioned sale periods if needed. We should add an assertion in the function to ensure that the sale is in the correct period. Given that the check is redundant and under normal execution shouldn't happen, it should be checked with an assert(...)

aragon-apps/apps/fundraising/contracts/Fundraising.sol

Line 288 in d461575

function calculatePrice(uint256 _saleId) internal constant returns (uint256 price, bool isInversePrice, uint256 pricePrecision) {

100% test coverage

Add receiveApproval function to Finance contract

As stated in the wiki, in order to deposit ERC20 tokens in Finance app, right now we need 2 calls:

token.approve(finance, amount)
finance.deposit(token, amount, string reference)

While for ERC677 tokens we just need one:

token.transferAndCall(finance, amount, string reference)

Adding the function receiveApproval would allow to deposit ERC20 tokens using just one call too.

Add fundraising app

Remove babel

When aragon/aragonOS#154 is merged and a new aragon-core release is made, we need to remove unused dependencies from all apps packages.

Multisig app

At the present moment the most widely used governance mechanism is through a multisig.

Different alternatives for implementation:

• Use a widely used trusted multisig like Gnosis.
• Extend Group app to require n confirmations before performing action (currently Group app is a 1 out of m multisig)

I personally think it is a better idea to implement our own solution for this on top of the Group app. Another question if we go down this route is whether we have two separate apps (Group and Multisig) or the current Group functionality is just a Multisig with only one required signature.

Use @aragon/os 3.0.0

Tons of changes since aragon-core 2.0.1. As soon as aragon/aragonOS#182 is merged, we can start updating apps to use the new version.