Mint card for Ubiquity Dollars

[rndquu]

This PR introduced a feature of card minting.

How it works:

1. Contributor opens pay.ubq.fi to redeem our "standard" permit reward
2. Contributor sends permit reward to the treasury address
3. Contributor sends transaction hash to the pay.ubq.fi backend
4. A new reloadly gift card is minted to the contributor

Any user with Ubiquity Dollars should be able to mint a gift card (not only the ones with ready to use permits).

What should be done:

• create a new page (for example pay.ubq.fi/cards) where users will be able to send Ubiquity Dollars to the treasury address and get reloadly gift cards in return

Notice:

1. Gift cards feature is located in a separate branch so it makes sense to open a PR towards that branch
2. Try to minimize backend code changes in order not to complicate it further

[pbkompasz]

/start

[ubiquibot-dev]

Deadline	Thu, Aug 8, 4:03 PM UTC
Registered Wallet	0x26BfbD8ED2B302ec2c2B6f063C4caF7abcB062e0

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.

[ubiquity-os-main]

Deadline	Thu, Aug 8, 4:03 PM UTC
Registered Wallet	0x26BfbD8ED2B302ec2c2B6f063C4caF7abcB062e0

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.

[ubiquibot]

Deadline	Thu, Aug 8, 4:03 PM UTC
Registered Wallet	0x26BfbD8ED2B302ec2c2B6f063C4caF7abcB062e0

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.

[pbkompasz]

@rndquu I have an MVP that is ready (~80%) and works locally on fixed and custom priced gift cards.
In this MVP the "standard" permit is built by a script and is passed as a query parameter to the frontend. In production how will this happen? Will a permit be generated on the spot for each page visit in permit-generation that can be fetched from the Supabase database?

[0x4007]

@rndquu I have an MVP that is ready (~80%) and works locally on fixed and custom priced gift cards. In this MVP the "standard" permit is built by a script and is passed as a query parameter to the frontend. In production how will this happen? Will a permit be generated on the spot for each page visit in permit-generation that can be fetched from the Supabase database?

@EresDev rfc

[EresDev]

@rndquu I have an MVP that is ready (~80%) and works locally on fixed and custom priced gift cards.
In this MVP the "standard" permit is built by a script and is passed as a query parameter to the frontend. In production how will this happen? Will a permit be generated on the spot for each page visit in permit-generation that can be fetched from the Supabase database?

There are tools included with this repository to generate a permit for testing. yarn start from beta branch generates a permit but it needs some setup. In production, we don't care about how permit is generated. For us, user visits the page with permit in query parameter https://pay.ubq.fi/?claim=[permit base64 encoded]. We can just use it here or if needed it can be passed to /cards page as query parameter.

But just for info, permit is generated by ubiquibot in its permit-generation plugin on a specific github event, which is when an issue is closed on a successful merge of a PR that solves that issue.

[rndquu]

@pbkompasz

Will a permit be generated on the spot for each page visit in permit-generation that can be fetched from the Supabase database?

How permit generation works:

1. Github issue is closed
2. The bot generates a permit (example). Permit is simply a json data with signature. The bot owns an ethereum wallet from which the bot signs uniswap permits which can be redeemed by contributors at pay.ubq.fi.

As EresDev already stated simply run yarn start and you'll get an example ERC20 permit URL ready to use at pay.ubq.fi with the local anvil instance.

In this MVP the "standard" permit is built by a script and is passed as a query parameter to the frontend. In production how will this happen?

In the context of the "Mint card for Ubiquity Dollars" feature you don't need permits at all unless I'm missing smth. In the pay.ubq.fi/cards page user pastes in some text input how much of available Ubiquity Dollars he want to exchange for a gift card and all of it is then handled on the backend. Our standard permits don't seem to be used anywhere here.

[ubiquity-os]

@whilefoo the deadline is at Sat, Sep 21, 4:18 PM UTC

[whilefoo]

@rndquu do ubiquity dollars need to be sent to the treasury wallet?

[0x4007]

@EresDev requested I make a brand new wallet for it- something about a clean transaction history.

I would guess that a smart contract would be considered more professional but I think for now there are no functional differences.

Unfortunately I can't find the wallet I made for it yet. I suppose we can always make a new one.

[EresDev]

@rndquu do ubiquity dollars need to be sent to the treasury wallet?

There is a treasury wallet used only to receive payments for minting card. It is not used for any other purpose.

Unfortunately I can't find the wallet I made for it yet. I suppose we can always make a new one.

The one you gave me as the treasury wallet for cards was
https://github.com/ubiquity/pay.ubq.fi/blob/bb5ec42adb3b9947cd49c8f815d528d12b431a4e/shared/constants.ts#L7C41-L7C83

[whilefoo]

Where do I get reloadly sandbox api keys?

[rndquu]

Where do I get reloadly sandbox api keys?

DMed you in telegram

[ubiquity-os]

@whilefoo, this task has been idle for a while. Please provide an update.

[whilefoo]

The plan is:

• User enters the amount in Ubiquity dollars in the input field
• User clicks 'Check gift card'
• The best available card is presented and user can click 'Mint card'
• The frontend initiates a ERC20 transfer to a special address owned by Ubiquity (or it can be a smart contract later)
• User accepts the transaction and the tx hash is written to the local storage
• User signs a message with the tx hash confirming it is the owner of the wallet
• Frontend sends the tx hash and signed message to the backend
• Backend orders a card and transaction id of the order is added to the tx hash in the local storage
• The frontend keeps checking if the card is ready to redeem
• When the card is ready to redeem, the user must sign a message again to claim the card
• Backend checks the signed message and returns the redeem code

All the steps write in the local storage because the user can refresh the page or something goes wrong in the process. At the bottom of the page the history will be displayed with all cards ordered or claimed

[0x4007]

At the bottom of the page the history will be displayed with all cards ordered or claimed

Need to reduce clutter in UI. Should focus on instantly removing the cards from UI once they are imported to Apple Pay etc

[whilefoo]

Need to reduce clutter in UI. Should focus on instantly removing the cards from UI once they are imported to Apple Pay etc

We can remove the cards from the history if the redeem code was revealed but that doesn't guarantee that they already imported it to Apple Pay

[0x4007]

That AND a seven day timeout should guarantee no problems

[ubiquity-os]

@whilefoo, this task has been idle for a while. Please provide an update.

[whilefoo]

Ah it looks like I was unassigned. Maybe we could add a feature if the issue has a linked PR that has been merged, it should assign the user to the issue and close it?

What's also interesting that even though I specified Resolves # it didn't mark it as a linked PR

[ubiquity-os]

@whilefoo the deadline is at Tue, Oct 15, 7:56 AM UTC

[0x4007]

Ah it looks like I was unassigned. Maybe we could a feature if the issue has a linked PR that has been merged, it should assign the user to the issue and close it?

That probably makes sense!

What's also interesting that even though I specified Resolves # it didn't mark it as a linked PR

I'm not sure why but I have seen this rarely.

[rndquu]

What's also interesting that even though I specified Resolves # it didn't mark it as a linked PR

I suppose that's because #313 targets a none default branch of the https://github.com/ubiquity/pay.ubq.fi repo

[rndquu]

This issue should be closed as completed in #313, correct?