Multi Token Rewards - Ubiquity Governance Token (UBQ) Distribution

0x4007 commented 1 year ago

Context

We should reward community members for completing bounties on our repositories and take part in the upside of Ubiquity. This could lead to more loyalty to contribute to our repositories if they are bullish on what we are doing. Particularly if we begin revenue sharing via a buyback-and-lp on our governance tokens.

This effectively means that we should support multiple token payout configurations with the bot.

Proposal

At first I thought that we could duplicate all of the existing payment related configurations for the payment token. Using the ubiquibot-config-default.json as a reference point.

{
  "evm-network-id": 100,
  "price-multiplier": 1,
  "issue-creator-multiplier": 2,
  "payment-permit-max-price": 9007199254740991,
  "assistive-pricing": false, 
  "comment-incentives": false,
  "incentives": {
    "comment": {
      "elements": {},
      "totals": {
        "word": 0
      }
    }
  },
}

I realize that by changing the price-multiplier we should be able to use the same priority and time labels to calculate a different number BUT this instance must also be able to create a new price label representing the reward as well

e.g. 50 UBQ

So that when a bounty is prepared it would have at least four labels

e.g. Priority: 3 (High), Time: <1 Day, Reward: 500 WXDAI, Reward: 100 UBQ

Tasks

0x4007 commented 1 year ago

@rndquu rfc

rndquu commented 1 year ago

@rndquu rfc

Questions:

So when a bounty hunter solves an issue he should be able to get 2 reward permits (for example for DAI and UBQ), right?
We support payouts in WXDAI for the gnosis chain. If evm-network-id=100 then we should also generate UBQ permit for the gnosis chain, right (which means that we should deploy UBQ token to gnosis chain or use some crosschain SDK)?
What if we modify the price-multiplier: 1 config param to something like:
```
"price-multiplier": {
"DAI": 1,
"UBQ": 0.1
}
```

0x4007 commented 1 year ago

Yes but ideally inside of one link with both permits encoded in the query parameters.
I used the Omni bridge so we already have UBQ on Gnosis Chain. I think it's simple enough to expect our partners to do the same.
Seems like a good idea but something tells me we might need to use the address as the identifier. By the way, in my code block in my previous comment, what I was trying to express is that we should consider that entire object as the incentive configuration per reward asset. In this case we would have one for WXDAI and one for UBQ. Intuitively I think it makes sense to allow partners to design their own incentive schemes. It makes our tool more versatile across a wider variety of use cases.

rndquu commented 12 months ago

I used the Omni bridge so we already have UBQ on Gnosis Chain

So when the tokens are bridged via the Gnosis OmniBridge a new ERC667 token is created

Now we have:

UBQ ERC20 on mainnet: https://etherscan.io/address/0x4e38D89362f7e5db0096CE44ebD021c3962aA9a0
UBQ ERC667 on gnosis: https://gnosisscan.io/token/0x2b20faaf99d1f849815d55bed626bde050aa12c4#code

0x4007 commented 6 months ago

I bumped all the subtasks up to high priority so that we can support governance token payouts in tandem. This MAY help with our growth strategy if we offer small rewards during the launch period.

@rndquu I would appreciate if you take some time to review the specifications and update them if necessary due to the recent developments since this was originally authored.

Also from the perspective of the bot, these should be implemented in the form of plugins, or the kernel config parsing module.

rndquu commented 6 months ago

I bumped all the subtasks up to high priority so that we can support governance token payouts in tandem.

All of them should be closed since we moved to plugin oriented architecture. I will update the specs once https://github.com/ubiquibot/permit-generation is production ready.

ubiquity / ubiquibot