Create UI for UbiquityPool

[rndquu]

There is the new UbiquityPool contract (facet) where users can mint and redeem Dollar tokens for collateral tokens.

Minting example:

1. User calls mintDollar() and sends 95 LUSD + 5 Governance (UBQ) tokens worth 5 USD
2. User gets 100 Dollar tokens

Redeeming example:

1. User calls redeemDollar() and sends 100 Dollar tokens
2. User waits for 2 blocks to be mined
3. User calls collectRedemption() and gets 95 LUSD + 5 Governance tokens worth 5 USD back

We should create a new frontend (using https://github.com/ubiquity/ts-template) for the UbiquityPool contract and make sure it works with already deployed mainnet contracts.

Notice:

• The old UI may be found at https://uad.ubq.fi/ + its sources here
• Try to use CSS styles from the old UI defined here
• Make sure input validation and error handling are implemented

Since the UbiquityPool contract is forked from the FraxPoolV3 contract we can take the Frax UI as an example:

• mint page: https://old.app.frax.finance/mint
• redeem page: https://old.app.frax.finance/redeem

Mint:

Redeem:

[hydroxylase]

Is that all the functions you need?? mint and redeem??
That's it

[rndquu]

Is that all the functions you need?? mint and redeem?? That's it

Yes, I've also added this line to the original issue description:

Make sure input validation and error handling are implemented

[hydroxylase]

/start

[ubiquity-os]

Warning!	This task was created over 35 days ago. Please confirm that this issue specification is accurate before starting.
Deadline	Fri, Sep 20, 5:58 AM UTC
Beneficiary	0x229674f3db146E0AF0182b660F5c9232538E7e7b

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.

[hydroxylase]

Greetings.
Before starting off, must I use the ubiquity template this repo was built on for the next app? Or should I just create a new next app with yarn then add jest, cypress, ethers, eslint, cspell, and others? Would you prefer vaniallla JS with next or Next withTypescirpt

[hydroxylase]

@Keyrxng @rndquu

[rndquu]

Before starting off, must I use the ubiquity template this repo was built on for the next app? Or should I just create a new next app with yarn then add jest, cypress, ethers, eslint, cspell, and others?

@0x4007 I'm not really sure what's better here. On the one hand nextjs is perfect for complex UI interactions, on the other ts-template already has everything setup like cypress, cloudflare preview, etc... If uusd.ubq.fi is not going to be too complex (only mint/redeem + staking features) then, perhaps, it makes sense to go with ts-template and typescript.

[0x4007]

Honestly I prefer to make every view a separate page. And to keep it as simple as possible.

I know it's trendy to make a single page app that can handle millions of functions but I think it doesn't make sense for our goals.

So ts-template

[rndquu]

@CaptainPrinz hey

Before starting off, must I use the ubiquity template this repo was built on for the next app? Or should I just create a new next app with yarn then add jest, cypress, ethers, eslint, cspell, and others?

Sorry for the inconvenience, I've updated the issue description, pls use https://github.com/ubiquity/ts-template

Would you prefer vaniallla JS with next or Next withTypescirpt

Typescript

[0x4007]

Another approach to consider (I have done stuff like this before)

wget -r

And you can edit the compiled code and swap out the smart contract addresses for example. It might be a bit tricky for some folks but to get something up and running fast this could be the way. That could probably be done in an hour or two.

I suppose it just depends on how their code is compiled.

[ubiquity-os]

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

[hydroxylase]

Yet to commence work

…

On Fri, 20 Sep 2024, 22:26 ubiquity-os[bot], ***@***.***> wrote: @CaptainPrinz <https://github.com/CaptainPrinz>, this task has been idle for a while. Please provide an update. — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A7M52GYEN6D44ZFMD2MXX5LZXSHI7AVCNFSM6AAAAABMGYJQJKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRUGYZTSMZWHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[kingsley-einstein]

/wallet 0xb69DB7b7B3aD64d53126DCD1f4D5fBDaea4fF578

[ubiquity-os]

+ Successfully registered wallet address

[kingsley-einstein]

@0x4007 @rndquu

Can I still take up this task?

[kingsley-einstein]

@0x4007 @rndquu

Having a SPA for this task makes sense as it alleviates redundancy regarding certain components. For example, we only need to have one connect button instead of different ones per page.

[ubiquity-os]

Deadline	Thu, Oct 3, 1:24 AM UTC
Beneficiary	0xb69DB7b7B3aD64d53126DCD1f4D5fBDaea4fF578

Tip

• 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.

[kingsley-einstein]

/start

[ubiquity-os]

+ Successfully registered wallet address

[kingsley-einstein]

/wallet 0xb69DB7b7B3aD64d53126DCD1f4D5fBDaea4fF578

[ubiquity-os]

+ Successfully registered wallet address

[kingsley-einstein]

/start

[surafeldev]

/help

[zugdev]

I'll be taking this forward due to its urgency.

[ubiquity-os]

@zugdev the deadline is at Mon, Nov 11, 9:23 PM UTC

[kingsley-einstein]

@zugdev
Why was I unassigned? I already raised a PR. @rndquu

[kingsley-einstein]

@0x4007 @rndquu
I was unassigned from this task even though I had raised a PR, and effected all all requested changes.

[kingsley-einstein]

@zugdev
I don't understand why I was unassigned after I had raised a PR, and had made all the requested changes.

Here's the pull request: #3

[0x4007]

@rndquu decision for what to do. @zugdev based on my quick Look I imagine it might make sense to build off of what has been created already

[zugdev]

@0x4007 I started over, I just need to polish some UI/UX, but you are already able to mint and redeem. I will setup an approval flow using a dynamic action button for either step (minting or redeeming).

[0x4007]

I suppose for v1 this direction is appropriate but my vision is to really abstract all the technical and crypto details away. We can consider making another view/page for non crypto people.

Details like the slippage and being able to mint with pure LUSD seem technical.

Also we should allow for cowswapping in and out to any asset they want so they can "redeem" in any asset. If for some reason cow swap is too difficult to implement, as I recall from earlier discussions, we could consider using other protocols. Uniswap could be a default but maybe there are more interesting options like how spark protocol lets users swap between stables for free.

Generating a payment card might also be interesting on this "consumer UI" one day

Perhaps uusd.ubq.fi are for the hardcore people and banking.ubq.fi etc can be for the mainstream consumers etc

[zugdev]

Perhaps uusd.ubq.fi are for the hardcore people and banking.ubq.fi etc can be for the mainstream consumers etc

I see that as the distinction between this issue (pool) and #4 (on-ramp), I believe it is fine to have both. What's harder to integrate is not the swap, CoWSwap even offers a cool SDK. Guaranteeing order integrity as the backend discretely processes the entire order is the hard part, we could implement an orderbook system to ensure consistency. The good news is that what is used here can and will be used in the banking project, they are closely related.

[rndquu]

Ok, there're 2 PRs that solve the same issue:

• chore: initialize #3
• feat: add Ubiquity Pool UI #13

Regarding #3:

1. localhost is used everywhere (one, two, etc...), so this PR doesn't work with mainnet
2. The PR doesn't work for minting UUSD with LUSD+UBQ tokens because approval of UBQ tokens is missing (although LUSD approval is inplace)
3. There's also missing approval UUSD step on redeeming (at least I couldn't find it in the code)

