Upgrade RPC Logic

[0x4007]

@Keyrxng you think you can swap out the logic in the repos using the old version with your package? I'm not sure which all have it off hand but I assume onboard, audit, and pay have this logic.

Originally posted by @pavlovcik in https://github.com/ubiquity/rpc-handler/issues/3#issuecomment-1998617039

[Keyrxng]

Sure thing will catch it tomorrow

Frontend

• onboarding
• audit
• pay
• staking

Backend

• I'll implement it into permit module for when that's in use but should I add it into any of the current production backend stuff?

[0x4007]

Sure thing will catch it tomorrow

Frontend

• onboarding

• audit

• pay

• staking

As in uAD.ubq.fi? I think there's an issue open for it you can handle that separately because I expect that to be its own big project. It's significantly more complicated codebase.

Backend

• I'll implement it into permit module for when that's in use but should I add it into any of the current production backend stuff?

Don't think it's necessary for anything in production currently. Besides I can't think of where it's even being used.

[Keyrxng]

I think there's an issue open for it you can handle that separately because I expect that to be its own big project

I already have a pull ready for it, if you can allow the build workflow I can abuse the preview deployment and try to reproduce, either way I can add the rpc-handler as part of that PR

• https://github.com/pavlovcik/uad.ubq.fi/pull/2

Don't think it's necessary

No probs

[Keyrxng]

neither audit nor onboarding actually make use of any RPC calls reviewing the code, onboarding does lean into using the MM provider which the rpc-handler would have no effect on

• audit: getRandomRpcUrl() & getOptimalRPC() exist but are never used in the codebase
• onboarding: uses getNetworkName, NetworkIds, Tokens from constants.ts which are also exported from the package but seems redundant installing the pkg just for 3 exports which exist in constants.ts

---

• pay: PR open
• uad: TODO

[0x4007]

onboarding does lean into using the MM provider which the rpc-handler would have no effect on

The built in RPC sucks for speed. Let's use our custom ones if its for reading data on chain.

[Keyrxng]

I'm mistaken anyway there are two calls, decimals and approve, my bad

Will pr it rn

[Keyrxng]

• https://github.com/ubiquity/onboard.ubq.fi/blob/66b2bcbb3ca21ff2559bf1c33a82359bd0130ea4/static/scripts/onboarding/onboarding.ts#L291 signer initialized and the chainId is fetched via MM

• https://github.com/ubiquity/onboard.ubq.fi/blob/66b2bcbb3ca21ff2559bf1c33a82359bd0130ea4/static/scripts/onboarding/onboarding.ts#L389 signer initialized, chainId and decimals fetched via MM although there's a signer-attached contract fetch and signer-required call to approve in the same function

What could be replaced:

• first chainId fetch
• chainId fetch and decimals, but then we'd need to instantiate a signer to call approve (which seems messier than as-is)

I'm unsure if it's worth it but that's the only reads that are happening, thought I'd ask before firing in a PR

[0x4007]

@Keyrxng heres a follow up

[Keyrxng]

Last PR open in permit-generation