ubiquity / pay.ubq.fi Goto Github PK

There is an audit page which matches github issue URLs with payout transaction.

It can only work with ethereum mainnet.

What should be done:

• add support for gnosisscan.io

Right now the audit page looks like this (check the screenshots in the PR).

What should be done:

1. Use typescript for js scripts (the same way it is already done in the index page)
2. Remove bootstap's css and use project's css (again the same way it is already done in the index page)

Test issue

Right now the UI will pass through and throw the raw MetaMask error.

In the case of the permit wallet not having enough DAI, the error was just something like "unable to estimate gas for transaction. Revert"

When that error is thrown, our UI should attempt to check the balance of the permit wallet.

If it is not enough, the UI should throw another error (display both the raw MetaMask error as well) that lets the user know that there is not enough balance in the permit wallet.

I mocked up an updated table.

It's a nice idea for additional context to read the issue name as well and display it.

Also the amount of DAI should link to the etherscan transaction (if it exists.)

We can make filters later to show/hide claimed transactions!

Please match the table to look like the following:

          maybe have the TX as a link and use that space for the issue name?

Originally posted by @Hodlatoor in #24 (comment)

On my Safari there is no wallet provider and it throws an error and hangs at "loading..." this should be caught and handled.

Strangely enough it crashes on Safari right at the function execution but technically that's not in scope of the bounty. But still concerning that there's inconsistencies with Safari and Chrome for a simple promise.

[Error] Unhandled Promise Rejection: Error: missing provider (argument="provider", value=undefined, code=INVALID_ARGUMENT, version=providers/5.7.2)

	(anonymous function) (app.ts:8)

Originally posted by @pavlovcik in #23 (comment)

Depends on ubiquity/ubiquibot#262

We should have a web page where a partner should be able to generate an initial config repository for his project.

There might be an input for a permit2 private key and a button "generate". On "generate" click partner is authorized via github and the config repository is created.

When the permit wallet doesn't have enough balance or allowance, it will show THIS PERMIT IS NOT CLAIMABLE. This is misleading and should be changed to more descriptive. Something like Organization EXAMPLE doesn't have enough balance on their wallet. Please contact them to top up their balance and Organization EXAMPLE doesn't have enough allowance set. Please contact them. We don't have organization name in the payload so maybe we should include that when generating permit in ubiquibot or we can just do without the name

This is currently happening on all ubiquity permits like this one

Right now in the onboarding page we ask partner to generate a classic github personal access token with "repo" and "admin" scopes. So partners could ask why we need so many permissions. Perhaps we could utilize github's fine grained tokens to narrow down the permissions we need (create a private repository + create a file in that repository)

What should be done:

1. Use github's fine grained tokens to narrow down required permissions to minimum
2. Update partner integration docs

          I mocked up a new design can you implement the following: 

Originally posted by @pavlovcik in #23 (comment)

• Depends on #110

When bounty hunters solve multiple permits it is hard for them to:

• find out unclaimed permits
• claim permits one by one

We should add a "Claim all" button that consolidates all their unclaimed permits in a single Multicall transaction.

What should be done:

1. Add the "Claim all" button
2. On click bounty hunter should be authorized in metamask
3. Then we should find out all bounty hunter's unclaimed permits (we know his address from authorized metamask), consolidate them in a single transaction and call Multicall

Notice that we support 2 networks: ethereum mainnet and gnosis so there could be unclaimed permits for both of the networks. We should somehow handle it, perhaps call 2 Multicall txs in a row. Perhaps there is a better solution.

Original discussion

Every time you open a new pull request on your GitHub repository, Cloudflare Pages will create a unique preview URL, which will stay updated as you continue to push new commits to the branch. This is only true when pull requests originate from the repository itself.

Source.

Unfortunately we need to create (or fork) a custom GitHub Action to use Cloudflare wrangler to automatically deploy a preview when bounty hunters open up a pull request in order to make the review process more efficient.

I believe that this should check the decimals from the smart contract before trying to render it with 18 in case we have a USDC or USDT situation.

          Now I'm also wondering how USDT and USDC render with `ethers.utils.formatUnits(allowance, 18)` but perhaps that can be a different bounty.

Originally posted by @pavlovcik in #42 (comment)

