Feat/pre upgrade sanity tests setup

[yurii-ssv]

No description provided.

[github-actions]

Gas Usage Report

Commit: 69c8910
Branch: HEAD
All within limits: No

Exceeded Limits

Operation	Limit	Actual	Over by
CANCEL_OPERATOR_FEE	38,000	34,865	+-8.25%
REMOVE_MULTIPLE_OPERATOR_WHITELIST_10_10	108,000	129,006	+19.45%
REMOVE_OPERATOR	75,000	76,818	+2.42%
REMOVE_OPERATOR_WHITELISTING_CONTRACT	52,000	57,036	+9.68%
REMOVE_OPERATOR_WHITELISTING_CONTRACT_10	109,500	126,292	+15.34%
REMOVE_OPERATOR_WITH_WITHDRAW	74,000	79,860	+7.92%
SET_MULTIPLE_OPERATOR_WHITELIST_10_10	137,000	157,821	+15.20%
SET_OPERATOR_WHITELISTING_CONTRACT	122,500	128,658	+5.03%
SET_OPERATOR_WHITELISTING_CONTRACT_10	316,000	337,000	+6.65%
SET_OPERATORS_PRIVATE_10	51,000	52,976	+3.87%
SET_OPERATORS_PUBLIC_10	29,000	30,915	+6.60%
UPDATE_OPERATOR_WHITELISTING_CONTRACT	79,500	85,799	+7.92%

[mtabasco]

@yurii-ssv I was wondering if we can reuse pieces/semantics between the current deployment scripts and forking tests.
Here is the suggestion. Can you please check? Thanks!

---

Convergence Opportunities

1. Duplicate Deployment Logic

The biggest redundancy is in ssvNetworkFullForkedFixture in fixtures.ts — it reimplements the entire upgrade flow (deploy modules, upgradeToAndCall, attach modules, set params) that already lives in scripts/upgrade.ts. They diverge in subtle ways:

• fixtures.ts hardcodes DEFAULT_UNSTAKE_COOLDOWN, DEFAULT_ORACLE_IDS, QUORUM_BPS, and applies params via individual daoNetwork.updateX() calls
• scripts/upgrade.ts reads everything from config.json and applies params via the upgrade initializer

The runInTestUpgradePath() branch in ssvNetworkFullForkedFixture is essentially a partial reimplementation of scripts/upgrade.ts --fork. The just upgrade-test-fork recipe already covers this exact sequence (fork → upgrade → attach modules → set params). The fixture's runInTestUpgradePath is redundant when upgrade-test-fork is used first.

2. Duplicate ForkConfigFile Type

scripts/common/fork-test.ts defines ForkConfigFile (with full protocolParams support + legacy fallbacks), while test/test-forked/v2.0.0/config.ts defines a different ForkConfigFile type (stripped down, no protocolParams). These should be the same type — the test-side config loader should import from scripts/common/fork-test.ts.

3. connection.ts vs fork.ts are near-identical

export async function getTestConnection() {
  const connection = await hre.network.connect("hardhat");

export async function getForkedConnection() {
  const connection = await hre.network.connect(selectedForkNetwork as any);

These are the same function differing only in the network name. They could be merged into a single getConnection(network?: string) that defaults to "hardhat".

4. Protocol param constants duplicated

The params object in ssvNetworkFullFixture uses constants from test/common/constants.ts. But when running forked, those same constants are re-applied via daoNetwork.updateX() calls rather than reading from the env vars that buildForkTestEnv already injects (FORK_NETWORK_FEE_ETH, FORK_MIN_OPERATOR_ETH_FEE, etc.). The forked fixture ignores those env vars.

---

Docs Improvement for Fork Testing

deployments/README.md covers the just upgrade-test-fork workflow well at a high level, but the test side has zero documentation on how fork testing actually wires together. The referenced test file fullIntegrationForked.test.ts uses ssvNetworkFullForkedFixture which has two completely different code paths (FORK_USE_DEPLOYED_STATE=true vs false) with no explanation.

Suggested additions to deployments/README.md under a new "Fork Testing in Detail" section:

## Fork Testing in Detail

### Two-phase workflow

1. `just upgrade-fork <env>` — runs `scripts/upgrade.ts --fork`, upgrades the proxy on Anvil, writes `upgrade-result.<version>.json`
2. `just test-fork <env>` — runs `scripts/run-forked-tests.ts`, which injects `FORK_CONFIG_PATH`, `FORK_USE_DEPLOYED_STATE=true`, and the protocol params as env vars, then spawns `hardhat test`

### Environment variables consumed by the test fixture

| Variable | Description |
|---|---|
| `FORK_CONFIG_PATH` | Path to the upgrade result JSON from phase 1 |
| `FORK_USE_DEPLOYED_STATE` | `true` = attach to already-upgraded proxy; `false` = re-run upgrade inside the test |
| `FORK_STRICT_DEPLOYED_STATE` | `true` = fail if deployed state is unreadable (no silent fallback) |
| `FORK_TEST_NETWORK` | Hardhat network name for the fork (default: `hardhat_forked`) |
| `FORK_BLOCK_NUMBER` | Pin to a specific block (auto-resolved from Anvil if unset) |

### Fallback mode

If `FORK_USE_DEPLOYED_STATE=true` but `SSVNetworkViews` is unreadable (e.g. stale Anvil), the fixture silently re-runs the upgrade inside the test unless `FORK_STRICT_DEPLOYED_STATE=true`. Use strict mode in CI to catch stale states early.

### Skipping the pre-upgrade step

Set `FORK_USE_DEPLOYED_STATE=false` (or omit `FORK_CONFIG_PATH`) to run the full upgrade inside the test. Useful for rapid iteration but slower and doesn't validate the actual `upgrade.ts` script path.

---

Summary

Issue	Recommendation
runInTestUpgradePath() duplicates scripts/upgrade.ts	Remove or delegate to upgrade script; rely on just upgrade-test-fork pre-step
Two ForkConfigFile type definitions	Test-side should import from scripts/common/fork-test.ts
connection.ts / fork.ts near-identical	Merge into getConnection(network?)
Forked fixture ignores FORK_* env protocol params	Read env vars from buildForkTestEnv output instead of hardcoded constants
Fork testing underdocumented on test side	Add "Fork Testing in Detail" section to deployments/README.md