Payouts v2

[rndquu]

We have plans to support:

1. Payouts to crypto wallets (we use them already)
2. Payouts to virtual and physical bank cards
3. Redeeming NFT rewards

It makes sense to redo the pay.ubq.fi page into a "single payouts dashboard" from a collaborator's point of view.

User stories which we should support:

1. As a contributor I want to connect a crypto wallet to have access to the payout dashboard
2. As a contributor I want to see the rewards amount
3. As a contributor I want to see a list of NFT rewards
4. As a contributor I want to get rewards to a crypto wallet
5. As a contributor I want to get rewards to a virtual card

This is a draft wireframe: https://www.figma.com/file/vdjASBTDbYBFmL7CtAYXwM/Payouts-v2?type=whiteboard&node-id=0%3A1&t=uWa3OMqLSCoOvkDG-1

[0x4007]

We have plans to support:

1. Payouts to crypto wallets (we use them already)
2. Payouts to virtual and physical bank cards
3. Redeeming NFT rewards

It makes sense to redo the pay.ubq.fi page into a "single payouts dashboard" from a collaborator's point of view.

I think replicating an online bank login would be a comfortable user experience. This is where you can see your balance and card details. Beyond that we can consider adding charts/graphs/analytics so that the user can feel proud of the work they have done and how much they have earned over time.

This is also an easy opportunity to "unlock" simple capabilities of the UI with higher XP etc.

User stories which we should support:

1. As a contributor I want to authenticate via github to have access to the payout dashboard

I don't see why GitHub would be mandatory to login to pay.ubq.fi. I think its more futuristic to login with your wallet instead. Perhaps for convenience sake we can also support GitHub login but that I think should come in second, unless we require increased authentication limits for the GitHub API.

2. As a contributor I want to see the rewards amount
3. As a contributor I want to see a list of NFT rewards
4. As a contributor I want to get rewards to a crypto wallet
5. As a contributor I want to get rewards to a virtual card

This is a draft wireframe: https://www.figma.com/file/vdjASBTDbYBFmL7CtAYXwM/Payouts-v2?type=whiteboard&node-id=0%3A1&t=uWa3OMqLSCoOvkDG-1

I left a couple of comments.

I think we should encourage or create some type of system to allow partners to automatically disperse payments to the contributors. I already have an idea for it where we can add a ubiquibot-config.yml property for payments which would be transfer: boolean;. Given that we already have private key access, it is trivial to call transfer instead of generating a permit. I have more information on this in the new Permit Generation Module readme.

There's certainly pros and cons to enabling transfers.

• For example, I like the ability to retract generated payments if something unexpected happened with the calculations (especially relevant during our rapid r&d phase) by deleting the permit comment before it is claimed.
• Also, as per the original reason why we implemented permits, its very nice for projects to not have to pay the transfer fee.

However if there is a "convenience fee" (ideally one that the contributor opts in to) then Ubiquity can host the transfer relay service and make some small fees along the way for facilitating the payments. Transfers would certainly yield a superior user experience for the contributors.

Notes:

1. It makes sense to move our claim reward page from pay.ubq.fi to somewhere like pay.ubq.fi/claim-crypto
2. Perhaps there will be one more page or input to select a collaborator's country of residence since we are allowed to issue virtual and physical cards only to collaborators who reside in the country where ubiquity org business is registered.

I think it would be more elegant to geolocate the country based on IP and then prompt with a modal. Sure there may be edge cases with VPN users, but those same users going out of their way to mask their IP can very likely figure out that by using the default settings, you can sign up.

3. This is a meta issue, I will break it down further

@ubiquity/software-development Feedback is welcome for the following question:

• We definitely need some backend (cloudflare worker?) with API endpoints for getting virtual card balances, issuing cards, etc... Should we refactor the current repo to be a monorepo (that hosts both frontend and backend) or move the backend to a separate repo? I think for ease of debugging we should simply use a new repo for backend.

I am a firm believer that we should split everything into smaller repos.

[rndquu]

I don't see why GitHub would be mandatory to login to pay.ubq.fi.

Yes, we can simply auth via crypto wallet

I think it would be more elegant to geolocate the country based on IP and then prompt with a modal.

+1

