Available commands

- /start: Assign the origin sender to the issue automatically.
- /stop: Unassign the origin sender from the issue automatically.
- /help: List all available commands.
- /autopay: Toggle automatic payment for the completion of the current issue.
- /query: Comments the users multiplier and address
- /multiplier: Set the bounty payout multiplier for a specific contributor, and provide the reason for why. 
  example usage: "/wallet @user 0.5 'Multiplier reason'"
- /allow: Set access control. (Admin Only)
- /wallet: <WALLET_ADDRESS | ENS_NAME>: Register the hunter's wallet address. 
  ex1: /wallet 0x0000000000000000000000000000000000000000
  ex2: /wallet vitalik.eth

@call3hudson

/start

Tips:

• Use /wallet 0x0000...0000 if you want to update your registered payment wallet address @user.
• Be sure to open a draft pull request as soon as possible to communicate updates on your progress.
• Be sure to provide timely updates to us when requested, or you will be automatically unassigned from the bounty.

Skipping /start since the issue is already assigned

the previa before the PR, still in beta, i'm trying to redefine the concept and the functions designing accordingly, but it pretty much similar

@pavlovcik
@rndquu

To clear the terminology ubq.eth is basically a treasuryAddress.

It would be great if we can set multiple emission destinations and set the amounts. That way, for example, maintenance on this repository can receive 5% of all governance token emissions, UbiquiBot repository 10% etc.

Questions:

1. Right now 100% of additional governance tokens are minted to the treasury address. We should split governance token minting to separate addresses where each address corresponds to a particular partner github repository, right?
2. By "governance tokens" we mean that all our partners (who use the ubiquibot github app) will be able to mint UBQ governance tokens, right? Or partners should be able to use their own governance tokens?

Goods news! right now it's possible to dynamically add addresses to the array in charge to mint extra IERC20Ubiquity(governanceToken).mint

aswell as remove

To clear the terminology ubq.eth is basically a treasuryAddress.

It would be great if we can set multiple emission destinations and set the amounts. That way, for example, maintenance on this repository can receive 5% of all governance token emissions, UbiquiBot repository 10% etc.

Questions:

1. Right now 100% of additional governance tokens are minted to the treasury address. We should split governance token minting to separate addresses where each address corresponds to a particular partner github repository, right?
2. By "governance tokens" we mean that all our partners (who use the ubiquibot github app) will be able to mint UBQ governance tokens, right? Or partners should be able to use their own governance tokens?

All good feedback, we need this questions cleared

Questions:

1. Right now 100% of additional governance tokens are minted to the treasury address. We should split governance token minting to separate addresses where each address corresponds to a particular partner github repository, right?

It will be possible to set the partners address the array level

2. By "governance tokens" we mean that all our partners (who use the ubiquibot github app) will be able to mint UBQ governance tokens, right? Or partners should be able to use their own governance tokens?

All addresses set will be getting a % fee of the minted token, altho, this was is suggest to change and clarify

• Right now 100% of additional governance tokens are minted to the treasury address. We should split governance token minting to separate addresses where each address corresponds to a particular partner github repository, right?

When promoting the DevPool/bot, I'll highlight how this approach is a stepping stone towards greater autonomy for DAOs. By aligning tokenomics with the direct funding of productive work, we can create a more efficient and self-sustaining DAO ecosystem. This method not only incentivizes meaningful contributions but also paves the way for DAOs to seamlessly integrate their tokenomics with actual work output, enhancing both governance and operational effectiveness

• By "governance tokens" we mean that all our partners (who use the ubiquibot github app) will be able to mint UBQ governance tokens, right? Or partners should be able to use their own governance tokens?

Partners should use their own governance tokens.

However for a temporary growth strategy we can definitely consider emitting UBQ to whitelisted partner wallets. For example, Taiko, MakerDAO.

This could allow for a really interesting future where DAOs can donate to specific work efforts of other DAOs using our system.

I think we could focus first on implementing the feature, then expand its functionality based on our needs and evolving requirements. By prioritizing the core functionality initially, we can ensure a robust foundation. Once the feature is successfully deployed and uses provide valuable insights, we'll use that feedback to guide future enhancements and expansions. This iterative approach allows us to deliver a well-refined feature while staying responsive to the changing needs or potential partners.

I think we're all using a little ChatGPT in our replies now

However for a temporary growth strategy we can definitely consider emitting UBQ to whitelisted partner wallets. For example, Taiko, MakerDAO.

Ok, so as a part of the current issue we should update the ChefFacet contract and add a whitelist of partner wallet addresses eligible for Governance token mints.

User stories:

• admin should be able to add/remove partner wallets eligible for Governance token mints
• admin should be able to set the reward rate for each partner

Notice that we shouldn't simply iterate across all partners here and mint tokens to all of them but rather create a separate method for each partner where the partner's reward would be calculated dynamically so that partners could claim rewards from time to time. This is to prevent unnecessary gas costs for staking contract users + to prevent contract DOS when amount of partners increases.

This is to prevent unnecessary gas costs for staking contract users + to prevent contract DOS when amount of partners increases.

That is unfortunate and feels like its removing the magic out of this idea. It no longer feels like "automatic governance distribution to the contributors" unless if I am misunderstanding.

