Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convex Generic DAO #434

Open
mikera opened this issue Nov 22, 2022 · 4 comments
Open

Convex Generic DAO #434

mikera opened this issue Nov 22, 2022 · 4 comments
Assignees
Labels
enhancement New feature or request question Further information or discussion is requested
Milestone

Comments

@mikera
Copy link
Member

mikera commented Nov 22, 2022

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.

@mikera mikera added enhancement New feature or request question Further information or discussion is requested labels Nov 22, 2022
@mikera mikera added this to the V1 milestone Nov 22, 2022
@helins
Copy link
Member

helins commented Dec 19, 2022

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

@mikera
Copy link
Member Author

mikera commented Dec 23, 2022

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
Copy link
Member

helins commented Dec 23, 2022

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
Copy link
Member

helins commented Dec 23, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information or discussion is requested
Projects
None yet
Development

No branches or pull requests

2 participants