feat(solidity): improve Sepolia deploy behavior and wallet registry flows

[lionakhnazarov]

Stack Context

This is PR 2/4 in the reorganization stack.
Base: #3999 (stack/testnet4-01-ci-yarn)
Next: #4001

What Changed

1) ECDSA deploy/runtime logic

• Contract-level adjustments:
  • solidity/ecdsa/contracts/WalletRegistry.sol
• Deploy script updates for deployment flow and account/approval behavior:
  • solidity/ecdsa/deploy/00_resolve_reimbursement_pool.ts
  • solidity/ecdsa/deploy/00_resolve_token_staking.ts
  • solidity/ecdsa/deploy/01_deploy_ecdsa_sortition_pool.ts
  • solidity/ecdsa/deploy/02_deploy_dkg_validator.ts
  • solidity/ecdsa/deploy/03_deploy_wallet_registry.ts
  • solidity/ecdsa/deploy/07_approve_wallet_registry.ts
  • solidity/ecdsa/deploy/09_deploy_wallet_registry_governance.ts
• Added verification helper:
  • solidity/ecdsa/deploy/etherscanVerification.ts
• Hardhat runtime/config updates:
  • solidity/ecdsa/hardhat.config.ts
• Wallet owner initialization logic update:
  • solidity/ecdsa/tasks/initialize-wallet-owner.ts

2) ECDSA test/fixture/type updates

• Tests:
  • solidity/ecdsa/test/WalletRegistry.Authorization.test.ts
  • solidity/ecdsa/test/WalletRegistry.CustomErrors.test.ts
  • solidity/ecdsa/test/WalletRegistry.Rewards.test.ts
  • solidity/ecdsa/test/WalletRegistry.Slashing.test.ts
  • solidity/ecdsa/test/WalletRegistry.Upgrade.test.ts
  • solidity/ecdsa/test/WalletRegistry.WalletCreation.test.ts
  • solidity/ecdsa/test/WalletRegistryGovernance.test.ts
• Fixtures/utilities:
  • solidity/ecdsa/test/fixtures/index.ts
  • solidity/ecdsa/test/utils/operators.ts
• Added types:
  • solidity/ecdsa/types/TokenStaking.extensions.d.ts
  • solidity/ecdsa/types/chai.d.ts

3) Random beacon deploy/config/test alignment

• Deploy/config:
  • solidity/random-beacon/deploy/05_approve_random_beacon_in_token_staking.ts
  • solidity/random-beacon/hardhat.config.ts
• Tests/fixtures/utilities:
  • solidity/random-beacon/test/RandomBeacon.Authorization.test.ts
  • solidity/random-beacon/test/RandomBeacon.Callback.test.ts
  • solidity/random-beacon/test/RandomBeacon.GroupCreation.test.ts
  • solidity/random-beacon/test/RandomBeacon.Relay.test.ts
  • solidity/random-beacon/test/RandomBeacon.Rewards.test.ts
  • solidity/random-beacon/test/system/e2e.test.ts
  • solidity/random-beacon/test/fixtures/index.ts
  • solidity/random-beacon/test/utils/operators.ts
• Added types:
  • solidity/random-beacon/types/TokenStaking.extensions.d.ts

4) Embedded export deploy scripts for ECDSA external random-beacon export

• Added scripts under:
  • solidity/ecdsa/external/random-beacon-export/deploy/01_*.js ... 09_*.js

Out of Scope

