Already Claimed Permit Proof

[0x4007]

When the permit has been claimed, be sure to show proof that the contributor already claimed it by posting the blockchain explorer's claim transaction link.

---

          > now I checked again and I claimed the permit.

I think we really should show proof that the permit was claimed because I grow tired of addressing this exact same complaint.

Originally posted by @pavlovcik in #124 (comment)

[evanjonesxx]

/start

[ubiquibot]

Deadline	Thu, 30 Nov 2023 11:11:56 UTC
Registered Wallet	0xe2111B76461BE1f3Df2E364Be1b18aAB9e4D2469

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.

[barebind]

I don't see any possible way to show proof of claimed permit(i.e txid) without using a separate db.
PermitTransferFrom emit only a normal ERC20 Transfer event. Is it possible to filter it out from blockchain without event logs?

Reply protection(claimed-or-not-state) is provided via nonce usage on Permit2 contract which is already being checked before sending the transaction. (After #149 is fixed.)

[0x4007]

I don't see any possible way to show proof of claimed permit(i.e txid) without using a separate db.

Yes in another old specification when I was refactoring the database, I created a table that corresponds to permits. One column in the table is supposed be be called claimed. It is either null or a link to the transaction on the block explorer.

The idea here is to let the UI display the already claimed transaction link if it exists. Or to get the transaction ID and generate + post the link back to the database as soon as the claim button is hit.

---

It would be great to use the blockchain as our only dependency (like using event logs) but we couldn't come up with any ideas the first time around. New ideas are always appreciated, feel free to brainstorm here.

[barebind]

Can you throw me a reference/example for db usage in pay.ubq.fi @pavlovcik ? Couldn't find anything other than godb/indexeddb on audit pages.

[0x4007]

It is currently not implemented in pay.ubq.fi. The only plan for interaction with our database is just that claimed column!

[barebind]

I should check the database usage I think. Let me go through other repos and see how it's used, db schema etc.

[0x4007]

I don't think it's worth studying the database too closely because the schema is in flux but here is the current version.

The location table is going to be removed as it overcomplicates and isn't useful.

I want to replace all that with a single new column in each table that will be the URL of interest (if any) for the row (for example a URL to a comment which set the wallet address, for auditing purposes.)

[ubiquibot]

# No linked pull requests to close

[0x4007]

By the way @barebind, I am back at my computer this week and had a chance now to review the database. The column already exists under the permits table as transaction string and this is nullable.

I can add you to the supabase if you Telegram DM me your Supabase email!

[barebind]

I've never used supabase before so let me check it and sign up first. I'll dm you from telegram!

[barebind]

/wallet 0x91e6aF5A1E6a530d60949e1438036A4741B80D22

[ubiquibot]

+ Successfully registered wallet address

[barebind]

/start

[ubiquibot]

Warning!	This task was created over 160 days ago. Please confirm that this issue specification is accurate before starting.
Deadline	Thu, Feb 22, 7:48 AM UTC
Registered Wallet	0x91e6aF5A1E6a530d60949e1438036A4741B80D22

Tips:

• Use /wallet 0x0000...0000 if you want to update your registered payment wallet address.
• 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 task.

[barebind]

is nftPermit an active feature? if so is it saved to the same permits table on supabase?

[0x4007]

is nftPermit an active feature? if so is it saved to the same permits table on supabase?

I think we have it partially implemented on pay.ubq.fi UI but not with the database or even with the bot. We are working on it for a grant from another crypto company.

rfc @rndquu @whilefoo

[rndquu]

As far as I remember @whilefoo implemented this feature a while ago. Are NFT rewards saved to a supabase DB?

Overall in order to find a matching claim tx for a particular permit we need to fetch all txs for the partner wallet's address. This is a long running task so putting it on the bot's side is not really optimal. Perhaps it makes sense to make a separate script that runs on github action schedule (once an hour/day ?) that periodically fetches all txs onchain and assigns the permits.transaction field.

[0x4007]

assigns the permits.transaction field.

I think it makes a lot more sense to handle this from the pay.ubq.fi UI. As soon as the claim button is clicked, it will write the transaction hash to our database. We can sanitize it with a simple regex to ensure its a transaction hash.

[barebind]

I think it makes a lot more sense to handle this from the pay.ubq.fi UI

I've implemented this on the pay.ubq.fi UI side already. basically querying the permit with it's nonce(hence unique) and update the transaction hash of it after the tx is confirmed.

would that satisfy the requirement?

[0x4007]

I think it makes a lot more sense to handle this from the pay.ubq.fi UI

I've implemented this on the pay.ubq.fi UI side already. basically querying the permit with it's nonce(hence unique)

What do you mean? How is this implemented?

As far as I'm aware we can only check if the nonce is available or not in the permit contract's bitmap. Whether or not the permit was generated for that nonce is not available information.

A permit can be generated but not claimed yet and the nonce would still be available.

So of course when a permit is generated we would need to also store in our database to have a full picture of the state of the contributor's payment. States:

1. Not created; not claimed
2. Permit generated; not claimed
3. Permit generated; claimed

[rndquu]

assigns the permits.transaction field.

I think it makes a lot more sense to handle this from the pay.ubq.fi UI. As soon as the claim button is clicked, it will write the transaction hash to our database. We can sanitize it with a simple regex to ensure its a transaction hash.

In order to write smth to a supabase's DB we either need to setup RLS in a proper way (not sure if it is possible to allow only certain users to write only to certain fields in the DB) either create a separate backend API which will be responsible for such write operations (which we plan to implement here).

[0x4007]

I think it's low priority to set it up "the proper way" if it is challenging to set up RLS for this because there is little incentive for a grifter to click on other permits (before they are claimed) and hack the UI to save an incorrect transaction hash.

Besides if there's anything suspicious happening and we need to get involved, we can always review the on chain data.

Beyond that we could make a simple API to validate that the origin of the transaction indeed is the registrants wallet address.

---

Given all of the RPCs we have access to now (also sorted by speed) it may now be viable to check the onchain data upon page load to search for that claim transaction. I might take some time to implement a prototype of this over the weekend.

This could hold us over until we do things the proper way. Fortunately it doesn't require the database as a dependency which can make it simpler to set up and maintain.

[0x4007]

ChatGPT estimates that we can make it near realtime to check permit claims for most cases (claimed within 12 hours of posting) with the right strategy. You can scroll to the bottom of the conversation to see the conclusion:

https://chat.openai.com/share/0bfb5b8e-eb8c-4f8e-827d-16f5ac8cf3e2

I think this could be a useful standalone module we create that can run from the pay.ubq.fi UI and the audit UI.

[0x4007]

I might take some time to implement a prototype of this over the weekend.

As much as I am very interested to take a crack at this, I am running out of development time leading up to 1 March. Then I'll need to focus most of my time on fundraising efforts and opening up the local office. I'm assuming the RPC thing isn't really a top priority from the perspective of card issuance.

[barebind]

What do you mean? How is this implemented?

As soon as the claim button is clicked, it will write the transaction hash to our database.

I meant I've implemented this part in the PR already. writing the transaction hash to database when the claim button is clicked. I've used nonce for querying/selecting permit from DB only. it has unique key on db schema so I used that.

[barebind]

I think we have it partially implemented on pay.ubq.fi UI but not with the database or even with the bot. We are working on it for a grant from another crypto company.

If nftPermit is not one of the requirements for this issue, I think the task is completed and PR can be reviewed.

[0x4007]

I think we have it partially implemented on pay.ubq.fi UI but not with the database or even with the bot. We are working on it for a grant from another crypto company.

If nftPermit is not one of the requirements for this issue, I think the task is completed and PR can be reviewed.

Cool! Normally in this case you would convert your pull request from a "draft" to a finalized pull request.

[barebind]

Just wanted to double-check what is needed :)

[barebind]

I think we can close this issue too as #187 serves to the same purpose and #172 is closed. what do you think @pavlovcik ?

[ubiquibot]

# Issue was not closed as completed. Skipping.