What if we made a Repository with a GitHub Action that bounty hunters can fork and add their signing key as a secret to automatically claim bounties?

When the UbiquiBot pays out, it can post the comment and also ping a GitHub Action webhook.

The webhook can be to something like https://api.github.com/${bountyHunterGitHubUserName}/devpool-claim

If they forked the repo and setup their GitHub Action webhook correctly (should be by default, except for the secret - the signing key) then they can automatically claim as soon as the payout is offered!

Config:

PRIVATE_KEY
MAX_GWEI e.g. 50

• - I just realized that the color for the timer bar on the toaster is not rendering.
• - opacity for header needs to be dimmed on light mode.
• - opacity too low for beneficiary name.

Need to fix.

• - Background and body elements should span to fill sides in dark mode

Originally posted by @pavlovcik in #93 (comment)

When I click CLAIM there is an error toast but no text inside.

Lets prototype the flow here.

• Check if no wallet is connected
• Display claim button always now
• If wallet not connected then when user clicks a toaster should explain:
  • That they can connect their wallet and claim directly, which only will cost them gas fees.
  • Warn user about x% fee to use the Ubiquity relayer service.
• User clicks button and relayer handles the claim.

We need to figure out how to calculate the total relayer cost because it must cover dynamic gas fees.

Permit Consolidation API

We could make a simple UI that takes several permits collected by the bounty hunter and sends it to our Permit Consolidator API. It is a permit rollup. It can check if the permits have been used already. If not, then it can revoke them (not sure if possible?) and then generate a new combined one. In this way, the bounty hunter will be able to withdraw all of the allowance in a single transaction.

I was looking at my permit claim on my phone and realized that it would be really convenient if I could claim from my phone browser which does NOT have web3 wallet support.

• Let's set up a relayer that will allow users to claim their permits if they click claim without a wallet.
• In case we can't execute the claim on their behalf directly, we can simulate it by invalidating the permit, and then transferring the DAI to them? Although I hope we can just execute the claim directly on their behalf.
• The relayer should take a configurable fee. Let's say 1% to start.
• Reference claim.

• #117
• #118

Let's make a simple user interface that has a similar setup as the audit page.

The vision is to let a contributor easily claim all of their unclaimed permits in one shot off of a specific repository.

1. The contributor will specify the organization, the repository name, and their wallet address (in the future we can have them connect their wallet and handle this automatically.)
2. The web app will go through every UbiquiBot comment and check if any permits are unclaimed.
3. The web app will total up the dollar amount of every unclaimed permit.
4. The user at any time can click a "claim" button that will use multisend to claim all of the valid permits simultaneously.

This will be particularly useful for when ubiquity/ubiquibot#272 is implemented and for contributors who are more frequently commenting vs solving bounties (bounty hunting.) They will be racking up small amounts over time across many different bounties which can become extremely tedious to hunt down every permit link. At this point I think a rollup will be necessary in order to save costs.

(Optimism or Gnosis Chain - formerly known as xDAI Chain - seem interesting to me personally for this stage.)

@Steveantor looks like Cloudflare doesn't support esbuild. Can you figure out how to make it work? I suggest setting up Cloudflare pages (its free) and link it to your fork for testing.

cf2fb4e#commitcomment-108350462

Add chainId to the auto generated config page

What should be done:

1. Add a text input for the chainId parameter
2. Populate the result config with the provided chainId parameter

We should migrate to viem since it's more performant and better from all sides than ethers
https://viem.sh/docs/introduction.html

Bundle Size

Performance

• Depends on #86

There is the audit page which produces a table with github issue title (which is a link to an issue URL) and correspondent payout amount (which is a link to ethereum/gnosis transaction URL):

We should make a UI more user friendly

What should be done:

1. Remove the "Etherscan API Key" text input. Hardcode this API key in the code. Notice that we support ethereum and gnosis networks so you should hardcode both of the keys (etherscan and gnosis API keys)
2. Remove the "RPC URL" text input. Hardcode RPC URLs both for ethereum and gnosis in the code.
3. Check that the "Github Personal Access Token" input field is necessary. As far as I remember we need this PAT for some of the github endpoints but I'm not sure, pls check.
4. Remove the "Owner name" field.
5. Refactor the "Repository name" field to "Project URLs" textarea which should accept a comma separated list of repositories we are building analytics for. Example:

https://github.com/ubiquity/ubiquity-dollar,
https://github.com/ubiquity/pay.ubq.fi

6. Modify the analytics table to contain the following columns:

• organization name / repo name (which is a URL to the repo under the hood), ex: ubuiquity/pay.ubq.fi
• issue (no updates, keep it "as is")
• bounty hunter nickname who solved an issue (which is a URL to bounty hunter's github profile under the hood)
• amount (no updates, keep it)
• on-chain payout tx hash (which is a URL to etherscan or gnosiscan transaction)

7. Add search text field above all of the table columns for filtering results

Original discussion

I wonder if its possible to ONLY support Ubiquity Dollars internally, but to chain together a transferFrom and a swap PERMIT so that bounty hunters can "cash out" in any token they want. This way we will always get our swap fees, and in order to use our DevPool, you MUST top up with Ubiquity Dollars.

Another benefit to this is that we can allow for minting when we're above peg, which means that we'll be able to raise collateral and deploy it (like FRAX AMOs) to make yield. This and swap fees can be our indirect way to profit from all of this.

We could consider leveraging transfer hooks in order to make it seem like its not a gimmick. If we have some unique capability that only exists in our Dollar and not other stablecoins then its easy to argue why we implemented our system this way.

Given that gas fees will be higher if we chain operations together, we should also look into ways that we can "roll up" permits. Ideally if a bounty hunter can "cash out" several permits combined into a single one then it could save on gas fees.

• Finalize architecture
• utilize Uniswap router api to estimate cash out amount in any asset
• Create cash out button to allow user to perform the swap from this UI

There is the audit page where we can match github issues with ethereum transaction payouts.

If you run the audit page for the https://github.com/ubiquity/business-development repository you will get the following output (at the moment of creating the current issue) with 5 results:

Somehow the following issues are not included in the result audit table (though permits were generated for those issues):

• ubiquity/business-development#2
• ubiquity/business-development#48

What should be done:

• find out the reason why not all issues with generated permits are included in the audit page and fix the bug

1. We deprecated the range labels (e.g. "Price: 400+ USD") so they should no longer be included in the config generation. I noticed it in the below action.

2. Check that the provided github personal access token has the required scopes: repo and admin:org

Looks like the wizard halfway worked:

https://github.com/Alpha-Labs-Global/ubiquibot-config

Was created but there was an error presumably committing the config.

Originally posted by @pavlovcik in ubiquity/ubiquibot#299 (comment)

Create a web page somewhere at https://pay.ubq.fi/analytics where a treasurer will have to:

1. Fill 4 text inputs: etherscan API key, github API key, wallet address, repository URL
2. Click "Get audit report" to get a table in the format "github issue URL => etherscan tx URL => payment amount in DAI"

Similar to how we have it in @ubiquity/ubiquity-dollar smart contract unit testing, we should select the fastest RPC from our list of available RPCs and recommend it to the user if they need to change networks to claim the permit.

Right now we have singular options hardcoded in, but https://rpc.gnosischain.com is having serious performance issues at the moment.

I think the code can be lifted from @ubiquity/ubiquity-dollar

renderEnsName relies on some random person's Cloudflare function which appears to be down. We should make our own solution. I hope that we can handle this entirely from the front-end?

We should also make all of our requests non blocking in case they fail!

Originally posted by @pavlovcik in #42 (comment)

We should make the secret.html page better

What should be done:

1. Remove the EC_PUBLIC_KEY field
2. Encrypt wallet's private key under the hood on "Set" button click
3. Remove the "Encrypt" button

Use this curve25519 public key: 5ghIlfGjz_ChcYlBDOG7dzmgAgBPuTahpvTMBipSH00

When this task is ready:

1. We should generate our own config for the https://github.com/ubiquity organisation
2. We should ask https://github.com/Alpha-Labs-Global to generate their own config
3. Remove reading the "old shared" private key from the environment variables on the bot's side and read it only from a config

This payout page is responsible for bounty claims (claim example). Bounty claims are generated with the help of the uniswap's permit2 contract. Each issue has a unique bounty claim URL thanks to the permit2 nonce.

Sometimes there are cases when we should invalidate nonces for some claim URLs in case of the bot's error or smth else. That is why we need a friendly UI for nonce invalidation.

What should be done:

1. Add a new button "invalidate" to the https://pay.ubq.fi page
2. The "invalidate" button should be visible only if the authorized wallet account equals to the permit signer and the nonce is unclaimed
3. On "invalidate" button click we should send a tx that invalidates the nonce

On-chain example of nonce invalidation here

A couple of experiences when claiming a bounty that should be improved.
for eg:

1. if there is an error (like master wallet having insufficient funds or transaction declined by hunter due to gas fees) it comes off as a dramatic data dump in red. What about reducing the amount of data visible and providing a simple error message and # if needed.

2. when claiming a bounty the hunter can still click the claim button again which results in an error. Best solution - grey out after payment is confirmed and change to "paid". second best alternative issuing a message saying the bounty was already paid out.

I just tested this Gnosis Chain claim and it was successful. However there are a handful of user experience related issues that must be addressed. I went to the dApp with the current network as Ethereum Mainnet.

• The token address link goes to an invalid address on etherscan.io because it is supposed to be checking for the token contract on gnosisscan.io
• The token address should be converted to display the token symbol, as we have it working with DAI on mainnet.
• When I hit claim, there was an empty error toast.

I had to refresh the page a few times to get it to work eventually. It seemed like the dApp was lagging quite bad when I tried claiming the first couple of times. The dApp should also have the following capabilities:

• Automatically detect which network the claim is on, and request to the user to switch to that network.

• Example Mainnet Unclaimed Permit Issue
• Example Gnosis Chain Unclaimed Permit Issue

Revision 20 June

Maybe a better approach would be including chain id in the URL parameter when generating a claim url on the bot, which would be cleaner in my opinion.

#76 (comment)

I tried setting up parcel because its fast and easy to setup but there was some compatibility issue with compiling ethers so I couldn't use it.

I don't want to go all in on Next.js / React because of how simple the application is. No need to burden ourselves with that much overhead (slows me down orders of mag when I have to deal with the bloat from UI frameworks.)

Rollup seemed like an appropriate alternative but required a ton of config.

Webpack seems quite heavy.

Are there any alternatives?

Maybe hacking together a build script using tsc directly?

Right now the audit page takes a while to load.

What should be done:

1. Add etherscan pagination
2. Handle errors
3. Implement retry on errors or rate limits
4. Cache the result in local storage so that on the next script run it wouldn't fetch already cached data
5. Get etherscan transactions and github comments in parallel so that those API requests wouldn't wait for each other

In order to track down a specific transaction from the chain to understand why it was paid out is almost impossible now, as every combination of chain and repository potentially must be checked.

We need to improve its usability. We now have many repositories (12+) with multiple chains (mainnet, gnosis chain.)

General Tasks

• The configs should be baked into the dApp, like the RPC url for Mainnet and Gnosis, and API keys to make the audit process less burdensome.

Views

These can be considered separate projects, in chronological order:

• 1. Audit transaction: I think we should write metadata on chain within the transaction in order to ease claim auditing. OR we can pass in a claim transaction hash to the audit dApp, and the dApp can return results on the contributor, the claim comment URL, and the associated issue etc. Perhaps this can be straightforward by passing the permit details to the dApp, and the dApp uses the GitHub API to search for those permit properties encoded as a string in a comment URL?
• 2. Audit user: we can track down a specific contributor's claims (e.g. enter a contributor's GitHub username and see all of the associated claims/issues.)
• 3. Audit repo: see all claim details on a repository.