I think we should encourage or create some type of system to allow partners to automatically disperse payments

We'll leave the "disperse payments" feature for the next iteration. Right now we should cope with virtual cards.

[0x4007]

We'll leave the "disperse payments" feature for the next iteration.

A little off topic but I realize that if a contributor stakes some idle asset they are bullish on (i.e. UBQ) we can call transferFrom to withdraw uUSD from their wallet to make spending on their cards seamless. If we detect some tampering with the balance, then we can withdraw the staked assets etc.

It is sort of like a one block (~13 second) loan that the system automatically settles by the next block.

---

If we really wanted to incentivize staking for some reason (e.g. make number go up) we can consider dispersing liquidation bonuses but this would certainly require more thought because I'm uncertain of how frequently this would even occur.

[whilefoo]

If we are rewriting pay.ubq.fi it'd make sense to consider using a framework like React to make development much easier -currently this repo is a pain to maintain

[0x4007]

In my refactor I broke apart most of the functions into separate files which makes it easier to work on.

I think react makes sense for single page apps with tons of views.

pay.ubq.fi should only have a single view. React bears significant overhead and gets in the way more than it helps for single view applications.

[molecula451]

If we are rewriting pay.ubq.fi it'd make sense to consider using a framework like React to make development much easier -currently this repo is a pain to maintain

I highly disagree, i'm seen unloaded websites using React, i understand you might like React (i do too) but it bears it's complexity, but if we go with it, i'm good too

I think we should give a chance to https://kit.svelte.dev/docs/adapter-static for static generation, and it's smoothly fast, a bit of tailwind CSS to beautify and enhance the UX

We definitely need some backend (cloudflare worker?) with API endpoints for getting virtual card balances, issuing cards, etc... Should we refactor the current repo to be a monorepo (that hosts both frontend and backend) or move the backend to a separate repo? I think for ease of debugging we should simply use a new repo for backend.

I'm seeing to much bear rely on cloudfare, perhaps we may consider explore other alternatives, what about a full VPS to manually enable all the stuf, would need to asses cloudfare advantages, we may still explore others alternatives

I do not think we should conver this one to a full monorepo, i'm in favor of separate stuff with a clear documentation on how the things connect

Notes:
It makes sense to move our claim reward page from pay.ubq.fi to somewhere like pay.ubq.fi/claim-crypto

Perhaps there will be one more page or input to select a collaborator's country of residence since we are allowed to > > issue virtual and physical cards only to collaborators who reside in the country where ubiquity org business is > registered.
This is a meta issue, I will break it down further

Good but i'm in f avor of claim-crypto.pay.ubq.fi/

[whilefoo]

With a framework there's a clear separation into components which include HTML, JS and CSS related to the component. There's also awesome tools like https://wagmi.sh/ which make working with Ethereum RPC really easy.

I enjoy the reactivity and components aspect of frontend frameworks as it's much easier to reason about and development is much easier than vanilla JS.

But that's just my 2 cents.

[molecula451]

With a framework there's a clear separation into components which include HTML, JS and CSS related to the component. There's also awesome tools like https://wagmi.sh/ which make working with Ethereum RPC really easy.

You know that react is not a full framework like angular, it's just a JS library, the difference is important, anyway, i vouch too, as long as it won't become a whole complexity with just a single static page

[rndquu]

How payouts are going to work:

