AGP discussion: Community Funding DAO

I am a bit worried about spam prevention for proposals in this DAO.

From the approved AGP text:

configured so that only ANT holders can vote and create votes,

The part about ‘only ANT holders can create votes’ seems scary IMO as you could purchase 10^-18 ANT (which technically makes an account an ANT holder) and spam the DAO with an infinite amount proposals to withdraw all the funding from the DAO. There are very high chances that one of such proposals would pass because no one would be motivated to vote no, specially since there is a tragedy of the commons scenario to vote no (no direct upside), and the attacker potentially can get all the funds in the DAO if one of the proposals isn’t rejected.

I propose adding a spam prevention mechanism by requiring to burn x ANT in order to create a proposal in the Bounty DAO. This amount of ANT could be small, just to justify the cost to all ANT holders for their attention to vote no on bad proposals.

Wrote the code for it in 10 minutes using ANT’s approveAndCall, so only 1 transaction is needed. The calldata of the newVote function would need to be sent in the ANT approveAndCall transaction. The permissions in the DAO would be set so only the BurnToPropose contract can create new votes.

If we already had Triggers this could have been done using the UI directly :wink:


I generally agree with @jorge here that an anti-spam mechanism is critical, though a strict reading of the AGP would suggest that no such mechanism should be implemented as it was not specified in the proposal…

I will say publicly that I personally planned to spam the organization with proposals to force the issue of implementing a more secure proposal process… With the anticipated result that spam proposals would be voted down until a proposal which transferred funds to a more secure organization was proposed and successfully executed. :upside_down_face:

So perhaps we can bend the rules just a bit and just deploy a more secure proposal process from the start?


The optimal amount seems tricky to find. The cost would have to be at the intersection of “number of attack proposals that ANT holders will be willing to vote down”, “number of proposals I can afford to spam before it’s not worth it”, and “not prohibitively expensive”.

And a general comment, not aimed at anyone in particular: it’s good to have this feedback early on but it would have been nice if it came up before the DAO was actually approved. Let’s try to get critical feedback like this in before proposals are finalized. The AA review would have been another opportunity to reject this proposal in favor of one with a quality filter mechanism.

I don’t like the implications of bending the rules here and think the will of ANT holders should be implemented as strictly as possible. If it results in a lesson being learned, so be it! (That said I’m generally supportive of creating a funding DAO proposal to move all funds to a more secure DAO asap, we can then patch AGP-10 with the new DAO address as the funds recipient in the next AN Vote.)


I totally agree @light, we need to push for more critical feedback before the vote even happens. I still think that whoever wants to attack the DAO for their own benefit has a higher incentive to attack it (spending more ETH in gas) than whoever decides to attack it to defend it. It will be a fun experiment anyway, and I plan on deploying a DAO with the burn-to-propose mechanism so anyone can create a proposal to this DAO to migrate the funds to the other one.

In order for this to be fair, the exact date and time in which OG Bounty DAO will be deployed needs to be known in advance so everyone has a fair chance to attack the DAO.

I think a simpler heuristic would be the relation between the burnt amount and the maximum amount of funds that can be pulled from the DAO. I think 1/100 or 1/200 would be a fair amount to burn as having someone voting NO to 100 or 200 proposals doesn’t seem too crazy to me. Voting down 200 proposals would cost around 2 blocks worth of gas, which at today’s prices you can do for less than $10.

1 Like

Ha, yes we can make it a “fair launch” and announce the date here a few days ahead of time at least :wink: cc @lkngtn

That’s true, but at ~15 second block time per vote it is also almost one hour of work (sign, submit, wait for confirmation… sign, submit, wait for confirmation… etc.) to reject 200 proposals. We should also take into account that whatever burn amount is chosen, honest proposers will likely bundle it into the cost of their proposal. Which makes the burn mechanism a bit capital inefficient (and increases the incentive to ask for larger amounts of funding, to reduce the amount of DAO funding spent per quarter reimbursing burn costs).

In the interest of capital efficiency (and perhaps simplicity) maybe for v2 of this DAO the Aragon Cooperative could assume the same role as the quality filter for proposals that the Association board does for Aragon Network proposals?


That’s true, I was assuming that whoever would do this would use a ‘smart contract wallet’ to batch all the calls into a big transaction that can vote No to ~100 proposals. However this would not really fly since people will likely have their ANT in a regular account by the time the malicious proposals are created.

This is making me think that it would be really convenient to add multicall functionality natively to aragonOS 5 (which would allow batching calls in any Aragon app while still using a regular EOA), as we are discussing adding to Staking (cc @bingen @sohkai):

Although by burning you distribute the ANT to all holders, maybe it would be more efficient to send the tokens to the DAO’s Vault rather than burning them, so the money stays in the DAO cc @lkngtn.

If we really wanted to we could implement deep EVMScript inspection and have the burned amount be a function of the money being requested, although this could require involving price feeds.

This sounds reasonable, although I kinda like how decentralized and anonymous this DAO would be if we manage to prevent spam without curation.

1 Like

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.

1 Like

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

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.