Bonus

• 4. Claim unclaimed: bounty hunters should be able to use an enhanced UI (using similar claim parsing logic that we would have already built at this point) that automatically tallies up their unclaimed permits, and they can multicall and claim all of them in one go.

Depends on ubiquity/ubiquibot#327

There is a config generation page where a partner can generate a default bot's config.

Ubiquibot development is quite active and we add new bot's params on a regular basis. It's tedious to update config generation page every time there is a new param. So we can refactor the bot's config so that the config generation page could fetch a default config once. This way it is no more necessary to update config generation page on every new param introduced.

What should be done:

• fetch default yml config from the bot's repository and use it here to populate default config values

P.S. when the bot becomes a private repo we could move the default yml config to some other public repo

I think for various components down the road we will need good system analytics. Some of what comes to mind includes:

1. bounty:

   • of bounties, average time to completion, success rate, average bounty $ and a distribution chart/graph by selectable time (to recognize trends)

2. bounty hunter:

   • of hunters, activity ranking (by bounty #, $ and type), # of bounties per hunter, total compensation per hunter (and system average) for selectable time as a chart/graph would be great too.

3. bounty master:

   • of bounties issued, average time to completion, total spend (and time selectable), associated projects

4. would be cool to be able to parse this data eventually as an interactive neural network model.

5. opinion: I would think these data should be private but i know some might disagree. can we get a consensus on this?

Seems intuitive that the claim button should be disabled if it is impossible to use. We could do something like

display: none;

Should be 7 characters to match GitHub hash display but in our CI we seem to be overriding the hash production from the build script inside of package.json

Depends on ubiquity/ubiquibot#305

This PR introduces a new param incentive-mode which should also be added to the config generation page

Depends on ubiquity/ubiquibot#547

When ubiquity/ubiquibot#547 is implemented we should read permits from a DB instead of parsing github comments.

What should be done:

1. Remove the comment parsing logic which finds permit URLs in issues
2. Read permit URLs from supabase DB

Supabase public/anon key which can be safely used in the frontend: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6Iml5eWJoaGlmbHdic2pvcHNnYW93Iiwicm9sZSI6ImFub24iLCJpYXQiOjE2ODUxMTA1MTMsImV4cCI6MjAwMDY4NjUxM30.R_c29S9xFbZmqHxi4HTdhP8uqHt2v6DnUSCEAxBeTTM

Supabase project URL: https://iyybhhiflwbsjopsgaow.supabase.co

Original comment

There is the audit page where we can match github issues with ethereum transaction payouts

If you run the audit page for the https://github.com/ubiquity/business-development repository (there are 44 issues at the moment of creating the current issue) then the script runs for ~3 minutes and makes 1200 API requests. Most of those API requests (~80%) are eth_chainId() and eth_blockNumber() RPC calls. It's seems like a bug because we don't need to get chain id or block number so often for the audit script to work fine.

What should be done:

• find the root cause of so many unnecessary RPC calls and fix it to make the audit script run faster

• So we can claim permits on behalf of users directly.
• Or simulate that by invalidating the permit and doing a direct transfer to their wallet.

We must figure out how to calculate the fees so that the dynamic gas fee will always be covered, plus a profit.

          > https://etherscan.io/tx/0xf7eab4b5090d50d1895f2d9708b13cce45dc433593d6e866652b63434c903897

claim was successful

Dang would be super cool if the bot could post this automatically as proof for everyone reading.

Originally posted by @pavlovcik in ubiquity/ubiquity-dollar#592 (comment)

Updated Proposal

What we can do:

1. When permit URL is generated save payment details to supabase (notice that each permit has a unique nonce)
2. On some repository event (which runs the bot) find unclaimed permits (read from the DB)
3. For each unclaimed permit check if it was claimed (should return 1 here https://github.com/Uniswap/permit2/blob/main/src/SignatureTransfer.sol#L19)
4. Use https://docs.etherscan.io/api-endpoints/accounts#get-a-list-of-normal-transactions-by-address and find the claimed permit (filter tx inputs and find a tx with the provided nonce)
5. Post a tx url and mark permit as claimed in the supabase DB
   This is all done on the bot's side inside a CI action runner.

Old Proposal

This is left here for reference.

i think we could setup a webhook:

1. setup a restful endpoint on the github action ci, or supabase, or a cloudflare action.
2. in the claim webapp, when the claim transaction is completed, post the github issue data to the restful endpoint
3. github issue data is saved to supabase for later review. ideally it also computes the transaction hash for later review

perhaps its simplest to post 1. link to issue 2. transaction hash

From https://t.me/c/1588400061/1673/2181

I checked the chain and it does not look like this was claimed. Why does the dApp say "permit already claimed"?

I also think its unlikely that sergfeldman went and invalidated the nonce - unless the bot did when generating the new permit?

Is it possible to also explicitly say that the permit has been invalidated instead of saying that the permit was claimed?

The only way is to parse all wallet transactions from the bot's wallet address. It is possible but "time-consuming" for the UI because we need to fetch all transactions, parse all of them and find a correspondent tx with the provided nonce. So it adds a few seconds for a UI to load.

We can check the date the permit was generated by cross referencing the comment timestamp. We can pass that data in to the dApp as a query parameter. Then we can check the chain starting from that timestamp which should cut down on the amount of network requests. I wish we could do a single network request and receive all of the transactions between Date.now() and the comment timestamp!

However the total amount of network requests shouldn't be too crazy because it is likely that the invalidation or claim transaction happened soon after the permit was posted e.g. within a day for most cases.

Also we should instantly show to the user that the "permit is unclaimable" and that the UI is "figuring out the reason now..."

It can asynchronously check the chain and update the text with the reason.

          ### [ **[ CLAIM 100 WXDAI ]** ](https://pay.ubq.fi?claim=eyJwZXJtaXQiOnsicGVybWl0dGVkIjp7InRva2VuIjoiMHhlOTFEMTUzRTBiNDE1MThBMkNlOERkM0Q3OTQ0RmE4NjM0NjNhOTdkIiwiYW1vdW50IjoiMTAwMDAwMDAwMDAwMDAwMDAwMDAwIn0sIm5vbmNlIjoiNjQ4NDI2MjQ0ODY1NzM3ODAxMTkxMDA2MTIyODU4MDAwMDg5NzE3NzgxMDkwNDA4NjAzMDE3NDM1MTk0NDEwMDczMzkzMDc1Njk2NTgiLCJkZWFkbGluZSI6IjExNTc5MjA4OTIzNzMxNjE5NTQyMzU3MDk4NTAwODY4NzkwNzg1MzI2OTk4NDY2NTY0MDU2NDAzOTQ1NzU4NDAwNzkxMzEyOTYzOTkzNSJ9LCJ0cmFuc2ZlckRldGFpbHMiOnsidG8iOiIweEMzZmRDNDg2RUVhNjNENzk2MGU1MENDNTQwOWZiZUE0MzRhNmZEZjMiLCJyZXF1ZXN0ZWRBbW91bnQiOiIxMDAwMDAwMDAwMDAwMDAwMDAwMDAifSwib3duZXIiOiIweGY4N2NhNDU4M0M3OTIyMTJlNTI3MjBkMTI3RTdFMEEzOEI4MThhRDEiLCJzaWduYXR1cmUiOiIweGUxNmNhZGIxOTQ3NjI0Njg3NmIyODVhMDM1YTY1ZDFhMjBiMTQ1OTAzZjI4NmNjZTRmYjE3ZjhjNWY2OWQxOWUyY2E2ZDVhOWFjMzJlNzYyYTBkN2E5MWU1YmE4Y2EzNDMwNTVjY2UzYWEyZDQ4NzY5OWZiYmY0NjQ2YzFiOTllMWIifQ==)

0xC3fdC486...434a6fDf3

Originally posted by @ubiquibot[bot] in ubiquity/business-development#48 (comment)

We should take any stepped component (example) and transform the config generation page to an onboarding wizard with 2 steps:

• Step 1: config generation page
• Step 2: setting allowance for permit2

What should be done:

1. Rename https://pay.ubq.fi/secret to https://pay.ubq.fi/onboarding
2. Remove unnecessary text fields from the config generation page (step 1)

• EC_PUBLIC_KEY
• ADVANCED_CONFIG

3. Add "safe address" text field to config generation page (step 1). We should add a text field for safe address here along with a URL to safe generation docs. This safe-address param should also be saved in the bot's config.
4. Add "chain id" text field to config generation page (step 1). We will use this param in wizard step 2 to distinguish what token to approve for permit2: DAI (for mainnet) or WXDAI (for gnosis chain). This chain-id param should also be saved in the bot's config.
5. Add wizard step to set permit2 allowance (step 2). This step is basically a single text field for allowance with an "approve" button. We know chain id (from step 1) so we know what token to approve(DAI for mainnet or WXDAI for gnosis chain). Allowance via an input box should be in normal human notation (not with the 18 zeros appended.)

So basically we are automating the onboarding: https://dao.ubq.fi/ubiquibot-setup