1. When a contributor solves some issue worth 100 WXDAI then we simply tally up his total reward in a DB
2. Contributor opens pay.ubq.fi
3. Contributor clicks on "Payout to crypto" which calls our backend server, sets contributor's DB balance to 0, generates a new permit worth 100 WXDAI and saves the permit in a DB
4. Meanwhile we also generate (if certain conditions are met, like county residence) a new virtual card for a contributor which is authorized to spend funds up to 100 WXDAI (which is contributor's current reward balance)

We need this mechanic of generating permits / setting balance to 0 and decreasing the reward balance on bank card transactions in order to prevent a double spending (when user clicks on "Payout to crypto" and makes a payment with virtual card simultaneously).

[0x4007]

How payouts are going to work:

1. When a contributor solves some issue worth 100 WXDAI then we simply tally up his total reward in a DB

The database schema I designed is intended to be "ledger style"

• The users final balance is computed every time they need it (no caching)
• the inputs are every debit and credit the user received
• we can cache results (or not) in some years whenever a user accrues tens of thousands of transactions and it's slow to do simple math

2. Contributor opens pay.ubq.fi

3. Contributor clicks on "Payout to crypto" which calls our backend server, sets contributor's DB balance to 0, generates a new permit worth 100 WXDAI and saves the permit in a DB

4. Meanwhile we also generate (if certain conditions are met, like county residence) a new virtual card for a contributor which is authorized to spend funds up to 100 WXDAI (which is contributor's current reward balance)

I really wish that we can top up an existing card balance. This would be a much better user experience.

We need this mechanic of generating permits / setting balance to 0 and decreasing the reward balance on bank card transactions in order to prevent a double spending (when user clicks on "Payout to crypto" and makes a payment with virtual card simultaneously).

[rndquu]

@pavlovcik I've updated the description

I think we can simply assign this issue to somebody who's available (@FernandVEYRIER @barebind @molecula451 ) and is willing to solve a high priority issue

I would set a 1 week time estimate with medium or high priority

[molecula451]

I would set a 1 week time estimate with medium or high priority

i think it's best you divide this task in meta issues to properly accomplish it

[molecula451]

i checked the figma, i think more comments and hints are required on the figma

[molecula451]

Update: Task #171 clarifies that this repository won't be a "monorepo". It will solely serve as a static site for managing payout permits, enhancing our existing one.

[rndquu]

I would set a 1 week time estimate with medium or high priority

i think it's best you divide this task in meta issues to properly accomplish it

Unfortunately stripe has rejected our application for virtual cards issuing, I will break it down further when we find a new virtual cards API provider

[rndquu]

@gentlementlegen @0x4007

Pls check the updated wireframe: https://www.figma.com/file/vdjASBTDbYBFmL7CtAYXwM/Payouts-v2?type=whiteboard&node-id=0-1&t=m42vnzgVbLDyenEN-0

It implies that all permits (along with virtual cards) are generated only when user requests them, not when github issue is closed as completed.

As a virtual cards provider we decided to use https://docs.reloadly.com/ gift cards because:

1. It is (almost) the only company that work with "small-scale" crypto companies
2. They support gift cards in the form of virtual bank cards
3. Their virtual cards work in Google/Apple wallets
4. They gave us production API access

In the nearest future we'll shift to a proper virtual cards provider.

How it works when user withdraws in crypto:

1. User clicks the "withdraw" button
2. User selects the "crypto" dropdown and types the amount to withdraw
3. User click on "Withdraw"
4. Some backend service for pay.ubq.fi generates a permit (the same one we generate now) in a DB for the desired amount
5. The newly generated permit is shown in the UI

How it works when user withdraws to a virtual card (which has an upper limit of 1000 USD):

1. User clicks the "withdraw" button
2. User selects the "virtual card" dropdown and types the amount to withdraw up to 1000 USD
3. User click on "Withdraw"
4. Some backend service for pay.ubq.fi calls https://docs.reloadly.com/gift-cards/Orders/Order-Gift-Card and generates a gift card (depending on user's country, not all countries support Visa/MasterCard gift cards)
5. Card details are saved in a DB
6. The newly generated gift card is shown in the UI
7. User clicks "Full info" to show full card details
8. User finds out the redeem code for the gift card
9. User goes to https://myprepaidcenter.com/, enters the redeem code and get full details of the bank/gift card

P.S. NFT rewards are still generated and saved in a DB when github issue is closed

[gentlementlegen]

@rndquu Looks great. So if I understand properly, whenever the issue is closed, eventually the user would have to go through the dashboard to make the generation happen? And if so, where would that dashboard be (as in is it a completely new project we should develop or would it be created within an existing project)?

[rndquu]

@gentlementlegen

So if I understand properly, whenever the issue is closed, eventually the user would have to go through the dashboard to make the generation happen?

Yes

And if so, where would that dashboard be (as in is it a completely new project we should develop or would it be created within an existing project)?

As far as I understand this payout dashboard should be opened instead of our "standard" permit claim page at https://pay.ubq.fi/ (@0x4007 might know better)