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.

[saju01]

Six weeks since the last update here, so a status ping — and this branch now conflicts with main (mergeable_state: dirty), so it needs a rebase before it can go anywhere.

Recapping where it was left, since the thread is long:

• @mgarciate asked whether the UI + API had been tested against real pools. It has — validated end-to-end on a live Hoodi pool (first-run wallet flow, deposit against real Rocket Pool contracts), not just builds.
• The network: hoodi issue was fixed in 065edbf via SMARTNODE_NETWORK (hoodi → testnet for the smartnode setting, mainnet → mainnet), leaving the package's own NETWORK=hoodi identity intact.
• The wrapper targets stable Smartnode HTTP API routes rather than the removed rocketpoold api ... path, so it's independent of the v1.20.x auto-bumps.

Before I rebase: is this still the direction you want for megapool deposits? If the UI is being handled differently upstream, or the timing isn't right, I'd rather hear that than rebase and keep the PR open on a design that's moved on. Equally happy to close it if it's no longer useful.

If it is still wanted, say the word and I'll get it rebased and re-verified against current main.

[saju01]

Rebased onto current main — now conflict-free (mergeable_state: clean).

Conflict resolution: the only conflict was .github/workflows/auto_check.yml. main has since moved to the reusable workflow (dappnode/workflows/.github/workflows/bump-upstream.yml@master, #156/#26), which supersedes the inline workflow fix this branch originally carried — and handles it better than my version did. I took main's version wholesale, so that file is now byte-identical to main and this PR no longer touches CI at all.

What remains is only the megapool deposit work: UI components, API routes, the startup script's Hoodi handling, and the settings template.

Re-verified after the rebase (not assumed):

• UI build passes (react-scripts build)
• API build passes (tsc, no errors)
• rocketpool-start.sh passes bash -n
• .github/workflows/auto_check.yml diffs clean against main

The live Hoodi validation described earlier in this thread still applies — the rebase touched only the workflow file, so the deposit flow itself is unchanged.

Ready for review whenever you have a moment.