Dandelion User Testing & Feedback

Hi!

We are excited to share the work we have been doing on Dandelion, an Aragon organization template and set of apps that is inspired by the Moloch DAO mechanism design. If you are interest in being an early tester and providing feedback before our mainnet release please continue reading! :)

If you haven't already done so, I recommend reading our the Dandelion overview post, which explains the how the different apps work together and how the overall template compares to the original Moloch design.

To facilitate testing on rinkeby we have created a shared testing org, as well as an onboarding flow for creating your own org on rinkeby.

In order to test you will need some Rinkeby ETH, you can get some using the Rinkeby: Authenticated Faucet, or simply hop on our keybase and I can send you some. You will also need to make sure your web3 provider (eg metamask) is connected to Rinkeby test network.

Step 1: Creating a test organization

Navigate to preview.1hive.org and select create new organization. Scroll through the available templates until you find the Dandelion org.

You'll need to provide some details related to the parameters of the applications. Most of it should be self-explanatory, but if you find anything confusing please make a note and share with us.

You will be prompted to provide a payment token to use with the Lock app, Token Request app, and Redemptions app. Since this is on Rinkeby you will probably want to use a standard test token that can easily be acquired by yourself or other members of your organization. You can get "test" ANT and DAI at the test token faucet provided by Aragon Black.

For testing purposes I recommend using relatively short durations and a small amount for the base lock amount, as it will be easier to test flows if you don't have long waits in between.

Step 2: Token Request Flow

In order to join a Dandelion org a user must request tokens. This is a multi-step process where a user submits a request and deposits tokens, then an existing member must submit the request to the voting queue. If accepted the deposit will be transferred to the vault and there requested tokens will be minted for the user.

You can try this process out, including some specific edge cases, if a user submits a request, they can withdraw their deposit at any time, but if their request is approved, tokens will not be minted unless the deposit is still available to transfer to the org.

Step 3: Creating Votes and Locking Tokens

Only existing members of the org have the permission to create votes, and each time a member creates a vote they are required to lock a configurable number of tokens for a configurable amount of time. Additionally, if a specific member tries to submit another vote while a lock is still pending the amount of tokens and duration will increase with each subsequent lock created.

This is a bit different than the anti-spam mechanism in Moloch but serves a similar functional purpose. Since proposals are processed in sequence, an individual pays an increasing cost the more actions they add to the queue.

As you submit votes, you will be required to lock tokens, you can view the status of your locked tokens using the "time lock" app, and withdraw your tokens once the locks expire.

Step 4: Voting and Redemptions

Similar to Moloch members can redeem their tokens for a proportional share of the organizations treasury, unless they have voted yes in a pending vote.

To accomplish this we have forked the standard Aragon voting app to ensure that votes are processed sequentially with predictable time between each vote, that votes cannot be executed early, and whenever a user votes yes on a proposal the event is timestamped. Additionally we have created an ACL oracle which restricts redemptions based on this timestamp. As a result if you vote yes you should not be able to redeem tokens until that vote has been fully processed.

Known Issues

Currently, the token request app clears some of the data associated with token requests after they are processed. This can result in requests that appear in the voting app display contextual information incorrectly AFTER the a request has been approved. We will be deploying a change to the token request app to fix this in the next few days.
Currently, the token request app lists requests as Pending even after they have been submitted, which can be confusing. We plan to use the proposed Forwarder API developed by Autark to resolve this UX issue, but we are waiting to see when it gets merged into aragonJS.

Providing Feedback

We really appreciate any feedback on the functionality and UX of Dandelion. We have created a repository to gather user feedback, and are also offering Honey tokens as a reward for those who participate and provide quality feedback.

GitHub - 1Hive/user-feedback: User feedback bounties for 1Hive apps

If you experience issues or have suggestions related to specific application, we also welcome you to create an issue in the user feedback repo, or in the relevant application repo. Feel free to also chat with us directly on our public keybase team

1Hive / dandelion-template

Write an user testing guide #18