-
Notifications
You must be signed in to change notification settings - Fork 131
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
Implement new pre-propose interface and support native deposits in cw-proposal-single #481
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK: Gave it a quick pass with the smoothest brain possible...will need to revisit a few things tomorrow, especially the test coverage. Feel free to ignore...everything
Codecov ReportBase: 93.62% // Head: 94.40% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #481 +/- ##
==========================================
+ Coverage 93.62% 94.40% +0.78%
==========================================
Files 34 36 +2
Lines 3480 3361 -119
==========================================
- Hits 3258 3173 -85
+ Misses 222 188 -34
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
dang. code coverage isn't telling us much here. this file, for example is described as being 83% covered, despite having 100% coverage by visual inspection. |
bbd0be2
to
f309560
Compare
9b2b12f
to
09f67cd
Compare
2b10979
to
e7e3ad6
Compare
Cosm-Orc Gas Usage
Raw Report for e7e3ad6
|
gas cost increase in instantiation is due to the addition of a new module which adds another |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My rather colloquial review on the bird app: https://twitter.com/bmorphism/status/1578923792071815168 really excited for V2! |
This PR implements a new pre-propose interface on cw-proposal-single. The
pre-propose interface gives proposal modules the ability to delegate permission
to create proposals to a different contract. If one is present, only the
pre-propose module associated with a proposal module may create proposals.
In order to allow pre-propose modules to take actions like refunding proposal
deposits, pre-propose modules receive proposal hooks from their associated
proposal module. Proposal hooks fire when a proposal is created and when its
status changes. Like other receivers of proposal hooks, if the pre-propose
module fails to handle a hook message and errors it will be removed and the
proposal-module will fail-open by allowing any address to create a proposal
after the failure.
In summary, when a pre-propose module is associated with a proposal module:
The pre-propose interface.
Pre-propose modules are only required to implement the following execute
message:
The semantics of how a proposal is created and are left up to individual
modules.
Deposits
The initial use case for these pre-propose modules is to allow for more complex
proposal deposit systems. To this end: this PR builds on Jake's previous
work and adds support for
native token proposal deposits, in addition to retaining support for cw20
deposits.
cw-pre-propose-base
Proposal deposit logic is currently identical across the
cw-proposal-single
and
cw-proposal-multiple
proposal modules. Thecw-pre-propose-base
packageintroduced in this PR implements this shared logic in the form of a pre-propose
module that may be extended to support the proposal semantics of a particular
module. The design of this base contract is based on and shares many
similarities with
cw721-base.
The
cw-pre-propose-base-proposal-single
contract added in this PR extends thiscontract to support
cw-proposal-single
proposal messages, and thecw-pre-propose-base-proposal-multiple
contract put together by Jake in thisPR does the same thing for
cw-proposal-multiple
.Here is a flow chart of the proposal creation process with
cw-pre-propose-base
:In addition to the logic described in that flowchart, the module also supports
updating it's configuration, and the DAO withdrawing deposits via the following
executed messages:
Some important behaviors of this module to note:
create, it will do nothing and not fail the transaction. This addresses the
case where this module has replaced an existing module and there are
outstanding proposals.
module will not change deposit information for in-flight proposals.
Proposal Module Changes
Proposal modules are largely not impacted by these changes. The existing
proposal hook system (though slightly modified) is used to feed updates to
pre-propose modules.
There are only three changes to the
cw-proposal-single
interface.InstantiateMsg
is replaced withpre_propose_info
which allows instantiating a pre-propose module as part of the proposal
module's instantiation.
proposer: Option<String>
field is added to theExecuteMsg::Propose
variant. If a pre-propose module is associated with the proposal module, it
is expected that this is
Some(address to attribute proposal creation)
. Ifno pre-propose module is associated, this field is expected to be
None
. Inthis case the proposal module will fill in the proposal's proposer with the
sender of the message.
ExecuteMsg::UpdatePreProposeInfo
message variant is added whichallows the DAO to update its pre-propose module.
Notably, if the DAO swaps out a pre-propose module, the old module will stop
receiving proposal hooks. It is expected (and covered in tests) that, in this
case, the DAO will executed the
Withdraw
method on its pre-propose module andreimburse proposers of in-flight proposals who would otherwise not receive their
deposits as a result of the pre-propose module holding them no longer receiving
proposal hooks.
If you've made it this far, thanks for reading and taking the time to review my
PR!