You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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).
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 proposalvote
- express support or opposition to a proposalreject
- delete a proposal if there is sufficient oppositionaccept
- 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 completeDesign comments;
execute
can be used to make structural changes to the DAO e.g. change in voting membershipexecute
can potentially feed to another DAO, e.g. a sub-committee forwarding a proposal to the full committeeA DAO with maximum flexibility could use
eval
oreval-as
for the execute function. More constrained DAOs may have more limited capabilities.The text was updated successfully, but these errors were encountered: