Unused dependencies (4)

Unused devDependencies (2)

Should I force UUSD or should I offer an input field for token. If I should force, what about chains where UUSD is not at currently? I've included all permit2 chains I could, for now.

There should be a separate input for a token. When mainnet or gnosis is selected the UUSD should be set in the input token field by default but user should have the ability to change the token address.

I don't want to have user authenticate with GitHub, it's an unnecessary step, but if I did I could read what chain he has payments setup in. Is there a way to read what token he is using as reward too? If that was the case I should consider adding GitHub auth.

Check this comment. Overall github auth is not necessary as a part of the current github issue and can be solved in another PR.

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

1. Should I force UUSD or should I offer an input field for token. If I should force, what about chains where UUSD is not at currently? I've included all permit2 chains I could, for now.

I wonder if it makes sense for us to bridge over to as many chains as we can. I suppose anybody can do this and we just need to aggregate the addresses.

2. I don't want to have user authenticate with GitHub, it's an unnecessary step, but if I did I could read what chain he has payments setup in. Is there a way to read what token he is using as reward too? If that was the case I should consider adding GitHub auth.

This is actually determined by the partner project currently. So in theory we could have partner A, B, and C and each pays with their own preferred token on their own preferred chain. This is because they need to fund their wallets with whatever asset they want.

3. I am waiting on the above to integrate ethers.

I think aside from providers that's it. I need to find a smart way to use providers in all 10+ chains, why don't we use Alchemy or some service like that?

yarn start prints wrong ip

It's not a wrong ip, 0.0.0.0 means all available network interfaces including localhost. Though it's not something I've set myself.

Interesting. Makes it accessible to all devices in the network. I can run it on my PC and phone without any extra config. Cool

@rndquu @0x4007

Using @reown/appkit for wallet connection is a major change I think. We use ethers.js in pay.ubq.fi. If we are going to use @reown/appkit here, it will be expected everywhere else too. Looks cool though. Card minting expects token to be USD equal and also card minting needs transaction confirmation with certain checks that may vary across networks. It will need testing and probably some enhancement for each network.

Also, existing onboard page is in light mode, this one is in dark mode. I also couldn't find support for both dark/light modes in template. Looks like we are sticking with one for now.

@reown/appkit is used only for wallet connection and saves tremendous amount of time while ethers.js is still used for onchain interactions, seems fine.

Regarding the dark/light theme, this was not in scope for this task, so sticking to only the dark one is also fine.

Regarding the changes:

1. Getting the same error on "approve" button click
2. These fixes should be applied
3. Alchemy RPC nodes should be removed
4. CI should be passing

Since e2e tests and responsive CSS were not in the initial task scope it makes sense to increase the estimated time to <1 Day.

@zugdev Overall looks good. Pls fix the above comments.

I also get the same error as rndquu and EresDev

{\"jsonrpc\":\"2.0\",\"id\":152,\"error\":{\"code\":32601,\"message\":\"the method eth_sendtransaction does not exist/is not available\"}}", error={"code":32601}, requestBody="{\"method\":\"eth_sendTransaction\",\"params\":[{\"gas\":\"0xb54e\",\"from\":\"0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266\",\"to\":\"0xe91d153e0b41518a2ce8dd3d7944fa863463a97d\",\"data\":\"0x095ea7b3000000000000000000000000000000000022d473030f116ddee9f6b43ac78ba30000000000000000000000000000000000000000000000056bc75e2d63100000\"}],\"id\":152,\"jsonrpc\":\"2.0\"}"

It seems that it's trying to send a transaction using eth_sendTransaction which accepts an unassigned tx and assumes that the RPC node will sign the transaction, we should just use user's wallet to send the transaction instead

thanks for the input guys, very valid. I kinda disagree with needing an e2e test set, cause it's just a mere approve() transaction, can we reconsider it? transactions weren't going through cause reown isn't properly injecting pk into signer, I have changed to capture injected wallet (standard window.ethereum stuff)

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