aragon / aragonos Goto Github PK

Current stock classes are completely independent tokens. It would be interesting to implement different stock classes that have the same underlying value.

Example of what could be accomplished with such system:

Stock A: Normal token (liquid token transferable in exchanges)
Stock B: Normal token + extra voting rights (illiquid, but convertible to Stock A 1-to-1)
etc...

Basically Stock B would need to have 1 Stock A for every token it issues, this way the conversion works simply as the unwrapping of the token.

Right now there's no way of looking up apps in the metadata repository because the only things provided on the Register event are the computed ID and the address of the organ or app.

The issue with this is that multiple apps or organs can have the same computed ID, since it's just a hash of the function signatures in that particular contract.

The provided address can be a shared instance between multiple DAOs or a single instance for that specific DAO, so we can't use the address either.

My proposal is that we change isDelegate to something like appId, where the appId is a unique identifier for the app in question (i.e. even if two apps A and B have the same compId, they will have a different appId).

For organs the appId would be nil.

• In order for the organization to be able to issue new tokens, the organization needs to be the token controller.
• No locking is needed as each vote will use the balance at a certain block height. This also allows for certain debate period, and for holders to sell or buy more tokens before certain vote starts.

It would be nice to have the ability to comment on votes while selecting "yes" or "no", I think it could lead to some debates.
Storing the comment string wouldn't be necessary, an event should be sufficient.
Thoughts?

If the idea is accepted I can implement it.

Right now upgrading an app or organ requires two different actions to deregister and the register the upgraded version.

MetaOrgan should provide a way for this actions to occur in the same call so it isn't open attacks in the period between the deregister and register

Right now nonces are just used for checking a certain preauthorized payload be executed just once, while also allowing for executing different times the same preauth action (with different signatures, of course)

As proposed in this EIP comment, it could be interesting to treat nonces below a certain x threshold (x = 10 ^ 10 seems good enough) as an incremental nonce. This means that a preauthorized transaction that has a nonce n below x, will only be executed iff last executed preauth tx for that address was n - 1.

It would require adding an additional storage key for keeping track of address nonces.

Tokens are arbitrary contracts that can run malicious code. Some sort of whitelist has to be implemented for the tokens that are allowed to execute transactions in the DAO.

