feat: wire-up rfox staking

[gomesalexandre]

Description

This PR implements RFOX staking e2e.

• Wallet/custom RUNE address with newly added bech32 validateAddress in THOR adapter
• balance and fee asset balance validation, using react-hook-form. <TradeAmountInput /> has been touched in a non-breaking manner to now consume a form context if present with useFormContext or have a dummy useFormContext otherwise. We actually declare the form context up top in RFOX's <StakeInput /> and do anything with said consumed form context in <TradeAmountInput /> meaning this isn't a user-facing change despite the seemingly scary diff there
• Handles approval needed/allowance Tx firing
• Handles signing and broadcasting the Tx, including EIP1559 support
• Displays approval/estimate fees programmatically
• Displays share of pool
• Handles loading states gracefully
• Adds some market-data patching for missing FOX on Arb market data
• Adds some generatedAssetData patching for missing FOX on arb asset
• Adds FOX on arb and RFOX contract address + RFOX ABI constants (to be updated with latest once @0xean's feat: refactor for staking token to be generic rFOX#43 goes in and v2 is deployed)
• Reintroduces wagmi for QoL (no need to reinvent the wheel when reading data with our own react-query hooks when battle-tested ones exist)
• Bumps viem from v1 -> v2 to work nicely with wagmi v2, and tackles all type errors and breaking changes (i.e function and arg name changes)

TODO:
- [x] tackle comments in this guy https://github.com/shapeshift/web/blob/7f85132b0f6b73cd77d8078ec060ebe5ae17da63/src/components/MultiHopTrade/components/TradeAmountInput.tsx
- [x] regression test added `useFormContext` and related changes in `<TradeAmountInput />` don't cause in regressions in current consumers
- [x] market patch FOX on Arb market data
- [x] approval fee instead of gas fee at input time when required
- [x] find a solution for `generatedAssetData.json` madness
- [x] share of pool?
- [x] Scrutinize react-queries that live in a wrong place currently (i.e lending)/should be generalized here, this is a bit messy on the query side and not really leveraging our current react-queries reusable queries for some
  - [x] 'estimateFees' (and consume the abstracted version in lending too after ensuring the implementation is line-per-line the exact same)
  - [x]  yeah no, we need the current mutation for proper loading state after click ~~send Tx mutation - probably not a now thing though it looks like we don't need a mutation at all here since we're not doing anything complex that requires a mutation - just move the logic to `handleStake` itself~~
- [x] Contract ABI and consumption
- [x] cooldownPeriod query
- [x] input
  - [x] estimate gas when approval *not* needed
  - [x] balance checks
  - [x] balance + fees checks as additional validate method
- [x] confirm
  - [x] approval step when required
  - [x] Tx broadcast
- [x] status
- [x] Record a final commented jam before opening this commenting on every row and ensuring data is there and things are happy re: balance checks, approval, spamming the delete key and re-inputting ensuring no race conditions etc. Go with the full flow e2e, including custom receive addy and its RUNE bech32 validation

Pull Request Type

• 🐛 Bug fix (Non-breaking Change: Fixes an issue)
• 🛠️ Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
• 💅 New Feature (Breaking/Non-breaking Change)

Issue (if applicable)

closes #6737

Risk

High Risk PRs Require 2 approvals

Low/medium

What protocols, transaction types or contract interactions might be affected by this PR?

Testing

• RFOX flow is happy e2e, including
  • Approval needed (approval step is triggered and approval Tx is happy)
  • Not enough fee for gas
  • Not enough FOX balance for entered amount
  • Manual RUNE address (try with an invalid address too and ensure you cannot continue), as well as account RUNE addies
• Do a quick regression test of inputs in THOR LP, swapper and lending. No need to test these end-to-end, just ensure that you can still type amounts there without inputs being rugged

Engineering

• ☝🏽

Operations

• ☝🏽

Screenshots (if applicable)

https://jam.dev/c/ef9c0848-d978-459e-b209-5b57c4b1257f

[gomesalexandre]

Yeah we're bringing this back, no reason to reinvent the wheel when reading data in components - wagmi is just a wrapper around react-query and we would write ours, not so well optimized anyway, using viem.

Since wagmi wraps react-query and uses our viem client under the hood, that's literally the same we would write, but better. Nothing crazy huge either: https://bundlephobia.com/package/[email protected]

Note: this is the last v1 before wagmi published v2 which has viem v2 as a dependency, meaning we'd also have to bump viem to v2. Initially went with that and this is nothing super bad to tackle, but this PR is probably not the place for it so staying at v1 for now.

[gomesalexandre]

Actually bumped viem and wagmi to latest, tackled all type errors and renames following breaking change. Now bundle is actually twice smaller 🎉

[gomesalexandre]

This was not typed properly but just happened to work given our usage, doesn't anymore

[0xApotheosis]

Holy moly this is a monster PR, well done ser.

Code review pass and light functional test:

✅ Can successfully stake FOX on Arbitrum

✅ TradeAmountInput consumers are still happy :fridaydog:

❌ Fiat amounts are sad, but only when connected to an account with no FOX on Arbitrum:

rFOX-fiat-sad.mp4

❌ Share of pool looks off in both the quot and the confirm screens:

❓ I'm not sure I understand this, is it 1 hour or 28 days?

❓ Approval does not show a transaction ID, and is a little jumpy (could use some loading states on the button and on the gas estimate):

rFOX-approval.mp4

[gomesalexandre]

❌ Fiat amounts are sad, but only when connected to an account with no FOX on Arbitrum:

rFOX-fiat-sad.mp4

Nice find. Looking closely, we can see that the opposite fiat value is also missing when inputting crypto. The issue here is we needed to hydrate FOX on Arbitrum market data. Mainnet FOX market-data would conventionally be hydrated across the app regardless of whether or not the user has balance (many many consumers) and isn't an issue, but FOX on Arbitrum isn't.
Fixed in b5b8d3d - tangential, but also passed the cryptoAmount in to <TradeAssetInput /> too for sanity in cdf3dfe, and while at it, added missing prefix for crypto as opposite currency when isFiat in <TradeAmountInput />

https://jam.dev/c/c57272f9-9ddb-4c33-bac3-8d50ceebd751

❌ Share of pool looks off in both the quot and the confirm screens:

There are two things off here:

1. the whole share of pool thing isn't very clear and
2. derp, this is an actual bug, forgot to cherry-pick math fixes from the unstaking PR, consuming stakingInfo[2], i.e the staking balance, vs. the wrong hollistic balanceOf, which includes pending unstaking too.

as for 1. tl;dr, we've been back and forth with this one with beard many times, and this isn't super clear either for engineering nor users. Is it your current share of pool? Is it the share of pool for the exact amount you're staking, but not taking into account your currently staked amount? Is it the new share of pool after you stake said amount?
The answer is the latter, but that's not super obvious at all UX-wise. We've agreed to do a follow-up to use the same <DynamicComponent /> as lending, which will show both before and after values in the spirit of clarity.

Fixed in bbacc30:

• Current contract balance: 123 FOX

• Current user staking balance: 10.6875 FOX i.e (10.6875 / 123) = 8.68902439 % of the pool

• Staking 0 - no change of pool share

• Staking a fraction of FOX - no visible change of pool share given the toFixed(2) and rounding for percentage, but allows us to confirm confirm is happy

• Staking 100 FOX - i.e new staking balance = 110.6875. New share of pool = (110.6875 / (123 + 100)) = 49.635650224 %

❓ I'm not sure I understand this, is it 1 hour or 28 days?

8196a79

❓ Approval does not show a transaction ID, and is a little jumpy (could use some loading states on the button and on the gas estimate):

rFOX-approval.mp4

• Toast added in 4f537d5 https://jam.dev/c/bcf00f41-c36a-416b-bc35-cf20cb53cf7a
• Jumpy states tackled in 1e14154 https://jam.dev/c/bcf00f41-c36a-416b-bc35-cf20cb53cf7a
• Paranoia jam retest of staking flow without approval required https://jam.dev/c/604abc97-a874-4eba-aa09-535c701d7938

[0xApotheosis]

Still a few small things to do as follow-ups, which I'll outline below, but let's get this monster in 🙏

• Approval gas estimate changes after confirming quote:

changing-approval-gas.mp4

• Approval fee fiat amount spans two lines:

[0xApotheosis]

rm

[gomesalexandre]

Still a few small things to do as follow-ups, which I'll outline below, but let's get this monster in 🙏

• Approval gas estimate changes after confirming quote:

changing-approval-gas.mp4

• Approval fee fiat amount spans two lines:

Nice catch @0xApotheosis - tackled in #6989 as a follow-up!