AGP discussion: Community Funding DAO

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

1 Like

Hey, thanks for the note.

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:
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.

1 Like

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.

1 Like

Great to hear. As it is now March 18th, can you share a link to the DAO here so we can start submitting proposals? :slightly_smiling_face:

1 Like

The org has been deployed here :tada:

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.

EDIT: The vote to make proposal submission public is now active


Thanks a lot Luke.

The funding should be incoming:


This seems redundant as ANT holders have already approved setting the DAO so that any ANT holder can create proposals. As deployed, this does not fit the spec defined in AGP-10.

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.

1 Like

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. :man_shrugging:

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. :slight_smile:


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%
Support: 66.6666666666666666%
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 :wink:)

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! :grimacing:) 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 :money_mouth_face:


@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...?

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:

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?

1 Like

@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

1 Like