• Generated deployments/sepolia JSON snapshots (handled in chore(deployments): add Sepolia deployment artifacts #4001).
• Go/Testnet4 runtime changes (handled in feat(go): add testnet4 mapping and harden runtime integration behavior #4002).

Test Plan

• cd solidity/ecdsa && yarn test
• cd solidity/random-beacon && yarn test
• Spot-check deployment flows for expected skip/redeploy behavior.

Summary by CodeRabbit

Release Notes

• New Features

  • Added deployment verification helper wrappers for improved error resilience.
  • Introduced random beacon deployment automation with network-aware initialization.
  • Enhanced wallet governance initialization with additional consistency validation.

• Bug Fixes

  • Made deployment scripts network-aware to gracefully skip unavailable contracts on local development networks.
  • Added ABI-level feature detection to prevent failures when calling unsupported contract methods.
  • Improved deployment transaction handling with environment-based gas price configuration.

• Documentation

  • Updated contract documentation with expanded guidance on beneficiary address resolution behavior.
  • Added deployment guidelines for vendored external contracts.

• Tests

  • Updated test suites to use allowlist-based authorization by default with legacy fallback support.
  • Enhanced test utilities with improved compatibility helpers for legacy contract interactions.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 1d47cf83-9ee9-4880-9f2b-e5522e6382df

📥 Commits

Reviewing files that changed from the base of the PR and between ebf0a91 and 2f0e26d.

📒 Files selected for processing (2)

• solidity/ecdsa/deploy/02_deploy_dkg_validator.ts
• solidity/random-beacon/test/RandomBeacon.Authorization.test.ts

🚧 Files skipped from review as they are similar to previous changes (2)

• solidity/ecdsa/deploy/02_deploy_dkg_validator.ts
• solidity/random-beacon/test/RandomBeacon.Authorization.test.ts

---

📝 Walkthrough

Walkthrough

This PR refactors Threshold's ECDSA and random-beacon deployment infrastructure to decouple verification from deployment success, defaults test fixtures to allowlist authorization, vendors random-beacon export scripts, adds compatibility layers for legacy TokenStaking method variants, and migrates test suites to use legacy helpers while skipping unsupported scenarios.

Changes

Unified deployment, verification, and test compatibility changes

Layer / File(s)	Summary
Verification wrappers and conditional loading solidity/ecdsa/deploy/etherscanVerification.ts, solidity/ecdsa/deploy/tenderlyVerification.ts, solidity/ecdsa/hardhat.config.ts	New verifyOnEtherscanOrContinue and verifyOnTenderlyOrContinue helpers catch and log verification failures without rethrowing, allowing deployments to continue. Hardhat config conditionally requires hardhat-verify plugin based on DISABLE_HARDHAT_VERIFY environment variable.
Hardhat configuration paths and accounts solidity/ecdsa/hardhat.config.ts, solidity/random-beacon/hardhat.config.ts	Adds resolveRandomBeaconExport() helper for local/npm export path selection, updates named accounts for mainnet/Sepolia with explicit literals, handles local development deployments separately, conditionally applies gas price overrides to Sepolia, and conditionally assigns etherscan API keys only when verification is enabled.
ECDSA deploy guards and local network handling solidity/ecdsa/deploy/00_resolve_reimbursement_pool.ts, solidity/ecdsa/deploy/00_resolve_token_staking.ts	Adds conditional skips when ReimbursementPool or TokenStaking are missing on hardhat/development networks, logging skips rather than throwing errors to enable local test setup.
ECDSA sortition pool and governance deployment solidity/ecdsa/deploy/01_deploy_ecdsa_sortition_pool.ts, solidity/ecdsa/deploy/09_deploy_wallet_registry_governance.ts	Routes Etherscan and Tenderly verification through wrapper helpers and gates Etherscan verification by DISABLE_HARDHAT_VERIFY environment variable alongside network tags.
DKG validator redeploy control solidity/ecdsa/deploy/02_deploy_dkg_validator.ts	Introduces allowlisted safe-redeploy networks (hardhat, development, sepolia), adds optional forced Hardhat compile, performs fail-fast consistency check when validator would redeploy with WalletRegistry already present to prevent desync, and routes verification through wrappers.
Vendored random-beacon export scripts and documentation solidity/ecdsa/external/random-beacon-export/README.md, solidity/ecdsa/external/random-beacon-export/deploy/01_deploy_reimbursement_pool.js through deploy/09_deploy_random_beacon_chaosnet.js	Documents vendored export structure, script format (compiled vs hand-written), approveApplication precheck requirements, and regeneration policy. Includes 9 deploy scripts covering pool, validator, beacon, governance, and authorization/approval flows with Etherscan/Tenderly verification and network tag gating.
TokenStaking approveApplication compatibility solidity/ecdsa/deploy/07_approve_wallet_registry.ts, solidity/random-beacon/deploy/05_approve_random_beacon_in_token_staking.ts	Adds ABI feature detection to verify approveApplication method presence, checks if already approved, skips when method unavailable on network, and includes targeted error handling for networks without the method while rethrowing unexpected errors.
Wallet owner initialization task solidity/ecdsa/tasks/initialize-wallet-owner.ts	Validates walletOwnerAddress as Ethereum address, ensures WalletRegistryGovernance correctly wires to WalletRegistry, skips when governance is misaligned, reads existing walletOwner and skips if already set, performs TOCTOU governance re-read before transaction, and selects signer based on on-chain governance owner identity.
TokenStaking type augmentations and legacy helpers solidity/ecdsa/types/TokenStaking.extensions.d.ts, solidity/ecdsa/test/utils/operators.ts, solidity/ecdsa/types/chai.d.ts, solidity/random-beacon/types/TokenStaking.extensions.d.ts, solidity/random-beacon/test/utils/operators.ts, solidity/random-beacon/test/fixtures/index.ts	Module augmentations for TokenStaking with stake, increaseAuthorization, approveApplication, processSlashing, topUp, and slashing queue methods. legacyTokenStakingAt helper in both test suites invokes legacy methods via minimal ABI. Chai matcher type declaration for revertedWithCustomError with chainable .withArgs(). Fixture token-staking parameter calls check method availability before executing.
Allowlist-default test fixture solidity/ecdsa/test/fixtures/index.ts	Defaults useAllowlist to true when omitted, exports setupAllowlist for external use, updates JSDoc with allowlist-first examples, and skips TokenStaking parameter updates when allowlist mode is active.
Rewards and custom-error test updates solidity/ecdsa/test/WalletRegistry.Rewards.test.ts, solidity/ecdsa/test/WalletRegistry.CustomErrors.test.ts	Adds rewardsBeneficiaryAddress helper resolving beneficiary from allowlist or staking roles. Replaces custom-error fixture setup to use allowlist initialization. Removes dedicated allowlist-specific rewards test suite.
WalletRegistry authorization migration tests solidity/ecdsa/test/WalletRegistry.Authorization.test.ts	Routes legacy staking calls through legacyTokenStakingAt. Marks pre-upgrade and upgrade-flow suites as skipped. Adds skipped NOT MIGRATED touchpoints suite verifying beneficiary lookup still uses TokenStaking when allowlist enabled.
Wallet creation, slashing, and governance tests solidity/ecdsa/test/WalletRegistry.WalletCreation.test.ts, solidity/ecdsa/test/WalletRegistry.Slashing.test.ts, solidity/ecdsa/test/WalletRegistry.Upgrade.test.ts, solidity/ecdsa/test/WalletRegistryGovernance.test.ts	Skips challenge contexts due to missing processSlashing on dev TokenStaking. Routes legacy processSlashing through legacyTokenStakingAt in unrecoverable-signatures paths. Updates gas assertions. Adds fixture setup in upgrade tests. Simplifies governance delay update test setup and assertions.
Random-beacon authorization test migration solidity/random-beacon/test/RandomBeacon.Authorization.test.ts	Systematically routes stake, increaseAuthorization, requestAuthorizationDecrease, and processSlashing through legacyTokenStakingAt across all authorization scenarios: increase, decrease request, approval, involuntary decrease, sortition pool eligibility, operator status, eligible stake, delay calculations, and mixed interaction chains.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Suggested reviewers

• piotr-roslaniec
• lrsaturnino

---

🐰 Verification flows now skip with grace,
Allowlist becomes the fixture's base case,
Legacy helpers bridge the deploy divide,
And tests gain compatibility with pride! ✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 10.45% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The PR title accurately describes the main changes: improving Sepolia deployment behavior and wallet registry flows through updated deploy scripts, test fixtures, and verification helpers.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch stack/testnet4-02-solidity-logic

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[lrsaturnino]

LGTM

The base branch was changed.

[coderabbitai]

Actionable comments posted: 7

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

solidity/ecdsa/test/fixtures/index.ts (1)

216-235: ⚠️ Potential issue | 🔴 Critical | ⚡ Quick win

Critical: JSDoc contradicts actual default behavior.

Lines 216 and 230 state that TokenStaking is the default authorization mode, but the code at line 105 sets useAllowlist ?? true, making Allowlist the default. This documentation bug will mislead developers who rely on the JSDoc.

Additionally, the examples are now backwards:

• Line 224 shows the default call but documents it as using staking (legacy)
• Line 227 shows explicit useAllowlist: false but documents it as using allowlist

📝 Corrected JSDoc

 /**
  * Creates and loads a WalletRegistry test fixture with dual-mode authorization support.
  *
  * This is the main entry point for test files to load the WalletRegistry fixture.
- * It supports TokenStaking (default) and Allowlist authorization modes for
+ * It supports Allowlist (default) and TokenStaking authorization modes for
  * comprehensive testing of the dual-mode authorization routing implementation.
  *
  * `@param` options - Configuration options for the fixture
  * `@param` options.useAllowlist - If true (default), Allowlist mode; if false, legacy stake path
  * `@returns` Promise resolving to fixture with all deployed contracts, signers, and test operators
  *
  * `@example`
- * const { walletRegistry, operators, allowlist } = await walletRegistryFixture()
+ * const { walletRegistry, operators, allowlist } = await walletRegistryFixture()  // Default: Allowlist mode
  *
  * `@example`
- * const { walletRegistry, operators, staking } = await walletRegistryFixture({ useAllowlist: false })
+ * const { walletRegistry, operators, staking } = await walletRegistryFixture({ useAllowlist: false })  // Legacy TokenStaking mode
  *
  * `@remarks`
- * - Default uses TokenStaking; use `{ useAllowlist: true }` for dual-mode / Allowlist-only tests
+ * - Default uses Allowlist; use `{ useAllowlist: false }` for legacy TokenStaking tests
  * - Allowlist mode calls walletRegistry.initializeV2() to enable dual-mode routing
  * - In Allowlist mode, TokenStaking notification rewards are NOT configured (not needed)
  * - Fixture uses hardhat-deploy's snapshot/restore for efficient test isolation
- * - Performance: ~5 seconds (TokenStaking mode), ~7 seconds (Allowlist mode)
+ * - Performance: ~7 seconds (Allowlist mode), ~5 seconds (TokenStaking mode)
  */

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@solidity/ecdsa/test/fixtures/index.ts` around lines 216 - 235, The JSDoc
incorrectly states TokenStaking is the default while the code sets useAllowlist
?? true; update the doc for walletRegistryFixture to state Allowlist is the
default, adjust the two examples so the default call returns allowlist (and the
explicit { useAllowlist: false } example returns staking), and correct remarks
that currently claim TokenStaking is default; ensure references to useAllowlist,
walletRegistry.initializeV2(), TokenStaking, and Allowlist match the actual
behavior.

♻️ Duplicate comments (1)

solidity/ecdsa/external/random-beacon-export/deploy/07_deploy_random_beacon_governance.js (1)

61-76: ⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Verification failures will block deployment flow.

Same issue as in 04_deploy_random_beacon.js: lines 61-67 call helpers.etherscan.verify directly without the error-suppressing wrapper, and lines 70-76 call hre.tenderly.verify directly. This creates inconsistency with the ECDSA deployment scripts and contradicts the PR's goal of preventing verification failures from blocking deployments.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@solidity/ecdsa/external/random-beacon-export/deploy/07_deploy_random_beacon_governance.js`
around lines 61 - 76, The verification calls for RandomBeaconGovernance
currently call helpers.etherscan.verify and hre.tenderly.verify directly (in the
RandomBeaconGovernance deployment block) which can throw and abort deployment;
change these to the same error-suppressing pattern used in the other ECDSA
deploy scripts by wrapping each call in a try/catch that logs the verification
error (including the error message) but does not rethrow, i.e., replace direct
calls to helpers.etherscan.verify(RandomBeaconGovernance) and
hre.tenderly.verify({...}) with try { await
helpers.etherscan.verify(RandomBeaconGovernance); } catch (err) {
console.warn("Etherscan verify failed for RandomBeaconGovernance:", err); } and
similarly for hre.tenderly.verify, referencing
RandomBeaconGovernance.address/name in the log.

🧹 Nitpick comments (5)

solidity/random-beacon/types/TokenStaking.extensions.d.ts (1)

10-39: ⚡ Quick win

Apply transaction overrides to all write signatures here as well.

These are write methods, so CallOverrides is not the right override type and may block valid tx override fields in tests.

Suggested typing fix

 import type { BigNumber, BigNumberish, ContractTransaction } from "ethers"
-import type { CallOverrides } from "`@ethersproject/contracts`"
+import type { CallOverrides, Overrides } from "`@ethersproject/contracts`"
@@
-      overrides?: CallOverrides
+      overrides?: Overrides
@@
-      overrides?: CallOverrides
+      overrides?: Overrides
@@
-      overrides?: CallOverrides
+      overrides?: Overrides
@@
-      overrides?: CallOverrides
+      overrides?: Overrides
@@
-      overrides?: CallOverrides
+      overrides?: Overrides
@@
-      overrides?: CallOverrides
+      overrides?: Overrides

Also applies to: 50-55

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@solidity/random-beacon/types/TokenStaking.extensions.d.ts` around lines 10 -
39, The listed functions (stake, approveApplication, increaseAuthorization,
topUp, processSlashing and the other write signatures in the same file)
incorrectly use CallOverrides (read/call-only) — change their overrides
parameter to the appropriate transaction override type (Overrides from ethers
for non-payable writes, or PayableOverrides if the function is payable) so tests
and tx options (gas, nonce, value, etc.) are accepted; update the signature for
each write method (e.g., stake(..., overrides?: Overrides), topUp(...,
overrides?: Overrides|PayableOverrides as applicable), approveApplication(...,
overrides?: Overrides), increaseAuthorization(..., overrides?: Overrides),
processSlashing(..., overrides?: Overrides)) and adjust imports if necessary.

solidity/ecdsa/test/WalletRegistry.Authorization.test.ts (1)

3780-3808: ⚡ Quick win

Avoid unconditional skips for migration-path suites.

These describe.skip blocks remove coverage for pre-upgrade routing and upgrade transition behavior. Prefer conditional execution (skip only when required capabilities are absent) so these assertions still run in environments that support legacy flows.

Also applies to: 3981-4038, 4047-4158

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@solidity/ecdsa/test/WalletRegistry.Authorization.test.ts` around lines 3780 -
3808, Replace the unconditional describe.skip with a normal describe and make
the before hook a non-arrow function so you can call this.skip() if the
environment lacks legacy token-staking authorization; e.g., change
describe.skip("Pre-Upgrade Mode...") to describe("Pre-Upgrade Mode...") and
convert the before(async () => { ... }) to before(async function() { if (!(await
supportsTokenStaking())) return this.skip(); await createSnapshot(); await
setupRealStaking(...); await deactivateChaosnetMode(...); await
walletRegistry.connect(...).registerOperator(...); }); similarly add or reuse a
small helper like supportsTokenStaking or capability check to detect when
token-staking/legacy flows are unavailable so the suite runs in capable
environments but is skipped gracefully otherwise (same pattern for the other
skipped suites).

solidity/ecdsa/test/WalletRegistry.WalletCreation.test.ts (1)

2403-2466: ⚡ Quick win

Preserve slashing-path coverage with capability-based skipping instead of unconditional skips.

These blocks are fully disabled, so challenge/slashing regressions won’t be caught in this suite. Gate them conditionally (based on fixture/runtime capability) rather than permanently skipping.

Also applies to: 2484-2544, 2587-2663, 2946-3000, 3028-3082, 3122-3188

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@solidity/ecdsa/test/WalletRegistry.WalletCreation.test.ts` around lines 2403
- 2466, The test contexts are unconditionally skipped via context.skip which
removes coverage for the challenge/slashing paths; change each context.skip to a
conditional wrapper that checks runtime capability (e.g., whether
processSlashing exists) and only skips when unsupported. Concretely, introduce a
boolean like supportsProcessSlashing = typeof legacyTokenStakingAt(staking,
thirdParty).processSlashing === "function" (or await
staking.callStatic.processSlashing? catch) at the top of the suite or in a
before hook, then replace context.skip(...) with supportsProcessSlashing ?
context(...) : context.skip(...), keeping the inner tests that call
walletRegistry.challengeDkgResult, legacyTokenStakingAt(...).processSlashing,
assertGasUsed, etc., so the tests run when processSlashing is available and are
skipped otherwise.

solidity/ecdsa/deploy/07_approve_wallet_registry.ts (1)

22-46: ⚡ Quick win

Consider consolidating redundant checks or documenting the dual-check rationale.

The script performs two separate checks for approveApplication availability:

1. ABI interface check (lines 22-28)
2. Try-catch with error message parsing (lines 37-44)

If the ABI check is reliable, the try-catch is redundant. If both are needed (e.g., to handle deployment ABI/on-chain ABI mismatches), document why. The error message parsing at line 39 is fragile and will break if the error format changes.

♻️ Simplified approach relying on ABI check

If the ABI check is sufficient, remove the try-catch:

   if (!ifaceHasFunction(iface, "approveApplication")) {
     hre.deployments.log(
       "TokenStaking does not have approveApplication (Threshold TokenStaking); skipping WalletRegistry approval"
     )
     return
   }

-  try {
-    await execute(
-      "TokenStaking",
-      { from: deployer, log: true, waitConfirmations: 1 },
-      "approveApplication",
-      WalletRegistry.address
-    )
-  } catch (e: unknown) {
-    const msg = e instanceof Error ? e.message : String(e)
-    if (msg.includes("No method named") && msg.includes("approveApplication")) {
-      hre.deployments.log(
-        "TokenStaking has no approveApplication callable on this network; skipping WalletRegistry approval"
-      )
-      return
-    }
-    throw e
-  }
+  await execute(
+    "TokenStaking",
+    { from: deployer, log: true, waitConfirmations: 1 },
+    "approveApplication",
+    WalletRegistry.address
+  )

If both checks are needed, add a comment explaining the deployment/runtime ABI divergence scenario.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@solidity/ecdsa/deploy/07_approve_wallet_registry.ts` around lines 22 - 46,
The script redundantly checks for approveApplication twice (via ifaceHasFunction
on TokenStaking ABI and again by catching runtime errors around
execute("approveApplication", ...)); either remove the try-catch and rely on the
ABI check (delete the catch block and its special-case string parsing) or keep
the runtime guard but add a clear comment explaining why both checks are
required (e.g., deployment ABI vs on-chain implementation mismatch) and replace
fragile string parsing in the catch with a safer detection (inspect error
type/metadata instead of message substrings). Ensure changes reference
ifaceHasFunction, ethers.utils.Interface/TokenStaking.abi,
execute("approveApplication", WalletRegistry.address) and the current try-catch
so reviewers can locate the logic to modify.

solidity/ecdsa/deploy/03_deploy_wallet_registry.ts (1)

64-88: 💤 Low value

Consider applying DISABLE_HARDHAT_VERIFY to Tenderly verification for consistency.

The Etherscan verification is gated by both hre.network.tags.etherscan and process.env.DISABLE_HARDHAT_VERIFY !== "true" (line 65-66), while Tenderly verification only checks hre.network.tags.tenderly (line 81).

If DISABLE_HARDHAT_VERIFY is intended to disable all verification mechanisms, apply it to Tenderly as well. If the asymmetry is intentional (Tenderly uses a separate plugin), consider documenting this design decision.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@solidity/ecdsa/deploy/03_deploy_wallet_registry.ts` around lines 64 - 88, The
Tenderly verification block currently only checks hre.network.tags.tenderly; to
make DISABLE_HARDHAT_VERIFY apply consistently, guard the
verifyOnTenderlyOrContinue call with the same environment check
(process.env.DISABLE_HARDHAT_VERIFY !== "true"), e.g. wrap the existing
hre.network.tags.tenderly condition or add it to the if condition that invokes
verifyOnTenderlyOrContinue (reference: verifyOnTenderlyOrContinue,
hre.network.tags.tenderly, DISABLE_HARDHAT_VERIFY) so Tenderly verification
honors the same disable flag as verifyOnEtherscanOrContinue.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@solidity/ecdsa/external/random-beacon-export/deploy/01_deploy_reimbursement_pool.js`:
- Around line 60-75: The vendored deploy script calls
helpers.etherscan.verify(...) and hre.tenderly.verify(...) directly (e.g.,
surrounding ReimbursementPool verification) which can throw and halt deployment;
change these calls to use the same non-blocking wrapper logic as
verifyOnEtherscanOrContinue and respect DISABLE_HARDHAT_VERIFY (or create a
small wrapper that catches errors and logs them and/or skips when
DISABLE_HARDHAT_VERIFY is set), and apply that wrapper to the ReimbursementPool
verification calls so failures do not abort the deployment flow.

In
`@solidity/ecdsa/external/random-beacon-export/deploy/04_deploy_random_beacon.js`:
- Around line 110-137: The verification calls in 04_deploy_random_beacon.js are
unprotected and will break the deploy on any rejection; replace direct
helpers.etherscan.verify(...) invocations for BLS, BeaconAuthorization,
BeaconDkg, BeaconInactivity, and RandomBeacon with the existing helper
verifyOnEtherscanOrContinue (passing the same contract symbols) and replace the
hre.tenderly.verify(...) call for RandomBeacon with verifyOnTenderlyOrContinue
(passing name "RandomBeacon" and RandomBeacon.address or the helper's expected
args) so each verification is wrapped to catch/skip failures and allow the
deploy to continue.

In
`@solidity/ecdsa/external/random-beacon-export/deploy/09_deploy_random_beacon_chaosnet.js`:
- Around line 67-83: Replace the direct calls to helpers.etherscan.verify and
hre.tenderly.verify for RandomBeaconChaosnet with the graceful wrappers
(verifyOnEtherscanOrContinue and verifyOnTenderlyOrContinue) or, if you prefer
not to convert this .js file to .ts, wrap each verification in a try/catch that
logs the error and continues; specifically, for hre.network.tags.etherscan wait
for RandomBeaconChaosnet.transactionHash then call the etherscan wrapper (or try
{ await helpers.etherscan.verify(RandomBeaconChaosnet) } catch (e) {
console.log(...) }) and for hre.network.tags.tenderly call the tenderly wrapper
(or try { await hre.tenderly.verify({ name: "RandomBeaconChaosnet", address:
RandomBeaconChaosnet.address }) } catch (e) { console.log(...) }), ensuring
failures do not throw and block deployment.

In `@solidity/ecdsa/test/WalletRegistry.WalletCreation.test.ts`:
- Around line 2707-2709: Update the test description string in the two
Jest/Mocha test cases using it(...) so it accurately reflects the asserted gas
target (currently asserting assertGasUsed(tx, 221_000, 60_000)); change the
title from "should use close to 275 000 gas" to a wording that matches ~221k
(e.g., "should use close to 221 000 gas") in both locations (the it(...)
containing assertGasUsed and the second occurrence noted), leaving the
assertGasUsed(tx, 221_000, 60_000) call unchanged.

In `@solidity/ecdsa/types/chai.d.ts`:
- Line 7: The revertedWithCustomError matcher is currently typed to return
Promise<void>, preventing chainable .withArgs(...). Update
solidity/ecdsa/types/chai.d.ts by adding an AsyncAssertion that extends
Assertion & Promise<void> and a CustomErrorAssertion that extends AsyncAssertion
and exposes withArgs(...args: any[]): AsyncAssertion, then change the
Declaration of revertedWithCustomError(contract: unknown, errorName: string) to
return CustomErrorAssertion so callers can chain .withArgs(...).

In `@solidity/random-beacon/hardhat.config.ts`:
- Around line 111-114: Validate process.env.GAS_PRICE_GWEI before using parseInt
to set gasPrice: check that GAS_PRICE_GWEI exists and that
Number.isFinite(Number(GAS_PRICE_GWEI)) (or a similar numeric check) yields
true; if valid, compute gasPrice = Math.floor(Number(GAS_PRICE_GWEI) * 1e9) and
include the override, otherwise skip adding the gasPrice override (or throw/log
a clear error) so gasPrice is never set to NaN; update the code around the
GAS_PRICE_GWEI usage and parseInt call accordingly to use this validated numeric
conversion and explicit handling.

In `@solidity/random-beacon/test/RandomBeacon.Authorization.test.ts`:
- Around line 1556-1559: The test currently calls legacyTokenStakingAt(...)[
"requestAuthorizationDecrease(address,address,uint96)"](stakingProvider.address,
randomBeacon.address, deauthorizingBy) without awaiting the returned promise,
which can race with later assertions; update both occurrences (the one shown and
the similar block at lines referenced) to await the call so the
authorization-decrease setup transactions complete before proceeding, i.e. add
await before legacyTokenStakingAt(...)[
"requestAuthorizationDecrease(address,address,uint96)"](...) for each instance.

---

Outside diff comments:
In `@solidity/ecdsa/test/fixtures/index.ts`:
- Around line 216-235: The JSDoc incorrectly states TokenStaking is the default
while the code sets useAllowlist ?? true; update the doc for
walletRegistryFixture to state Allowlist is the default, adjust the two examples
so the default call returns allowlist (and the explicit { useAllowlist: false }
example returns staking), and correct remarks that currently claim TokenStaking
is default; ensure references to useAllowlist, walletRegistry.initializeV2(),
TokenStaking, and Allowlist match the actual behavior.

---

Duplicate comments:
In
`@solidity/ecdsa/external/random-beacon-export/deploy/07_deploy_random_beacon_governance.js`:
- Around line 61-76: The verification calls for RandomBeaconGovernance currently
call helpers.etherscan.verify and hre.tenderly.verify directly (in the
RandomBeaconGovernance deployment block) which can throw and abort deployment;
change these to the same error-suppressing pattern used in the other ECDSA
deploy scripts by wrapping each call in a try/catch that logs the verification
error (including the error message) but does not rethrow, i.e., replace direct
calls to helpers.etherscan.verify(RandomBeaconGovernance) and
hre.tenderly.verify({...}) with try { await
helpers.etherscan.verify(RandomBeaconGovernance); } catch (err) {
console.warn("Etherscan verify failed for RandomBeaconGovernance:", err); } and
similarly for hre.tenderly.verify, referencing
RandomBeaconGovernance.address/name in the log.

---

Nitpick comments:
In `@solidity/ecdsa/deploy/03_deploy_wallet_registry.ts`:
- Around line 64-88: The Tenderly verification block currently only checks
hre.network.tags.tenderly; to make DISABLE_HARDHAT_VERIFY apply consistently,
guard the verifyOnTenderlyOrContinue call with the same environment check
(process.env.DISABLE_HARDHAT_VERIFY !== "true"), e.g. wrap the existing
hre.network.tags.tenderly condition or add it to the if condition that invokes
verifyOnTenderlyOrContinue (reference: verifyOnTenderlyOrContinue,
hre.network.tags.tenderly, DISABLE_HARDHAT_VERIFY) so Tenderly verification
honors the same disable flag as verifyOnEtherscanOrContinue.

In `@solidity/ecdsa/deploy/07_approve_wallet_registry.ts`:
- Around line 22-46: The script redundantly checks for approveApplication twice
(via ifaceHasFunction on TokenStaking ABI and again by catching runtime errors
around execute("approveApplication", ...)); either remove the try-catch and rely
on the ABI check (delete the catch block and its special-case string parsing) or
keep the runtime guard but add a clear comment explaining why both checks are
required (e.g., deployment ABI vs on-chain implementation mismatch) and replace
fragile string parsing in the catch with a safer detection (inspect error
type/metadata instead of message substrings). Ensure changes reference
ifaceHasFunction, ethers.utils.Interface/TokenStaking.abi,
execute("approveApplication", WalletRegistry.address) and the current try-catch
so reviewers can locate the logic to modify.

In `@solidity/ecdsa/test/WalletRegistry.Authorization.test.ts`:
- Around line 3780-3808: Replace the unconditional describe.skip with a normal
describe and make the before hook a non-arrow function so you can call
this.skip() if the environment lacks legacy token-staking authorization; e.g.,
change describe.skip("Pre-Upgrade Mode...") to describe("Pre-Upgrade Mode...")
and convert the before(async () => { ... }) to before(async function() { if
(!(await supportsTokenStaking())) return this.skip(); await createSnapshot();
await setupRealStaking(...); await deactivateChaosnetMode(...); await
walletRegistry.connect(...).registerOperator(...); }); similarly add or reuse a
small helper like supportsTokenStaking or capability check to detect when
token-staking/legacy flows are unavailable so the suite runs in capable
environments but is skipped gracefully otherwise (same pattern for the other
skipped suites).

In `@solidity/ecdsa/test/WalletRegistry.WalletCreation.test.ts`:
- Around line 2403-2466: The test contexts are unconditionally skipped via
context.skip which removes coverage for the challenge/slashing paths; change
each context.skip to a conditional wrapper that checks runtime capability (e.g.,
whether processSlashing exists) and only skips when unsupported. Concretely,
introduce a boolean like supportsProcessSlashing = typeof
legacyTokenStakingAt(staking, thirdParty).processSlashing === "function" (or
await staking.callStatic.processSlashing? catch) at the top of the suite or in a
before hook, then replace context.skip(...) with supportsProcessSlashing ?
context(...) : context.skip(...), keeping the inner tests that call
walletRegistry.challengeDkgResult, legacyTokenStakingAt(...).processSlashing,
assertGasUsed, etc., so the tests run when processSlashing is available and are
skipped otherwise.

In `@solidity/random-beacon/types/TokenStaking.extensions.d.ts`:
- Around line 10-39: The listed functions (stake, approveApplication,
increaseAuthorization, topUp, processSlashing and the other write signatures in
the same file) incorrectly use CallOverrides (read/call-only) — change their
overrides parameter to the appropriate transaction override type (Overrides from
ethers for non-payable writes, or PayableOverrides if the function is payable)
so tests and tx options (gas, nonce, value, etc.) are accepted; update the
signature for each write method (e.g., stake(..., overrides?: Overrides),
topUp(..., overrides?: Overrides|PayableOverrides as applicable),
approveApplication(..., overrides?: Overrides), increaseAuthorization(...,
overrides?: Overrides), processSlashing(..., overrides?: Overrides)) and adjust
imports if necessary.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 2e906162-c166-4bea-9ec2-e83d45cd37ba

📥 Commits

Reviewing files that changed from the base of the PR and between 349c9a3 and 0d1ebff.

📒 Files selected for processing (44)

• solidity/ecdsa/contracts/WalletRegistry.sol
• solidity/ecdsa/deploy/00_resolve_reimbursement_pool.ts
• solidity/ecdsa/deploy/00_resolve_token_staking.ts
• solidity/ecdsa/deploy/01_deploy_ecdsa_sortition_pool.ts
• solidity/ecdsa/deploy/02_deploy_dkg_validator.ts
• solidity/ecdsa/deploy/03_deploy_wallet_registry.ts
• solidity/ecdsa/deploy/07_approve_wallet_registry.ts
• solidity/ecdsa/deploy/09_deploy_wallet_registry_governance.ts
• solidity/ecdsa/deploy/etherscanVerification.ts
• solidity/ecdsa/deploy/tenderlyVerification.ts
• solidity/ecdsa/external/random-beacon-export/README.md
• solidity/ecdsa/external/random-beacon-export/deploy/01_deploy_reimbursement_pool.js
• solidity/ecdsa/external/random-beacon-export/deploy/02_deploy_beacon_sortition_pool.js
• solidity/ecdsa/external/random-beacon-export/deploy/03_deploy_beacon_dkg_validator.js
• solidity/ecdsa/external/random-beacon-export/deploy/04_deploy_random_beacon.js
• solidity/ecdsa/external/random-beacon-export/deploy/05_approve_random_beacon_in_token_staking.js
• solidity/ecdsa/external/random-beacon-export/deploy/06_authorize_random_beacon_in_reimbursement_pool.js
• solidity/ecdsa/external/random-beacon-export/deploy/07_deploy_random_beacon_governance.js
• solidity/ecdsa/external/random-beacon-export/deploy/08_transfer_governance.js
• solidity/ecdsa/external/random-beacon-export/deploy/09_deploy_random_beacon_chaosnet.js
• solidity/ecdsa/hardhat.config.ts
• solidity/ecdsa/tasks/initialize-wallet-owner.ts
• solidity/ecdsa/test/WalletRegistry.Authorization.test.ts
• solidity/ecdsa/test/WalletRegistry.CustomErrors.test.ts
• solidity/ecdsa/test/WalletRegistry.Rewards.test.ts
• solidity/ecdsa/test/WalletRegistry.Slashing.test.ts
• solidity/ecdsa/test/WalletRegistry.Upgrade.test.ts
• solidity/ecdsa/test/WalletRegistry.WalletCreation.test.ts
• solidity/ecdsa/test/WalletRegistryGovernance.test.ts
• solidity/ecdsa/test/fixtures/index.ts
• solidity/ecdsa/test/utils/operators.ts
• solidity/ecdsa/types/TokenStaking.extensions.d.ts
• solidity/ecdsa/types/chai.d.ts
• solidity/random-beacon/deploy/05_approve_random_beacon_in_token_staking.ts
• solidity/random-beacon/hardhat.config.ts
• solidity/random-beacon/test/RandomBeacon.Authorization.test.ts
• solidity/random-beacon/test/RandomBeacon.Callback.test.ts
• solidity/random-beacon/test/RandomBeacon.GroupCreation.test.ts
• solidity/random-beacon/test/RandomBeacon.Relay.test.ts
• solidity/random-beacon/test/RandomBeacon.Rewards.test.ts
• solidity/random-beacon/test/fixtures/index.ts
• solidity/random-beacon/test/system/e2e.test.ts
• solidity/random-beacon/test/utils/operators.ts
• solidity/random-beacon/types/TokenStaking.extensions.d.ts

[lrsaturnino]

LGTM