I had asked @anteater if he was interesting in collaborating with the cooperative on the community funding/dao specifically for the purpose of whitelisting proposers. The thinking being having a whitelist of proposers tied to forum identities would be both sufficiently open and provide a sufficient deterrent against spam (since you have social reputation at stake and can be removed from the coop if you don’t act in good faith). However, my understanding is that such a solution is not really in the spirit of the AGP.
@jorge proposal I think offers a more complicated and potentially more expensive solution but one which feels a bit more in the spirit of the AGP.
Regardless, I agree that it may be best to simply launch the thing with the expectation that one of the first proposals will be be to transfer funds to a more secure organization. This notion was discussed a bit with @anteater on rocketchat wrt making changes to the community funding DAOs governance and it seems reasonable to simply make a community funding proposal for all the funds to fund a new community funding dao with a different governance process.
It would seem that if the intention is to prevent attacks that drain the DAO, then putting the tokens that are intended as spam prevention in the Vault doesn’t really help because the attacker knows they can get their tokens back if they succeed at draining the Vault. Burning seems to be the best way to make it truly costly to attack the DAO.
It might be not in the spirit of this proposal but perhaps it could work for a v2, especially if the more “open” nature of the AGP-10 DAO is clearly the wrong approach and burning or whatever more “anonymous” spam-prevention mechanism we come up with also doesn’t work for whatever reason.
I will admit I did not think of this when I proposed the DAO. But it’s an interesting experiment to see what the community comes up with to patch this weakness. I don’t have a good answer, tbh I was hoping this naive implementation would “just work”. But something like the burn you suggest could be a second-best option since I think it preserves the “spirit” of the open/ permission-less-ness of the DAO. I would like to see that or similar ideas to prevent spam tried before resorting to a white-list curation mechanism like using the Coop DAO to pre-approve proposals.
To be clear though I do want to see the DAO implemented the naive way, if only to make a point, and then we try to fix it by moving funds with a proposal in the first week to a safer DAO. If we find a good alternative we can amend AGP-10 and if there is no good solution we can scrap it until a better way to protect against spam proposals in “open” DAOs like this exists.
@jorge@luis a reminder that per AGP-10 the Community Funding DAO is due to be deployed and funded by March 17th, about 10 days away and the Aragon Association is responsible for ensuring its delivery. Should we expect it to be deployed on time?
Purpose of the transfer
To fund a Bounty DAO that will be created by the Aragon Association or Flock team designated by the Aragon Association. The Bounty DAO shall be created and funded within two months of this AGP being approved by ANT holders (due date March 17, 2019).
Hey @anteater! I think something to improve from the AGP process is to have clear ownership of action items.
Initially I thought that the Association should be the one taking on this, but then I realized it’s probably the AGP authors, since the Association carrying each AGP itself could expose it to more liability. Curious about @stefanobernardi’s take on this
We’re a bit delayed, given that at this time there is only myself at the Association level, and we had some more timely matters with the Flock teams and other substantial transactions for other AGPs.
That being said, yes, we definitely expect it to be deployed in time.
To @luis’s point, I also think the responsibility for making sure the AGPs get executed should rest on the AGP submitter, while the AA retains the responsibility of getting it all approved, executed and making the necessary transfers in a timely manner.
The main reason for this is that the AA is not in control of the amount of things that are going to be asked of it in AGP proposals, and the team will be small, so I’d suggest, in order to make sure everything gets completed fast to minimize the load.
That being said, that should probably be also reflected in the AGP’s proposal wording itself and in this one it’s the AA that needs to create the DAO, or delegate. So that’s what will happen.
We’ll try to make it more clear in the AGP process as well
In light of the fantastic work of @stellarmagnet and the entire Planning Suite team have undertaken IMO it would make sense to push this back to late Q2/Q3 and to simply use the finance app to set up regular payments to the planning suite bounty app where any ANT holder could vote according to their token weight. After some time this could switch to a system where previous bounty contributors vote according to the reputation they accrued (a sort of bounty guild). More ideas could be found reading the Planning Suite WP: https://docs.google.com/document/d/192hg6lUoePoWh_zR2uCyIHcw7TYH4gEc7CoUMZ1lkl8/edit#
Once we have monolithic/multiple contracts app the bounty DAO could combine finance/vault/planning suite together for a smooth experience.
Regarding spam prevention could proposers be required to deposit an amount of tokens proportional in value to the requested budget with slashing for bad behavior? Where the deposit is longer than the proposal voting period in order for the DAO to vote slashing retroactively if it detects abuse in the following weeks/months.
As this was approved via AGP and the AGP specified that the Association must deploy by March 17, pushing this back is not an option. Maybe what you describe could be implemented and this v1 DAO could switch to that later.
It is configured as specified in the original AGP with the notable exception that at the moment only my address and the Association Multisig can create proposals. As discussed earlier in this thread adding the ability for any one to submit proposals would potentially allow the organization to be spammed with proposals, with each proposal requiring action on behalf of a ANT holders to block. After I post this I will create a vote to add the “Create Votes” permission to “Any Entity” – This change would align the organization with permissions specified in AGP10.
This gives ANT holders the opportunity to approve or reject the permission change.
If it is approved, then anyone will be able to submit proposals and the point at which proposals can be publicly submitted will be related to when that initial vote duration ends.
If it is rejected, we would need to determine some other legitimate proposal submission process.
Given that ANT holders would need to approve of each proposal in the public process, and the first proposal could simply move the funds to a more secure organization.
ANT holders would need to confirm the intention of the organization/permissions either way, so this seems like a reasonable way to address the situation in the spirit of the proposed AGP and does not create an awkward information asymmetry associated with deployment where the time in which “public” proposals would begin to be accepted would be known privately before it was known publicly.
I understand the intent. We could have reduced the asymmetry by simply announcing here when the DAO would be deployed. And though a subtle difference, I would still prefer to see it implemented so that only ANT holders can create proposals vs any entity at all. I feel strongly that the DAO should have been implemented as specified.
And though a subtle difference, I would still prefer to see it implemented so that only ANT holders can create proposals vs any entity at all.
This is not something that can be done with Aragon’s current functionality and would requires custom code. If you think this distinction is significant I would suggest opening an issue. The way you would accomplish “only token holders can perform an action” would be to grant the token manager of a token the permission. However, a token manager cannot be initialized for an existing token unless the token manager is set as the MiniMe token’s Token Controller. This could certainly be worked around if development resources were allocated to address it… however it seems problematic for the operation of organizations such as flock teams/the association which have specific roadmaps and budgets associated with their operation to have AGPs divert dev resources to underspecified initiatives.
The way that the AGP was written it is ultimately up to the discretion of the Association to how to launch the organization, and in this case the trigger to launch the organization as specified has been delegated back to ANT holders.
To help reduce this ambiguity for future AGPs I would strongly advocate for future finance track AGPs to not include activities above and beyond sending funds to an existing address.
Ultimately, I think there are lots of lessons to be learned from AGP10 and very happy that its approval has resulted in the community confronting some of these issues head on.
I feel bad about not catching this in the review! Yes, another lesson learned. I take it then that it’s not as easy as assigning the “create vote” permission to the ANT contract address?
To be fair to the AGP-10 author I thought the organization’s set-up was well-specified:
The Bounty DAO shall be created and funded within two months of this AGP being approved by ANT holders (due date March 17, 2019).
The basic parameters of the Bounty DAO are:
Token: ANT (0x960b236A07cf122663c4303350609A66A7B288C0)
Vote duration: One week
Min. Quorum: 0%
Apps: Voting, Finance, and all default apps, configured so that only ANT holders can vote and create votes, and all Finance transfers require approval by the Voting app.
Maybe the part about only ANT holders being able to create votes is more difficult than anticipated, but the rest seems straightforward enough and the current way it’s been deployed seems an unnecessary departure from the spec.
That said I appreciate the effort that went into creating the current implementation of the DAO. I just feel it’s important to encourage AGP implementers to stay as close to the specs approved by ANT holders as possible, for the sake of good governance and to preserve the legitimacy of the process. I’ll step aside and let others share their thoughts on this, if anyone else has an opinion about it.
The way it works with the token manager is that the token manager implements a forwarder interface which can be used to forward actions by anyone who has tokens. Since the Minime token contract doesn’t implement a forwarder interface assigning permissions to it would not help. It should be trivial to implement an application that implements a forwader for a token without being the token controller though, the implementation of the forwader is not dependent on being the token controller as far as I know, we just don’t have an application currently other than the token manager that implements that behavior.
It would be quite useful to have a generic Token Forwarder app that would provide this functionality, and it likely would also be trivial for that application to implement some configurable constraints such as a required token balance or percentage of token supply in order to forward actions. (Perhaps a good candidate for a community funding dao proposal )
Same! I also feel bad for not catching this prior to the vote or providing better feedback prior to it being finalized.
I think the main reason I would consider this underspecified with regard to the finance track requirements is because an address for sending funds was not specified (it was left tbd).
As far as I am aware there is nothing in AGP-1 which specifies the role of an “AGP Implementor” nor any authority of the process to make anyone arbitrarily perform work outside of the specific scope of the AGP tracks. The finance track proposals sort of work in that regard as you could exchange funds for some service being performed, but the AGP-1 process assumes that it is the AGP submitter or some designated party who is contracting with the AGP submitter who is responsible for implementation.
For this reason AGP10 proposal probably should have been stopped by AGP editors (my bad! ) before even being put to a vote for that reason. It may be reasonable to create proposals which require the association to implement as the association review step allows them to acknowledge that responsibility and reject at that stage if necessary… but as currently written I don’t think the finance track accommodates that.
However, I think this is a larger conversation related to a meta-track AGP that perhaps deserves its own thread?
It seems fair to implement as-is given the technical difficulty of making it so only ANT holders can create proposals. Though “vote to change permissions” would not have been how I would have deployed the organization if I knew how (time to learn!) @lkngtn makes a good point that since ANT holders could vote to move the funds to another organization anyways, functionally speaking this is not much different than how it would have looked if it was deployed “to spec”. And we can consider it an innovative “fair launch” technique on his part.
Despite these cosmetic differences I consider agp10.aragonid.eth to be a legitimate implementation of the DAO described in AGP-10 and hope other ANT holders will too! Now go vote to activate it to we can start making proposals
@lkngtn is it possible to see which token contract was used for the Voting app? I can see in the Permissions app that the token is called “ANT” but is there a way to know just by looking that this ANT is the same ANT as contract address 0x960b236...?