Convex Generic DAO

[mikera]

Convex provides highly dynamic capabilities for DAOs. In particular, the on-chain compiler makes it possible for proposals to be compiled at executed by the DAO itself!

Key functions:

• propose - add a proposal to the DAO, typically in the form of a vector of execution parameters and some metadata describing the proposal
• vote - express support or opposition to a proposal
• reject - delete a proposal if there is sufficient opposition
• accept - execute proposal if there is sufficient support (over any opposition)
• execute - run proposal using the vector of execution parameters.
• dispose - delete proposal after everything is complete

Design comments;

• execute can be used to make structural changes to the DAO e.g. change in voting membership
• execute can potentially feed to another DAO, e.g. a sub-committee forwarding a proposal to the full committee

A DAO with maximum flexibility could use eval or eval-as for the execute function. More constrained DAOs may have more limited capabilities.

[helins]

What was the incentive for having both accept and reject Vs a unique finalize function?

[mikera]

I guess separate accept and reject are more explicit about what you expect the result to be. A finalise transaction could (in theory) be vulnerable to a front running attack that changed the result, so the caller might end up accepting a proposal that they intended to reject. Which might be a big risk if security depends on only certain people having accept/reject privileges.

[helins]

I'm not sure I can picture the front running concerns 🤔

In my current design, there is a result function which stops the voting process of a proposal if the voting library associated with that proposal can produce results given its voting state. Voting results mean that voting is done (otherwise, one couldn't produce definitive results). At this point, things have been set in stone by the voting process and that's it. Which obviously makes sense, what's the point of a voting process if someone can somehow change outcomes after voting.

If a proposal has voting results attached, anyone can finalize (hence execute) it. Even someone external to the DAO. Things have been decided, cannot be changed, so I don't see a point in restricting execution at this step.

result and finalize are separate for clarity but in theory they could very well be bundled in a single function.

[helins]

Ah yes, maybe it isn't clear: rejection is part of the voting choices. The propose function must enforce this depending on what execute considers to be a rejection (e.g. nil choice if execute does eval).