Dissent Forwarder App

[yeqbfgxjiq]

The dissent forwarder allows Aragon organizations to allow actions to be taken only if the address has voted no or abstained from the most recent vote. The goal here would be to use with the redemptions app, so that you are only able to exit if you have not voted yes recently. It basically means that by voting yes on a proposal you are committing to the decision.

• Status: not under development

@lkngtn

• The main reason this is relevant is that it ensures that people who dont vote for a proposal can exit (via redemptions), before those who voted for the the proposal are able to. I agree that deposits, dissent, delay are less important than redemptions/token-request, but they are important if we want to be able to frame the kit as "moloch" on aragon.

@burrrata

• I support this. Seems important to align incentives properly.

@0xGabi

• from reading the comments on HackMD it sounds like you generally support development on this app too?

[yeqbfgxjiq]

Open Questions For All BEEs 🐝

• Is this something we would want to work on?
• Do we agree that these apps are simple and straightforward to develop?
• What is the expected scope and a reasonable timeline given our resources and other commitments?

[0xGabi]

Yes, I support this app but in a second order of priorities over Redemptions and Token Request apps

[willjgriff]

• Is this something we would want to work on?

This would be interesting to work on and seems fairly crucial if we're trying to emulate Moloch.

• Do we agree that these apps are simple and straightforward to develop?

The UI, if necessary, would be minimal with a function to update the Voting app address it uses.

To support the Redemptions use case, this would require the Redemptions redeem permission only be given to an address that implements the dissent forwarder. I believe this would require modifying the current Redemptions app to not use msg.sender in the redeem function which means any DAO using the Redemptions app without the forwarder would have to set permissions with params (the param being what was msg.sender).

I don't envision many unknowns.

• What is the expected scope and a reasonable timeline given our resources and other commitments?

With my experience working on Aragon apps independently of a team I estimate about 2 weeks for one developer for a basic functional version.

[lkngtn]

I believe this would require modifying the current Redemptions app to not use msg.sender in the redeem function.

Agree I think we should have a role for calling the redeem function. This should be pretty simple I think?

which means any DAO using the Redemptions app without the forwarder would have to set permissions with params (the param being what was msg.sender

If there is a role, then the permissions app has a built-in UI for configuring the permission to allow "any entity" to perform the role. However, we should also consider the scenario where the role is assigned to another forwarder (eg dissent, or even a token manager), and make sure that despite going through a forwarder we are interacting with the users account when burning tokens and distributing vaultTokens.

[0xGabi]

This might also be great opportunity to extend aragonCLI dao acl create command to include parameters