At this point, wouldn't it be simpler to fork Compound's contract that "drips rewards" and then people can claim? I suppose this is the latest rewards contract that Compound has.

Just throwing this new approach out there, but is it possible to do a more native integration with the bot and permits? For example, we have a new method with some tight access control/limits that allows the bot to issue permits and directly let contributors claim?

Or perhaps we can associate limits based on the repository id and user id and make some type of oracle system to prevent abuse?

function claimContributorRewards(uint256 gitHubRepositoryId, uint256 gitHubUserId) {
    ...
}

Clearly that seems to be a far larger project. I'm hoping we can make this seamless but simple to implement, ideally.

there are still many ways to keep this simple, we could even add a onlyPause() modifier to stop this extra emissions following the external method that rnqnuu mentions, increasing gas costs for claimers it's the only setback i'd look

function claimContributorRewards(uint256 gitHubRepositoryId, uint256 gitHubUserId) {
    ...
}

Or perhaps we can associate limits based on the repository id and user id and make some type of oracle system to prevent abuse?

getting a bit out of the original intention but we could do a poc

At this point, wouldn't it be simpler to fork Compound's contract that "drips rewards" and then people can claim?

This is basically what I meant. Partners should be able to claim rewards instead of minting directly to the partners.

Just throwing this new approach out there, but is it possible to do a more native integration with the bot and permits? For example, we have a new method with some tight access control/limits that allows the bot to issue permits and directly let contributors claim?

This looks like we're trying to reimplement uniswap's permit2 contract because the logic inside the claimContributorRewards(uint256 gitHubRepositoryId, uint256 gitHubUserId) method will look very similar to _permitTransferFrom()

Do you have any updates @molecula451? If you would like to release the bounty back to the DevPool, please comment /stop
Last activity time: Wed Nov 22 2023 02:34:32 GMT+0000 (Coordinated Universal Time)

yeah i see, but original's pavlovciks vision is to generate rewards after an user claims, so this not what we're doing then, as this is gas costly for users, and certainly a bad experience of expensive networks like mainnet, but overall it would only be good for gnosis

Is this issue clear and scoped? Can jump on it.

This issue implies editing LibChef while we decided to keep using our old staking contract MasterChefV2.1.

As far as I understand, as a part of this issue we should mint UBQ tokens to whiltelisted partners who use the ubiquity-os bot.

What we could do:

1. Create a new smart contract responsible for UBQ rewards distribution
2. Set that smart contract to receive UBQ rewards instead of the treasury in the staking contract here

The "treasury" smart contract's owner must have the ability to:

1. Add/remove partner wallets eligible for UBQ token mints
2. Set the reward rate for each partner wallet

Ideally we should search for an already audited contract with the same functionality.

@0x4007 ?

I think it makes sense to only reward contributors who are helping to build ubiquity infrastructure with UBQ tokens. So we should only drip rewards to wallets we control for our organizations on GitHub.

However as a temporary marketing campaign we can certainly add a handful of top tier partners (like makerdao etc)

@zugdev Pls check this comment.

Ideally we should find an already audited contract (PaymentSplitter?) + cover it with unit tests.

Yeah that's the approach I think works best.

/start

@rndquu Gaslite is better, we could use this contract. OpenZeppelin's payment splitter is no longer mantained and was deprecated a while ago. Btw it wasn't very clear if I should modify MasterChefV2 or LibChef, specially because MasterChefV2 is not within this repo. Anyways I'll begin working on the payment splitter. Let me know if you need a different contract.

@zugdev

Gaslite is better, we could use this contract.

There are few drawbacks:

1. Too much assembly (basically almost 100%)
2. Audited by a single person 0xth0mas. I couldn't find his profile neither on sherlock nor on code4arena.

OpenZeppelin's payment splitter is no longer mantained

Although it is no more present in openzeppelin v5 it is still present in v4.9. Perhaps we could utilize the one from v4.9 (which https://github.com/ubiquity/ubiquity-dollar currently uses).

Btw it wasn't very clear if I should modify MasterChefV2 or LibChef

You should create a new contract (let's call it, for example, Treasury) for distributing UBQ rewards as stated in this comment. Later we will set the newly created Treasury contract as UBQ rewards receiver so that partners could receive UBQ rewards.

How it's gonna work:
1.Treasury contract owner sets MasterChefV2.1's treasury address to the newly created Treasury contract
2. Owner adds payees' addresses (i.e. whilte listed partners who use the ubiquity-os bot) in the Treasury contract
3. Treasury contract distributes rewards in a pull-based manner

Understood 🫡

/start

pick another issue, someone is already working on this one

I should be reasigned here, waiting for review.

@zugdev the deadline is at Tue, Oct 22, 5:57 AM UTC

@zugdev the deadline is at Tue, Oct 29, 4:49 AM UTC

Passed the deadline and no activity is detected, removing assignees: @zugdev.

so, what happened over here? @zugdev i thought had a solution based on the input here

so, what happened over here? @zugdev i thought had a solution based on the input here

The disqualifier is not waiting for review and disqualifying early in some cases.

The disqualifier works this way:

• waits 7 days for the warning
• waits 7 more days for disqualification

However, if a user didn't open a PR within the first 7 days it gets disqualified directly. And the disqualification period is influenced by the priority of the task, for example: priority 3 means 7 days / 3 = 2.5 days before the reminder.