Add stable megapool validator deposit UI

[saju01]

Summary

Port of the stable Smartnode v1.20.3 + Saturn/megapool validator deposit UI/API work to the Hoodi testnet package, per maintainer request on mainnet PR #25.

This keeps the testnet package identity intact:

• package: rocketpool-testnet.public.dappnode.eth
• network/build arg: hoodi
• global envs: EXECUTION_CLIENT_HOODI, CONSENSUS_CLIENT_HOODI
• dependency: web3signer-hoodi.dnp.dappnode.eth

What changed

• Bumps Smartnode upstream from v1.20.2 to stable v1.20.3.
• Aligns the settings template with v1.20.3 fields, including internal Smartnode HTTP API port 8280.
• Migrates Dappnode wrapper calls away from removed rocketpoold api ... commands and toward the stable daemon HTTP API at http://127.0.0.1:8280.
• Adds /api/v1/megapool/next-validator-bond so the UI asks Smartnode for the next validator bond requirement instead of hardcoding 4 ETH.
• Adds a stable Saturn/megapool validator deposit path in the UI.
• Preserves large wei values as strings before JS parsing to avoid precision loss.
• Supports the existing testnet NETWORK=hoodi env in rocketpool-start.sh (testnet still works too).

Validation run locally

• yarn --cwd build/api build ✅
• yarn --cwd build/ui build ✅
• bash -n build/rocketpool-start.sh ✅
• dappnode_package.json parses as valid JSON ✅

UI build warnings are existing eslint warnings in RewardsTab.tsx / Minipools.tsx; build completes.

Requested Hoodi validation before merge

Because this changes the Dappnode transaction path and first-run password setup, please validate on a Dappnode Hoodi/testnet install before merging:

1. first-run wallet password setup still works,
2. the UI can fetch the next megapool validator bond requirement through internal :8280,
3. can-deposit returns the expected result,
4. a test deposit succeeds,
5. returned validatorPubkeys are imported into Web3Signer correctly.

Related mainnet/stable PR: dappnode#25

[mgarciate]

@saju01 Just curious, have you tested the UI + API against real pools yet, even if it was outside of DAppNode?

[saju01]

Not yet against real pools.

So far I’ve validated this at the code/build level:

• API build passes
• UI build passes
• startup script syntax passes
• the wrapper is mapped to the stable Smartnode v1.20.3 HTTP API routes rather than the removed rocketpoold api ... path
• testnet package metadata remains Hoodi-specific

But I have not yet run the full UI + API flow against a live Rocket Pool Hoodi pool / actual deposit path.

That’s why I marked this PR as needing Hoodi/DAppNode validation before merge. The key flows I’d want to test are:

1. first-run wallet password setup,
2. fetching next validator bond through the internal :8280 API,
3. can-deposit,
4. actual Hoodi test deposit,
5. returned validatorPubkeys import into Web3Signer.

Happy to adjust based on what you see in testnet validation.

[saju01]

Status update — keeping this aligned with the new auto-bump cadence. The mainnet sibling's older v1.20.3 bump (#24) was closed as superseded by tropibot's v1.20.5 bump; the testnet auto-bump is #158.

This deposit-UI PR is independent of those version bumps (they only touch the daemon version, not the UI/API). I re-verified compatibility: the wrapper calls stable Smartnode HTTP routes at :8280 (/api/node/can-deposit, /api/megapool/status, /api/wallet/*), and v1.20.4/v1.20.5 are client + bugfix releases with no API route changes — so this stays compatible on top of #158.

Still flagged as needing a live Hoodi/DAppNode validation pass before merge (the build/syntax checks pass; the real-pool deposit path is what's untested). Happy to rebase onto current master whenever useful.

[saju01]

Update on the "have you tested the UI + API against real pools?" question — yes, now validated end-to-end on a live Hoodi pool, not just builds.

I ran the v1.20.x daemon in external-client mode (public Hoodi EL RPC + Beacon API) and drove this PR's flow against real Rocket Pool contracts:

First-run + deposit (this PR's flow):

• wallet/set-password → wallet/init — first-run wallet flow works exactly as rocketpool-start.sh drives it ✅
• node registered: https://hoodi.etherscan.io/tx/0xd75887ac903ca1cbb3d842566b5095af91d7635decb1f19c26243d606fe93a7a
• can-deposit → node deposit for a 4-ETH megapool validator: https://hoodi.etherscan.io/tx/0x5f1ef6b396c2a4fa25aae25a347d65c3dcfdb635dca4627273e4c4637517b6de
• megapool deployed at 0x080fc2df40ec100e1a85a8626836b2b01f6a6209, validatorCount 1
• after deploy, megapool/get-new-validator-bond-requirement returns 4000000000000000000 ✅ (it correctly errors pre-deploy with "node does not have a megapool deployed")

One bug found while validating — worth fixing before merge:
The settings template uses network: ${NETWORK} and the package sets NETWORK=hoodi, but the Smartnode daemon's network enum only accepts mainnet|testnet|devnet. testnet is Hoodi internally (chainId 560048, RocketStorage 0x594Fb75D3dc2DFa0150Ad03F99F97817747dd4E1). With network: hoodi the daemon can't resolve the storage address and every on-chain call fails with "The Rocket Pool storage contract was not found." Rendering the setting as network: testnet fixes it immediately — every contract read then succeeds. (The repo's own history already uses testnet in user-settings; the megapool template just needs the same.)

Also opened #159 as a stacked follow-up adding the exit + claim/withdraw lifecycle (exit-queue / exit-validator / notify-exit / distribute / claim-refund), validated against the same live megapool — so there's the option of deposit-only here, or the full lifecycle.

[saju01]

Pushed the fix for the network: hoodi issue in 065edbf: introduces SMARTNODE_NETWORK (hoodi → testnet for the smartnode setting, mainnet → mainnet), passed through envsubst into the template's network: field. The package keeps NETWORK=hoodi for its own identity (web3signer-hoodi, globals, URLs) — only the smartnode network setting is remapped. Re-verified: with this, node register + the 4-ETH megapool deposit succeed and all megapool routes resolve against live Hoodi.