Beta: Financial Incentives

[0x4007]

These incentives should all be paid out at the time the bounty is solved. During the bull market (with high gas fees) it may be wise to handle all bounty payments on an L2 like Optimism.

• Contributor Comment Incentives

  • Different elements in a contributor's comment corpus could have different price tags.
    • For example: plaintext=$0.1/word; link=$1; code block/image=$5;
      • Links are helpful but examples (via codeblocks) are probably the most involved to do.
      • With this current price algorithm, Tests are sometimes not running for random RPC URLs ubiquity-dollar#437 (original edit) yields $48.10 for the issue creation alone which seems pretty solid. Would be more for more comments/clarifications.
      • We can create the payment permits only when the bounty has been completed. This will calculate the reward for all of the contributors' comments at the time of bounty completion to accommodate any small edits/clarifications made during the course of the bounty completion.
        • This may cause perverse incentives to make less clear specifications. Need to observe how this plays out.

• Incentivizing Bounty (Issue) Creators/Delegation

  • The issue creator should get a multiplier on the comment incentive. For example, 2x credit for the original post in order to attempt to compensate for the time to identify the issue.
  • Manual approval from two roles required in order to authorize payment permit generation to protect from exploitations: technical architects and project managers.
    • Technical architects have the authority to set the Time: label. This is so that they can approve of the specification as being the most efficient approach to solve the business problem.
    • Project managers have the authority to set the Priority: label.
    • Both Time: and Priority: labels must be set before the bot will generate a price for the bounty.

• Incentivizing PR Reviews

  • Comment incentives should apply for reviews.
  • We can limit the reviewer incentives to the price of the bounty, per reviewer. Once the limit is hit, the bot should immediately notify in a comment saying that the limit has been reached, and that no more incentives can be provided to the reviewer. This should incentivize the reviewer to drop the review if the bounty hunter is wasting too much time. A formal way to indicate the exit could be that they dismiss their reviews (possible on GitHub UI.)
    • If all reviewers exit, we could automatically close the pull request for low performance and ding the bounty hunter's reputation in the database for not being talented enough etc.

[0x4007]

Multipliers on good performance

• PRs you reviewed you’re on the hook for if there are issues
• If you get X amount of flawless PRs

Time and Amount of PRs

• For example, approve 1 pull request a week that passes without issue
  • after one month you are eligible for a cash bonus
  • if any PR is reverted or has issues then bonus lost

[0xcodercrane]

If I understand the initial proposal correctly, incentivizing should depend on how much creators/delegators/reviewers contributed to the issue completion.

How to estimate bounty masters' contributions?

How to incentivize bounty masters based on their contributions?

I feel it would be better to incentivize bounty masters every month or every week (whatever is fine if it can be done within a regular interval), I am not opposed to pay per bounties through permi2 url. If a permit url gets generated, it should be claimed to get them into my pocket which may lose my fund (heres an example I think. I receive 10$ as an incentive but eth gas is extremely high so spent $15 to get $10 ).
I also don't want to claim my incentive rewards on every bounty, prefer looking at my contributions growing through like a web page and collecting them once I am fine.

[0x4007]

Yes but as we discussed with "permit rollups" earlier last month, the best solution is simply to use an L2 like Optimism to reduce gas fees.

@rndquu correct me if I'm wrong but the permit rollup API" idea is not worth pursuing due to complications around nonce invalidation?

[rndquu]

due to complications around nonce invalidation

You mean nonce invalidation in case of private key compromise?

Regarding the possiblity of using "permit rollups" (when a bounty hunter can claim all his rewards in a single transaction) via uniswap's permit2 the best we can do is to move to AllowanceTransfer. But in terms of gas it would be the same for a bounty hunter as many single claims because in the end all allowances are increases in a loop.

L2 solutions like optimisim solve the gas issue. But I guess we can make a further research regarding permit rollups, perhaps there is a ready made solution for our use case (or we can build our own).

[0x4007]

(or we can build our own)

UbiquiChain imminent?

[rndquu]

No, I meant forking https://github.com/Uniswap/permit2/blob/main/src/SignatureTransfer.sol and adding a feature of invalidating previous nonces on permit claim

Example:

1. Bounty hunter has an unclaimed permit for 10$ with nonce 1
2. Bounty hunter has an unclaimed permit for 20$ with nonce 2
3. Bounty hunter creates a "rollup" permit for 30$ with nonce 3 which on redeem invalidates permits with nonces 1 and 2