-
Notifications
You must be signed in to change notification settings - Fork 61
Taiko #883
Comments
@rndquu I think we can break things off and work concurrently on these objectives. Perhaps you can handle the fork of the permit contract. Do you think it's possible for you to produce a mock interface so that @wannacfuture can work on the UI? Lastly I think @whilefoo should work on the config given that they just finished redoing all of the bot config last week. The specification is a copy/paste of the proposal I sent to Taiko, however I think we can realistically finish everything within a month if we are productive. @sergfeldman I assume you have extra bandwidth to stay on top of this from a project management perspective? |
To clear things out. Some projects (like Taiko) don't have cash rewards. They simply mint a POAP (i.e. ERC721 NFT) with contributions of a particular bounty hunter. Basically we should allow bounty hunter payouts in NFT (in addition to our existing permit2 cash rewards). So the bot will be able to generate permits for 2 cases:
For a bounty hunter the flow is going to be this one:
Yes, I'll create a new contract forked from https://github.com/Uniswap/permit2/blob/erc721/src/ERC721/SignatureTransferERC721.sol with a new
Right now I can't say for sure what the contract interface will look like. @wannacfuture You could create a separate branch at https://github.com/ubiquity/pay.ubq.fi/ with the "Claim POAP" button. We can check the reward token address from the permit json. So if it is ERC20 then show our standard permit2 layout, if reward token is ERC721 then show the "Claim POAP" button. Then (when the
Regarding the bot's config, right now the rewards tokens are hardcoded. Moving the token reward address to a separate config param seems to be not the best decision because our own "ERC721 NFT rewards contract" will be very specific so I hardly image that some partner would need to rewrite the contract's address. We could add a new bot config param like |
I feel that if we are already building the capability, we should allow both cash and NFT rewards concurrently because the additional effort required I expect to be marginal. If for some reason it is a tremendous effort to enable both simultaneously then I'm okay to add that capability later. |
I hope that the next several weeks will be busy with intensive negotiations on the card issuing. |
I feel this is related to multi-token permits: and permits table schema #811 the NFT / ERC721 token mint + multiple ERC20 token payouts could be combined into an array of permits and pay.ubq.fi could enable redeems for each payout / mint. |
Got it. Let me take a look what I can do for the refined UI. |
A new requirement is that
So if
|
I'm mobile now and it isn't convenient for me to check the issues but I vaguely recall we had a design for saving all the owed payments in the database and then generating a single claim permit to "roll up" the transactions. Was this backlogged or can we go for this in conjunction with passing in an array (to claim different tokens, as I presume a single permit can not transfer multiple token types) |
You can transfer multiple ERC20 tokens but not any other types via one permit but it'll have a heavier claim fee so the faucet would need to be adjusted to calculate the fee dynamically as opposed to the hardcoded env var. function permitTransferFrom(
PermitBatchTransferFrom memory permit,
SignatureTransferDetails[] calldata transferDetails,
address owner,
bytes calldata signature
) external {
_permitTransferFrom(permit, transferDetails, owner, permit.hash(), signature);
}
In such a case where the project isn't a cash based reward system, are we perpetually covering the claim fees for those partners if applicable? |
Cool
Good question. Knee jerk reaction would be to have partners cover their own faucets but if this is complex to set up then it makes the most sense for us to host it. |
Yes, but those owed payments are grouped by reward token address. So each reward token tallies up its own reward debt per bounty hunter. Hence when a single permit URL is generated we planned to pass an array of permits to
Yes, it was backlogged ubiquity/pay.ubq.fi#136
Yes, we can transfer multiple tokens in a single permit but only those tokens which support ERC20 interface. It's not applicable to Taiko's POAP. Anyway I would keep it simple for now and let |
@rndquu when can you get started? |
I'm starting this week |
This is a first iteration of the config paymentTokens:
- evmNetworkId: 1
tokenType: ERC20 | ERC721
tokenAddress: 0x...
basePriceMultiplier: 1
issueCreatorMultiplier: 1
maxPermitPrice: 100 I'm guessing for ERC721 / NFT rewards the multiplier would be capped at 1. Will a user get multiple NFTs in one issue: 1 NFT for completing the bounty, 1 NFT for participating in discussion, 1 NFT for reviewing PR...? Maybe it'd be better to separate ERC20 / ERC721 rewards in the config: tokenRewards:
- evmNetworkId: 1
tokenAddress: 0x...
basePriceMultiplier: 1
issueCreatorMultiplier: 1
maxPermitPrice: 100
incentives:
comment:
elements: ...
totals:
word: ...
...
nftRewards:
- evmNetworkId: 1
tokenAddress: 0x...
incentives:
issueSolver: true | false
issueCreator: true | false
issueCommenter: true | false
reviewCommenter: true | false |
I think this probably makes sense. For whatever its worth, I anticipate projects to be generous with the NFT rewards as they do not have any monetary value. I think most partners would default to have them all enabled. We should make all enabled the first development milestone we hit as I think thats more valuable than the ability to disable specific types.
I think any activity is okay. The repository maintainers can delete/exclude their contributions before closing the issue if there is abuse.
Yes I formalized the different ways to contribute into 17 unique "contribution classeses" during my refactoring. As such there conceivably could be up to 17 unique NFT types per issue, identified by their "contribution class." There is a hierarchy so that you're consolidated into the single highest rank role in case you fit in multiple. Contribution Class OverviewIssue View Commenters
Pull Request Review Commenters
Pull Request Review States
Code Contributors
Other
AppendixNamingThe "class name schema" is as follows:
Views
Roles
|
Yes, separating the configs looks good. Initially we discussed (can't find the thread) that it should be enough to have a single new bot config param like |
I think it's responsible to aim for minimum viable product considering our timelines. We can iterate later if we are ahead of schedule. |
Ok so then for the first iteration we will just add a param However I just want to make sure I understand how minting will work. @rndquu let me know when you have the contract ready and in the mean time I'll prepare the bot |
+1
Basically it will be our own ERC721 token with lazy minting (i.e. the bot will be able to sign off-chain mint requests for particular bounty hunters so that they could mint NFTs using the bot's signature). This is yet a draft but it gives a glimpse of how lazy minting will work.
Yes, we'll start with gnosis
Yes, since the initial deployment is on gnosis (with low tx fees) we're free to save everything on-chain
ok |
@rndquu we only have a few weeks for this first deadline. I was kind of expecting this to be done within the first couple of weeks. How is progress coming along? |
NFT reward contract is ready, you may find all info at https://github.com/ubiquity/nft-rewards. This is a js example of how to sign mint requests on the bot's side. I've DMed you a private key from the minter's account (used in the deployed contract) which you should use for signing off-chain mint requests. |
Overview
We will automate the generation of the POAP properties using all of the relevant GitHub metadata of the closed issue, including but not limited to: the organization name (Taiko) repository name, issue number, and their contribution style. This can allow for advanced filtering and analytics around the POAPs that are generated.
We will modify this contract https://github.com/Uniswap/permit2/blob/erc721/src/ERC721/SignatureTransferERC721.sol and add a new permitMint() method. This will allow users to mint the POAP only if they contributed to the closed issue. Given the bot's current capabilities this means that they were either a commenter of the issue/associated pull request, the author of the issue, or the assignee of the issue.
Timeline
Month 2 (8,013 Taiko tokens awarded):
(Prototype)
Month 4 (8,013 Taiko tokens awarded):
(Beta)
community.
Month 6 (8,013 Taiko tokens awarded)
(Release)
community.
The text was updated successfully, but these errors were encountered: