Port random-beacon and ecdsa deploy layers to hardhat-deploy v2 / rocketh #4295

Follow-up to #4216, which #4294 closes by taking the maintained v1 line (hardhat-deploy@^1.0.4, Hardhat 2 retained). #4209 tracks the Hardhat 3 migration of both packages and calls hardhat-deploy v2 "the expensive part" without giving it a tracker of its own. This is that tracker, and the keep-core sibling of threshold-network/tbtc-v2#1128.

Why keep-core is on the critical path, not downstream of it

tbtc-v2 executes these packages' published deploy scripts out of node_modules via external.contracts[].deploy (#4216, follow-up comment). Inside keep-core, ecdsa does the same to random-beacon through resolveRandomBeaconExport("deploy"), and both packages load @threshold-network/solidity-contracts/export/deploy. So the ordering is forced:

@threshold-network/solidity-contracts  →  random-beacon  →  ecdsa  →  tbtc-v2

hardhat-deploy v2 is ESM-only with a different deploy-script shape. The published export/deploy is therefore public API: switching it breaks every consumer's USE_EXTERNAL_DEPLOY path until that consumer migrates too. Either all four packages cut over in a coordinated order, or these packages dual-publish during a transition (v1 CommonJS export/deploy kept alongside a v2 export). That is the first design question here, and it does not exist on the tbtc-v2 side.

Exposure on main (a7ac8989b, 2026-09-06)

Both packages: prepack runs tsc -p tsconfig.export.json at target: es5 then hardhat export-artifacts into export/; files publishes deploy/, export/, and export.json; deployments/mainnet and deployments/sepolia are committed. tbtc-v2 currently consumes 18 ecdsa scripts from the published 2.1.0-dev.19; main has 22, so the published surface grows with each release.

Upstream as of 2026-09-06

hardhat-deploy@2.0.26 peers hardhat ^3.6.0 and rocketh ^0.21.0 / @rocketh/node ^0.21.0; rocketh@0.21.0; @rocketh/viem@0.19.15; @rocketh/ethers does not exist; hardhat@3.15.0. The migration guide linked from #4216 / tbtc-v2#1079 has moved to hardhat-deploy/documentation/how-to/migration-from-v1/index.md; the AI-assisted SKILL.md is unchanged.

Blocked on

1. build(solidity): upgrade hardhat-deploy to v1 #4294 landing the v1 1.0.4 bump. Independent of everything below.
2. The ethers v6 direction for both packages. Migrate solidity/ to Hardhat 3 #4209's order is waffle out → ethers v6 → chai 5 / mocha 11 → hardhat-deploy → Hardhat 3. random-beacon is still on waffle, and Replace the deprecated @nomiclabs/* hardhat plugins #4213's hardhat-ethers v3 swap is blocked on the same ethers v6 move. v2 puts viem underneath the deploy layer regardless; tbtc-v2's recorded decision (solidity/docs/hardhat-3-migration.md there) is ethers v6 for tests with viem confined to deployment, and the same shape almost certainly applies here.
3. @threshold-network/solidity-contracts publishing v2-compatible deploy exports. Separate repo, 1.3.0-dev.14 consumed here, no issue known. Both packages execute its 13 scripts.
4. @keep-network/hardhat-helpers has no Hardhat 3 line and peers hardhat-deploy ~0.11.11; build(solidity): upgrade hardhat-deploy to v1 #4294 already flags that the peer range needs a separate update.
5. Two upstream questions, still unanswered as of today and shared with tbtc-v2#1128. They matter more here because these packages produce the format, not only consume it:
   • external.contracts with a deploy path: the v2 migration guide says only "Remove external.deployments configuration (handled differently)" and documents no mechanism for one package executing another's deploy scripts.
   • export.json / hardhat export-artifacts: @rocketh/export exists and emits chain info plus per-contract abi/address/startBlock; compatibility with the v1 export.json and export/ layout that files publishes is unverified.

Design decisions to make

• Dual-publish or coordinated cutover for export/deploy, agreed with tbtc-v2 (Display beneficiary address on the operator page #1128) before either side ports a script.
• B or D, per the option comparison in tbtc-v2#1079: v2 for deployment only with tests staying on ethers v6 (B), or Hardhat Ignition (D). D has no equivalent of deployments/*.json, named accounts, or external loading, so it is out for as long as tbtc-v2 consumes this package's exports.
• Raise the published export/ bundles off target: es5 #4210 ordering. The es5 export target exists to serve external consumers of export/deploy; a v2 export is ESM. Raise the published export/ bundles off target: es5 #4210 and this issue edit the same tsconfig.export.json, so decide which lands first.

Scope once unblocked

• Answer the two upstream questions; record the answers here.
• Agree dual-publish vs cutover and the cross-package order with tbtc-v2#1128; record it here.
• Decide B vs D; record it.
• Port random-beacon's 9 deploy scripts first (ecdsa consumes its export), then ecdsa's 22. The upstream SKILL.md covers the mechanical conversion.
• Replace the fixture loaders: random-beacon deployments.fixture ×3; ecdsa createFixture ×4 and deployments.fixture ×19.
• Replace external.contracts loading of solidity-contracts (both) and random-beacon (ecdsa) with whatever v2 mechanism upstream confirms.
• Preserve deployments/{mainnet,sepolia}, export/, and export.json byte-for-byte, or document the break and get tbtc-v2 sign-off.
• Verify both suites (955 + 673) and a fresh local deployment + --export per package, as build(solidity): upgrade hardhat-deploy to v1 #4294 did for the v1 bump.

Related

#4209 (Hardhat 3 umbrella), #4216 (scoping, closed by #4294), #4210 (ES5 export target), #4213 (@nomiclabs/* replacements), #4215 (@types/*), threshold-network/tbtc-v2#1128 (downstream sibling), threshold-network/tbtc-v2#1079 (option comparison).