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?
This is great to see, thank you @lkngtn!
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
Not sure if there is an easy way to confirm that, but you can look at the tx used to initialize the voting app here: https://etherscan.io/tx/0x9c79ce5b72c700893c1723ae8a8d3bbea08a5da4883b7c96c72cb5d532e635e7
The address of the minime token is passed as a parameter and if you parse the data you can see the 0x960b236… address in there.
The Community Funding DAO has been funded, and the vote to allow anyone to create new proposals has passed!
Now anyone can create proposals here:
I have updated the first post with a link to the DAO and a suggested lightweight process for making proposals.
It might be worth making a new post for this, Im not sure that editing the OP will have the same visibility, and a new thread would enable discussions on the process without having to scroll through this whole thread?
@stefanobernardi just a heads up that the Q2 Community Funding DAO payout is currently overdue:
Quarterly transfers with no expiration date, due by January 31, April 30, July 31, and October 31st, respectively
@light thanks for the reminder! AA will take care of that asap.
You’re welcome! You might consider adding a calendar/task reminder a few days ahead of each of the payout due dates if you don’t have one already
We’ll do our best to be timely on these kind of recurring payments in the future . The CFDAO has received the funds https://mainnet.aragon.org/#/agp10.aragonid.eth/0xa9ce3bcd78c3eec38556e4595154d42d56cffaa1
Yes, makes sense, but that would probably mean upgrading to solidity 0.5. See discussion here.