WORKSHOP - As a network operator, I want to experiment with charging a % fee for a bounty that's been fulfilled

[owocki]

ref: Bounties-Network/StandardBounties#42

As a network operator, I want to experiment with Charging a % fee for a bounty that's been fulfilled

Ideally this could be configured on a contract by contract basis (1%, 2.5%, etc) and i would be able to specify a network operator payout address either when the bounty is posted or fulfilled.

It would also be handled in the gitcoin UI.

I understand this addition might not be a welcome change to the Gitcoin system by some community members, but I would ask that community members remember that the Gitcoin project is going to have to earn revenue somehow. Ideally we do it in such a way that

• only sends value to Gitcoin Core when Gitcoin core delivers value
• isnt highly speculative (like a token sale would be)
• is driven by community-principles

related to: #3557

[dolebas]

It would be great to have this as an option in a scheme, as described in #973

If the bounty creator can specify an optional reward to the network operator, it would be experimentally decided by the community what is a fair share.

[vs77bb]

Doing some ideation here below on how this might work. Open to any and all feedback. Keeping Kevin's guiding principles in mind.

• Only sends value to Gitcoin Core when Gitcoin core delivers value
• Isn't highly speculative (like a token sale would be)
• Is driven by community-principles

Proposal

• Build in a x% fee to the Gitcoin Issue Explorer, paid out to a Gitcoin Core wallet upon the completion of a bounty.
• When a bounty is funded, the UX clearly shows the amount in escrow represents a) the bounty amount the hunter will receive and b) the amount Gitcoin Core will receive if the work is completed properly.
• While this model puts the onus on the funder to pay fees, they receive high quality work and only pay for bounties which actually get completed. If they post many bounties, discount packages / subscription models may become available. Hunters do not pay fees and are working in open source while getting paid.

Pages Affected

• On Gitcoin's Fund Issue page, we'll have to update the pricing section.

• Gitcoin's Payout pages (both Basic / Advanced), will have to be updated with a Gitcoin Fee section.

• The Gitcoin Issue Explorer / Bounty Detail pages should not show the full amount in escrow in the Standard Bounties smart contract, but rather the amount the hunter should expect to receive upon payout (i.e. the amount received after the x% fee.

• Anything else?

[frankchen07]

Overarching question from @thelostone-mc:

1. Does this ticket necessitate a change in how the smart contract operates?

When a bounty is funded, the UX clearly shows the amount in escrow a) the bounty amount the hunter will receive and b) the amount Gitcoin Core will receive if the work is completed properly.

1. What would the UX and language of the pricing section look like? For example, if the funder funds a $100 issue, and they want the bounty hunter to be paid out $100 for quality work, and our fee is 5%, that means our pricing calculator has to take that math into account. So does the language need to change to "dollars paid out upon completion ($100 + gas fees)" versus "total amount ($105 + gas fees)".

2. The above would necessitate a pricing page language change that suggests "the bounty hunter, upon successful completion, gets paid out a confirmed amount, and the % fee is collected if and only if the bounty is successfully completed."

3. Perhaps the pop up success rate calculation can be repurposed to a "bounty hunter is paid the USD minus the fee amount".

@PixelantDesign let's jam together on the wording and input box setup.

While this model puts the onus on the funder to pay fees, they receive high quality work and only pay for bounties which actually get completed. If they post many bounties, discount packages / subscription models may become available. Hunters do not pay fees and are working in open source while getting paid.

1. We want to make sure that hunters understand that they do not pay the fee at all, and that the language and math complexity is abstracted away from them, and at the same time, on the funder side, that this language is extremely clear.

2. We need to decide on what % fee is the best, considering that in the future we may have to change it, and that change may cause funder pullout.

Gitcoin's Payout pages (both Basic / Advanced), will have to be updated with a Gitcoin Fee section.

@PixelantDesign, again, let's jam on the pros and cons here.

The Gitcoin Issue Explorer / Bounty Detail pages should not show the full amount in escrow in the Standard Bounties smart contract, but rather the amount the hunter should expect to receive upon payout (i.e. the amount received after the x% fee.

1. This is a good point. Is there requisite backend engineering work on this to make this possible, due to the increased math?

Concern from a data perspective:

1. What is the risk to our growth if we run a test on this - is there an estimate on % active funders that pull out?
2. What unintended consequences are we not taking into account if we run a test on this?
3. What other risks are we not thinking of?

[PixelantDesign]

A few thoughts....

I think it complicates things if we try to include our fee into the pricing calculator.

When I use instacart, fees aren't being added on to each grocery item. They add a fee at the end of my bill. I think this approach is simpler for people to grok. Unless I'm not understanding the reason for including our fees in the pricing estimator. I see the pricing estimator being used to estimate the actual task at hand.

I agree with not showing our fee associate on any visible bounty that a contributor might see.

Great questions on risks and unintended consequences @frankchen07

Is it possible to create a segment of users to run a test with?

I think that all depends on the final number that we land on as a %, based on recent funder feedback I'm thinking we should be in the middle to upper of single digits.

[frankchen07]

I think it complicates things if we try to include our fee into the pricing calculator.

I see what you're saying, and agree with you. So you would suggest there be a separate "fee" section right before they hit the fund issue button, stating that an additional % is tacked on to the total amount, leading to $task + $fee total at the bottom before they hit submit.

segment of users

we could do a mix of active funders, one-time funders, and new funders, and gauge the reaction from each cohort (preferably from ones we haven't interviewed).

middle to upper single digits

agree as well, but will most likely surface during our discussions w/ funder feedback.

Looking forward to workshopping this.