Foundry parity: platform deploy/upgrade scripts, tests, and deployments export so dincli can import Foundry deployments

[umeradl]

Task: Foundry Platform Deploy/Upgrade Parity — scripts, tests, and deployments export for dincli

Status: Open
Type: Standalone task (work from a fork)
Repo: https://github.com/InfiniteZeroFoundation/DevNet (base branch: develop)
Roadmap ref: P2 open item (Foundry migration — partially done, Hardhat remains active for deployment tooling) · P3-PR13 (Upgradeable Platform Contracts) · P3-6.1 (dincli CLI-Level Test Harness)

---

1. Project Summary

DIN (InfiniteZero) is a federated-learning network coordinated by Solidity contracts on Optimism Sepolia, operated through dincli, a Python/Typer CLI. The four platform-level contracts (DinCoordinator, DinToken, DinValidatorStake, DINModelRegistry) were converted to the Transparent Proxy upgrade pattern in PR #13, which is now merged into develop (see issue #33).

The Hardhat tree gained full deployment tooling with that merge: hardhat/scripts/deploy-platform.ts deploys the platform behind proxies and writes hardhat/deployments/<network>.json, which dincli system import-deployments reads to configure the CLI. The tests/dincli/ end-to-end harness (P3-6.1) runs against a platform deployed this way.

The Foundry tree has none of this: foundry/src/ however holds upgradeable contract versions (likely exact copies of hardhat ones) and foundry/script/ contains no deploy scripts. Per the roadmap, the Foundry migration is an open P2 item — this task closes the platform-deployment part of that gap so a local platform can be deployed with forge script, imported into dincli, and validated with the harness.

2. Setup

# Fork https://github.com/InfiniteZeroFoundation/DevNet and clone your fork
git clone https://github.com/<your-fork>/DevNet
cd DevNet
git checkout develop && git pull

# Fork point: pin your branch to this exact commit on develop
# (the PR #13 merge + harness integration — the hardhat tooling you are mirroring)
git checkout 91db47945a2f54fda45946798a5a7813bc742c31
git checkout -b feature/foundry-platform-deployments

# Baseline: everything must build and pass before you start
cd foundry && forge build && forge test
cd ../hardhat && npx hardhat compile && npx hardhat test

Read before writing anything:

1. hardhat/scripts/deploy-platform.ts, hardhat/scripts/upgrade-platform.ts, and hardhat/deploy/{constants,helpers,types}.ts — the tooling this task mirrors.
2. Documentation/technical/contracts/hardhat/ — per-file docs for the above, including wiring order and known coverage gaps.
3. dincli system import-deployments in dincli/cli/system.py — the consumer of the deployments JSON.
4. Documentation/technical/testing/dincli-testing-guide.md — how to run the tests/dincli/ harness.

3. Scope

3.1 Upgradeable contracts in foundry/src/

Bring the four platform contracts in foundry/src/ in line with the initializer-based transparent-proxy implementations now in hardhat/contracts/ (including the V2 stub implementations from hardhat/contracts/upgrade/ for upgrade testing).

3.2 Deploy script

foundry/script/DeployPlatform.s.sol: deploy the four platform contracts behind transparent proxies on a local anvil chain (started via ./foundry/anvil.sh), wire them together in the same order as deploy-platform.ts, and write a deployments JSON with the exact schema of hardhat/deployments/localhost.json:

{
  "dinToken": "0x...",
  "dinCoordinator": "0x...",
  "dinValidatorStake": "0x...",
  "dinModelRegistry": "0x...",
  "proxyAdmin": "0x..."
}

Suggested output path: foundry/deployments/localhost.json.

3.3 Upgrade script

foundry/script/UpgradePlatform.s.sol: counterpart to hardhat/scripts/upgrade-platform.ts, upgrading a deployed proxy to a V2 implementation.

3.4 Forge tests