Regarding #13:

1. Absense of LUSD/UBQ approves on minting
2. Absense of UUSD approves on redeeming
3. Here collectRedemption() is called right after redeemDollar() which will revert in most cases because of 2 blocks delay mechanism

Guys, pls thoroughly test the implementations. It takes quite a time to QA such PRs.

@zugdev Thank you for jumping in straight with a meaningful implementation but I would wait for #3 because:

1. @kingsley-einstein was the 1st one to be assigned
2. chore: initialize #3 meets the spec 95%
3. @kingsley-einstein is responsive for code updates

@kingsley-einstein Pls make sure that #3 works flawlessly in the shortest time possible. There've already been 3 rounds of QA reviews. Otherwise we'll proceed with #13.

[ubiquity-os]

@kingsley-einstein the deadline is at Fri, Nov 15, 3:51 PM UTC

[zugdev]

Regarding #13:

1. Absense of LUSD/UBQ approves on minting
2. Absense of UUSD approves on redeeming
3. Here collectRedemption() is called right after redeemDollar() which will revert in most cases because of 2 blocks delay mechanism

Yes I get that, the approval mechanism should be dynamic, that meaning you should always check if the diamond already has enough allowance for the transaction. We also want to have a multi-call to bundle the collateral and governance approvals together, this would save gas and another entire step on the minting flow. We should also check on the background for conditions which block minting/redeeming such as UUSD price or a paused pool, and stop the user before he wastes his time and money trying. FRAX does that with a modal:

[kingsley-einstein]

Ok, there're 2 PRs that solve the same issue:

• chore: initialize #3
• feat: add Ubiquity Pool UI #13

Regarding #3:

1. localhost is used everywhere (one, two, etc...), so this PR doesn't work with mainnet
2. The PR doesn't work for minting UUSD with LUSD+UBQ tokens because approval of UBQ tokens is missing (although LUSD approval is inplace)
3. There's also missing approval UUSD step on redeeming (at least I couldn't find it in the code)

Regarding #13:

1. Absense of LUSD/UBQ approves on minting
2. Absense of UUSD approves on redeeming
3. Here collectRedemption() is called right after redeemDollar() which will revert in most cases because of 2 blocks delay mechanism

Guys, pls thoroughly test the implementations. It takes quite a time to QA such PRs.

@zugdev Thank you for jumping in straight with a meaningful implementation but I would wait for #3 because:

1. @kingsley-einstein was the 1st one to be assigned
2. chore: initialize #3 meets the spec 95%
3. @kingsley-einstein is responsive for code updates

@kingsley-einstein Pls make sure that #3 works flawlessly in the shortest time possible. There've already been 3 rounds of QA reviews. Otherwise we'll proceed with #13.

@rndquu

All missing criteria have been satisfied.

[kingsley-einstein]

/start

[ubiquity-os]

! You are already assigned to this task.