There is an attack possible where you can create a fake token contract and make transactions to the DAO as another person. Only tokens with trusted code (that doesn't allow impersonation) should be added to this whitelist.

I think a good solution for this would be to implement a token whitelist in BylawsApp, and return false in canPerformAction if the token that performed the action is not in the whitelist (and therefore the sender cannot be trusted)

Migrated from aragon/issues#68

#1 removed the truffle build directory from the repo, which aragon-dapp uses for fetching the contract artifacts (and the deployed contract addresses).

@onbjerg proposal: https://gist.github.com/onbjerg/b828aa3bdcc6f9ad0a316a2bfc98a304

Looking into https://github.com/lerna/lerna too

Various events triggered by the different components would benefits using the indexed keyword from solidity (see http://solidity.readthedocs.io/en/develop/contracts.html#events).

Up to three parameters can receive the attribute indexed which will cause the respective arguments to be searched for: It is possible to filter for specific values of indexed arguments in the user interface.

It would ease the devlopment of an interface where it is possible to filter the various events, to list all changes linked to a specific bylaw or member for instance, or to filter by bylaw types.

For instance in https://github.com/aragon/aragon-core/blob/master/contracts/apps/bylaws/IBylawsApp.sol, event BylawChanged(bytes4 sig, uint bylawType, uint256 bylawId, address changedBy); could be event BylawChanged(bytes4 sig, uint indexed bylawType, uint256 indexed bylawId, address indexed changedBy);

@onbjerg in #52: Solium could be used as the linter, it aims to comply with the official Solidity style guidelines.

Just discovered that scripts/generate_factory.js is using a dependency (solidity-inspector) with a relative path (see https://github.com/aragon/aragon-core/blob/master/scripts/generate_factory.js#L5) which makes it unusable.

After a quick search I wasn't able to find it online.

Preface

daoMsg() is saved in storage in every transaction to the DAO so other organs can access the full message they are dispatching and eventually populate it to the applications.

Problem

Given that the same storage slot is used, if part of the call to the DAO needs to call the DAO (which could happen without malicious intentions), it would change the daoMsg() for the original call once it is resumed. This is not a problem if the daoMsg has already been set in the Application (we would have application reentracy issues too, but if an app makes a different dao call this won't be an issue).

Posible solutions

• Make all organ logic re-entrancy proof. Research and efforts towards it have started on #26 and exploring gas limiting functions to reduce reentrancy risk.
• Have multiple slots for daoMsg() and fetch it with certain key, for example the hash of the msg.data (which is a parameter to which all organs have access regardless of daomsg).
• Looking for new ideas

There is growing community consensus on using the I* (example IOrgan or IDAO) for declaring interface contracts.

Solidity throws when sending ether to a non-payable function.

aragon-core can't take advantage of this feature and right now all functions just allow any value with them and by default it will be deposited in the Vault and creates an untagged incoming transaction in Accounting.

One way to tackle this would be to add a new argument to bylaws on whether they allow value or not.

This is not as bad of an issue as DAOs will always be able to move that capital and will not get stuck as it would in non-prepared contracts.

Open for feedback, for whether this is something to solve and the way to do it.

Was blocked by #5

Applications have a different address than the DAO. By mistake someone could send tokens to apps.

We need to add a method that anyone can call on apps that will send assets stuck to the DAO. This should be implemented in the base Application contract so all apps inherit it.

Similar idea (but onlyOwner isn't needed as the funds would go to the DAO)
https://github.com/status-im/status-network-token/blob/master/contracts/SGTExchanger.sol#L107

Is there any particular reasoning behind depending on babel? It doesn't seem to be used, and the index.js file is fully supported in the latest Node version.

Reference: https://github.com/ethereum/wiki/wiki/Ethereum-Natural-Specification-Format

To make easier to track when governance tokens have been added/removed

aragon/client#27

I want keep some aragon.

Blocked by #13

Think about whether we want per token budgeting or convert it all to one currency and denominate in that one (better UX)

If we go the one currency route:

• Initial implementation will need an oracle to feed token prices in
• Ideally will rely on 0x for price discovery when it is ready

Blocked by almost every major issue for the v0.4 millestone.

With the new architecture building an organization is almost as doing a LEGO puzzle.

We should work on a factory that with 1-3 transactions sets up all the needed contracts for the organization with some sane defaults, as the current CompanyFactory works in v0.3

Similar to how organs register the payload size some functions return, we could replace the current functionality that requires the DispatcherOrgan to make a static call to every Organ (600 gas * organ length for worst case scenario, aka, ApplicationOrgan).

The idea is that when installed organs would register in global DAO storage their intent to handle a certain payload. Problem is, we can only save and check against function signatures so this could work. Another solution could be to register to be called for a certain function signature instead of dispatching it directly.

Submitting another idea: what about having a polling application similar to votes but with more choices than just yes or no?

We need to add events for DAO actions in order for elements interacting with the DAO to be aware of critical changes. Events are needed for:

• InstalledOrgan
• InstalledApp (probably could be merged in one event with a boolean on whether it is an organ or app)
• KernelChanged
• DispatchedPreauth

VaultOrgan events should be added to this DAOEvents class.

Right now all bounties have to be manually funded sending ETH to the bounty contract address.

It would be great to have a Github bot listening to bounty issues that could allow maintainers to automatically fund the bounties.

Just reserved the @autobounty github username for it.

Example:

@autobounty standard bounty

@autobounty 1 ETH

And it will send the ETH to the bounty address in the issue.

Work on default contract used to execute votings

As outlined in #59:

An error occurred while running the linter on /home/quazia/Sites/quazia/aragon-core/contracts/kernel/Kernel.sol:
Error: An error occured while parsing the source code:
SyntaxError: Expected "=:", "hex", "let", "{", "}", comment, end of line, number, string, or whitespace but "r" found. Line: 108, Column: 17

Unit tests for BylawsLib are failing because Solidity is failing to link the lib to the test.

https://travis-ci.org/aragon/aragon-core/builds/242547229?utm_source=github_status&utm_medium=notification

This locked #11 for a day, then decided to remove it from the PR.

Bylaws app is compiling and should be ready to work in the current system.

Integration needs testing and unit tests to ensure the bylaws app does access control for the DAO.

With the changes introduced in #1 related to storage, DAOMessage can no longer be saved the way it was. It could be saved as storage or other solutions could be thought.

The requirement is to maintain the DAO calling context as we move through different organs via delagatecalls and being able to pass this context to the applications.

Implications related to reentrancy and DAOMessage not being changed need to be properly thought.

Blocked by #17

Take advantage of the comments in #63 to build a pretty good source-code generated documentation

Candidate: https://github.com/DigixGlobal/doxity

Should resolve #17

Keep it basic as current implementation.

Relative majority -> minimum quorum.

Dividends workflow:

• Create dividend sharing contract and transfer to it all the tokens that is going to share.
• Contract will do a clone of the token at that block height.
• When a holder calls the contract collect() function, his tokens get burned and gets a proportional share of all assets being shared (be careful with the rounding! https://medium.com/@weka/dividend-bearing-tokens-on-ethereum-42d01c710657)

Introduce a new Bylaw type: CombinatorBylaw that allows for a bylaw to pass if a certain condition among two bylaws is met.

This will allow for having multiple apps or parties that can perform an action.

Example of a complex bylaw:

Blocked by #17

@jbaylina did a spike related to this, but I cannot find it right now.

The challenge is to keep the list of who delegates on who in a way that voting doesn't require any for loop interations (that would be hard to scale because of the gas limit).

I think this can be achieved in the case where the organization is the Minime token controller of the token and the delegation balances can be modified with every token transfer (using the 'onTransfer' callback).

Hi,

The file npm-shrinkwrap.jon contains characters of a failed merge (<<<, HEAD, >>>) and npm install command fails to download dependencies.

Regards,
Mauro.

Work on very basic migration that kickstarts a default org (placeholder for a proper factory contract)

Implement the logic for the organ that handles ETH and tokens being transferred out of the DAO.

A good starting point is Giveth's Vault contracts: https://github.com/Giveth/vaultcontract/blob/develop/contracts/Vault.sol

We need to add a way to revoke token grants that returns tokens to the DAO.

Base implementation for a complex revoke: https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/token/VestedToken.sol#L74

Vitalik's idea to create clone contracts

Some events are in the past tense (e.g. KernelReplaced) and some are not (e.g. Register and Deregister). Making them all in the same tense would be nice.

Blocked by #17

Unit tests are needed to cover:

Kernel:

• Vanilla ETH transactions (when ETH gets wrapped into the EtherToken)
• Presigned ETH transactions (test payloads are non-reusable)
• Token receivers (ERC223 and approveAndCall compatibility)

Dispatcher organ:

• Not dispatching when action is not allowed
• Not dispatching when no organ can perform the action
• Dispatching to an app and checking app is sandboxed