-
Notifications
You must be signed in to change notification settings - Fork 115
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
Withdraw funds from bounty. #2160
Withdraw funds from bounty. #2160
Conversation
# Conflicts: # runtime-modules/bounty/src/lib.rs # runtime-modules/bounty/src/tests/mod.rs
I did not understand this question, could you restate?
If we have no caps on active bounties overall, then I see no need for such a limit. |
/// A bounty funding was successful on the provided block. | ||
max_funding_reached_at: BlockNumber, | ||
/// A bounty reached its maximum allowed contribution on creation. | ||
reached_on_creation: bool, |
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.
Why is reached_on_creation
needed? I see it only read here
cherry_needs_withdrawal: reached_on_creation && cherry_is_not_zero,
but it's also not clear this field is needed, or why it depends on anything except cherry_is_not_zero
.
/// The stage is set when the funding exceeded max funding amount. | ||
MaxFundingReached(BlockNumber), | ||
/// Creator funds (initial funding and/or cherry) were withdrawn. | ||
CreatorFundsWithdrawn, |
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.
Why is there a distinct extrinsic and thus milestone for withdrawing funding? All there is is bounty cancellation?
See design doc
The creator can cancel at any time before this, something that is of particular importance of in perpetual funding periods. If no one has contributed, any cherry is returned and the bounty is instantl removed, but if at least one contributor has funded, then the cherry will be split amont all contributors, and the bounty goes to the withdraw period.
So cancelling a bounty covers possible recovery of bounty contributed, if relevant. Right now you have two separate extrinsics and milestones. I am not actually sure you even need two Canceled
and CreatorFundsWithdrawn
even if we wanted two separate extrinsics, as the runtime should do the exact same thing going forward in both cases?
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.
Overall benchmarking looks great, just left one minor comment and one important question.
|
||
assert!(Bounties::<T>::contains_key(bounty_id)); | ||
|
||
Bounty::<T>::cancel_bounty(RawOrigin::Root.into(), creator.clone(), bounty_id).unwrap(); |
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.
Can we add an assertion after this that the stage is BountyStage::Withdrawal
with cherry_needs_withdrawal == true
? (The same for the other benchmark for withdraw_creator_funding
.)
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.
Ok
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.
LGTM
Changes
withdraw_member_funding
extrinsicwithdraw_creator_funding
extrinsicImplementation comments
withdraw_member_funding
orwithdraw_creator_funding
extrinsics. The actual removal occurs when all possible withdrawals are completed.Open questions
Main issue