feat: rpc upgrade

[Keyrxng]

Relates to ubiquity/.github#100

• removed chainlist submodule
• import constants from package from constant.ts
• create hook for use handler
• temp fix to avoid error with ens lookup but expect that it'll need address once the UBQ RPCs are back up

using my package for sake of dev but once published I'll swap it out

[0x4007]

Seems mostly fine but there were a lot more changes than I expected around the ENS lookup.

[Keyrxng]

Seems mostly fine but there were a lot more changes than I expected around the ENS lookup.

The only reason being is because the UBQ RPCs are offline atm, I'll revert the changes back once those are back online if that's preferred

[molecula451]

do you think this can help on #217 @Keyrxng ?

[Keyrxng]

do you think this can help on #217 @Keyrxng ?

No it won't, you are correct we need to see mobile debug logs to see why the tx is failing.

The confusion it seems, is that all of the previous RPC issues and PRs have nothing to do with writing a tx on-chain. Allowance and BalanceOf are the only two functions which the 'optimized RPCs' affect.

The original need to optimize them came from the UI loading times which were significantly improved between myself and pav addressing CSS and unneeded fetch calls as well as preventing a UI glitch when any failed calls happened

[rndquu]

@Keyrxng Could you:

1. Fix merge conflicts
2. Use https://www.npmjs.com/package/@ubiquity-dao/rpc-handler

[Keyrxng]

Love to see it!

• polymorphic with improved exports rpc-handler#6

This PR improves the rpc-handler a lot, specifically it being used in other projects.

I've broken the PR into two, one for the tests and one for the polymorphic exports.

Because it introduces breaking changes via improved type exports it's probably best to update the rpc-handler first.

[rndquu]

Love to see it!

• polymorphic with improved exports rpc-handler#6

This PR improves the rpc-handler a lot, specifically it being used in other projects.

I've broken the PR into two, one for the tests and one for the polymorphic exports.

Because it introduces breaking changes via improved type exports it's probably best to update the rpc-handler first.

https://www.npmjs.com/package/@ubiquity-dao/rpc-handler is updated

Now you're free to:

1. Fix merge conflicts
2. Use https://www.npmjs.com/package/@ubiquity-dao/rpc-handler

[ubiquity-os-deployer]

9e35444

2f30744

a31dbbe

f09e3da

[Keyrxng]

I've rerun the tests after each commit without error after updating the RPC endpoint. Could that workflow be run again with debug logging enabled pls

[gentlementlegen]

I've rerun the tests after each commit without error after updating the RPC endpoint. Could that workflow be run again with debug logging enabled pls

Are you talking about the Cypress test workflow?

[Keyrxng]

I've rerun the tests after each commit without error after updating the RPC endpoint. Could that workflow be run again with debug logging enabled pls

Are you talking about the Cypress test workflow?

I was @gentlementlegen, I haven't seen the nonce too low locally or otherwise before I don't think. The workflow is succeeding in another pull so it's likely a blip, could you fire it again with debug enabled and we'll see if it repeats it

• Fix infinite load on non-web3 friendly browsers #221 (comment)

[gentlementlegen]

@Keyrxng https://github.com/ubiquity/pay.ubq.fi/actions/runs/9216125552/job/25421514595

[github-actions]

Preview Deployment
2f3074409b302e86d752105fc715368dceb50be3
a31dbbe81623963ec9c9b1ec5fb5323b0efa2a0a
f09e3da2f5f2b413a2a6746c2ecc1502ce0065a4

[Keyrxng]

race conditions avoided with a wait step added to the workflow which I'm sure should prevent the nonce too low error from happening again

[rndquu]

Works fine, RPC provider is fetched from https://www.npmjs.com/package/@ubiquity-dao/rpc-handler

[gentlementlegen]

Works for me too, please fix conflicts.

[Keyrxng]

good to go

[rndquu]

@Keyrxng Tests in the development branch are failing after this PR is merged, could you fix it?

[rndquu]

@Keyrxng Should we close ubiquity/.github#100 as completed?

[molecula451]

great work @Keyrxng

[Keyrxng]

-32003: nonce too low error again. I'm best guessing that the error is because one of the later tx's in the command is completing before an earlier one.

We could break apart the funding command into distinct steps and have a workflow step for each with a hardcoded wait in between.

Or a new script to handle the funding actions separately, waiting between each action and confirming it's affect?

Locally anvil.ts handles funding but it only handles the server instance in a workflow, so the workflow uses a yarn command to fund.

---

Since tests should be infallible I guess a couple error prone points should be taken care of:

• anvil instance fails to launch due to RPC failure (happens locally from time-to-time, haven't seen it in a workflow run yet)
• funding txs are fired in sequence with a retry mechanism in case of nonce too low or some other error
• funding affect validation as it'll break tests if the funding address is double funded for example

[Keyrxng]

@Keyrxng Should we close ubiquity/.github#100 as completed?

• upgrade rpc logic 0x4007/uad.ubq.fi#3

this is still open and this is the prod staking repo I'm sure so I'll tie this up and then it can be closed