Mirror the hardhat suites in foundry/test/: proxy deployment wiring, initializer / re-initialization protection (_disableInitializers() verified at runtime, not just in source), and state preservation across V2 upgrades — equivalents of hardhat/test/*.upgrade.test.ts and hardhat/test/DinValidatorStake.test.ts.

3.5 dincli import path

Extend dincli system import-deployments so the Foundry output is a first-class source — the JSON schema is identical, so this should mostly be default-path resolution (the current default is hardhat-only, with dincli network local mapped to hardhat localhost). Document the Foundry flow next to the hardhat one.

3.6 Harness verification

End-to-end proof: anvil up → forge script DeployPlatform → dincli system import-deployments --file foundry/deployments/localhost.json → run the tests/dincli/ harness and confirm it passes against the Foundry-deployed platform. Include the harness run output (or a summary of it) in the PR description.

4. Deliverables Checklist

• foundry/src/ platform contracts match the upgradeable versions in hardhat/contracts/ (plus V2 stubs)
• foundry/script/DeployPlatform.s.sol deploys behind transparent proxies and writes foundry/deployments/localhost.json in the hardhat schema
• foundry/script/UpgradePlatform.s.sol upgrade path works against a deployed platform
• Forge test suites mirroring the hardhat deploy/upgrade tests, all passing (forge test)
• dincli system import-deployments accepts the Foundry deployments file; flow documented
• tests/dincli/ harness passes against a Foundry-deployed platform on anvil
• Existing hardhat flow untouched and still passing (npx hardhat test)

5. Submission

• Fork develop at commit 91db47945a2f54fda45946798a5a7813bc742c31 (branch feature/foundry-platform-deployments, per §2).
• Push the branch to your fork and open a PR directly into develop on https://github.com/InfiniteZeroFoundation/DevNet.
• PR description: what was mirrored vs. deliberately done differently from the hardhat tooling, the harness verification result, and anything you'd do differently with more time.

6. References

• Developer/ROADMAP.md — P2 open item: "Foundry migration (partially done — Foundry test suite exists at foundry/; Hardhat remains active for deployment and verification tooling)"; P3-PR13 (Upgradeable Platform Contracts); P3-6.1 (dincli CLI-Level Test Harness)
• Issue Test Harness merge with PR # 13 #33 — PR Feature/platform upgradeable #13 merge + harness integration (commits 7a3efc3, 91db479)
• Developer/issues/dincli-native-proxy-deployment.md — related deferred work: native in-dincli proxy deployment (Option C); this task keeps the script + import-deployments flow
• Documentation/technical/contracts/hardhat/ — docs for the tooling being mirrored

[robertocarlous]

Noted, i will get to work on this

[robertocarlous]

Hi @umeradl,

For §3.5 does import-deployments need a new source foundry flag to auto-resolve the Foundry path, or is updating the help text to document --file foundry/deployments/localhost.json sufficient?

[umeradl]

Hi @robertocarlous — yes, let's add a --foundry flag rather than relying on help text alone. It should auto-resolve the Foundry deployments file from the default path, mirroring the existing hardhat default resolution in import_deployments (dincli/cli/system.py):

• Default (no flags): unchanged — hardhat/deployments/<network>.json, with dincli network local mapped to hardhat's localhost via _HARDHAT_NETWORK_FOR.
• --foundry: resolve to foundry/deployments/<network>.json with the same local → localhost mapping, matching the suggested output path foundry/deployments/localhost.json from §3.2.
• --file: keeps working as the explicit override. --file + --foundry together should be rejected as mutually exclusive.

Since the JSON schema is identical to the hardhat output, no parsing changes are needed — this is purely default-path resolution. Please also update the command's help/docstring to document the Foundry flow next to the hardhat one (per §3.5).

[umeradl]

Cross-referencing from #23 to avoid confusion: this task is not the same as the DIN-DAO work in #23, although both live in the foundry/ tree.

• Start DIN-DAO #23 is the DIN-DAO governance layer (multisig → timelock → token vote under foundry/src/dao/) — a later-phase track on Developer/ROADMAP.md (only the P3-5.1 governance hooks are current scope; DAO activation is devnet 3.0 onwards).
• This issue is current-P3 parity work scoped strictly to the 7 contracts already in foundry/src/ at develop — deploy/upgrade scripts, tests, and the deployments-JSON export for dincli system import-deployments. No DAO contracts involved.

If you've already worked on #23, this one should be low-friction — the Foundry toolchain and repo conventions carry over directly.

[umeradl]

Implemented by @robertocarlous in PR #35 and landed manually on develop (see the closing comment on that PR for the full review, fixes, and commit list): #35 (comment)

Closing.