Improve Bounties and Child Bounties Deposit Logic

[shawntabrizi]

It was suggested that the deposit logic for Bounties and Child Bounties was not flexible enough.

Specifically:

• If a Bounty paid no fee, it would have no deposit requirements.
• If a Child Bounty had a huge value, it could end up for a huge deposit for the end user.
• If a Child Bounty curator was also the parent curator, they were being asked to put an additional deposit down.

To solve this, we refactored the logic around calculating the curator deposit into its own function, and put a little bit of simple logic in there to handle different situations.

For Bounties:

• The curator deposit is always a multiplier of the curator fee.
• The curator deposit has an optional upper and lower bound to ensure the value is never zero, and never too high.

For Child Bounties:

• If the parent curator is the same as the child curator, then no deposit is taken. They already have a deposit on the main bounty.
• Otherwise, the logic is exactly the same, and actually uses the bounties function directly to calculate the deposit.

The multiplier and limits are all configurable in the runtime.

New tests ensure each of these different scenarios are handled correctly.

polkadot companion: paritytech/polkadot#5183

[xlc]

I think this should be voluntary curator friendly that when curator is doing voluntary work, they shouldn't need to lock deposit from their own pocket?

Otherwise we simply require a minimal curator fee so that is ok to ask curator to lock deposit which will be compensated later.

[shawntabrizi]

Can you make a specific suggestion?

For example, the NoFee multiplier can be set to zero to support actually 0 fee from the curator.

[xlc]

I just don't find this useful. If we are not going to set NoFee to a non zero value, this code will be redundant and I don't think we want to set it to a non zero value.

What value are you going to pick anyway? The Polkadot Pioneers Price is 993286 DOT, so if you make it 0.1%, the deposit will be 993 DOT, which is still a big number for curator.

But for 10 DOT (the current minimal bounty value for Polkadot), 0.1% will be 0.01 DOT, which is less than ED.

[xlc]

What I want to see, is a maximum value for curator deposit. Similar to the treasury proposal deposit. That ensures the deposit won't be too large for some large curator payout. e.g. for the ORML security bounty, the curator fee will be 10% of the payout, which can be large if the payout is big.

[michalisFr]

I agree with @xlc that there should be a cap on the curator deposit of a couple hundred DOT. For cases when the fee is zero, the percentage I proposed for the deposit was 1%, which for a 20000 DOT bounty would be 200 DOT, which I think is reasonable to be the cap as well.

IMO the fee should be zero only when the curator is part of an organisation and they're doing it as part of their job. In those cases the organisation can front the deposit. Otherwise community members should get rewarded for their efforts.

But we do need a deposit. Otherwise a malicious curator could set a zero fee in order not to place a deposit and then take advantage of the fact the have nothing to lose.

[nuke-web3]

Related: paritytech/polkadot-sdk#1141 #11053

[xlc]

The min/max bounds implementation looks good to me.

[shawntabrizi]

Thanks for the feedback @xlc. Things should be up to date now, and pretty straightforward.

The only other thing I did here was remove the redundant configurations from child bounties, since I don't think they should really ever be different from the parent bounties itself.

[ggwpez]

Looks sane to me, I think we should wait for approval from @xlc as well.

[shawntabrizi]

bot merge

[paritytech-processbot]

Error: Approval criteria was not satisfied in paritytech/polkadot#5183.

The following errors might have affected the outcome of this attempt:

Merge failed. Check out the criteria for merge. If you're not meeting the approval count, check if the approvers are team members of substrateteamleads or core-devs.

[shawntabrizi]

bot merge