DIN-Rep approval automation: verify task contracts and manifest CIDs before add-slasher / approveModel / approveManifestUpdate

Start with dincli/cli/dinrep.py, especially add-slasher and list-pending-requests, then read dincli/services/ipfs.py and the task contract artifacts in foundry. Trace how load_din_info() supplies platform addresses and how tests/test_dintoken.py uses CliRunner and monkeypatch. Done means contract code and wiring checks, manifest classification, guarded approval decisions, and the described tests all work, including dry-run behavior.

Summary

Model owners deploy their own DINTaskCoordinator / DINTaskAuditor, and the DIN-Representative approves them (and later manifest updates) by hand. Nothing checks that the deployed contracts are the canonical code, that they are wired to the real platform contracts, or that the manifest points at standard services. This issue adds DIN-Rep-side automation that runs those checks and auto-approves, auto-rejects, or flags each request.

This implements the Model Approval decision from the 2026-09-18 testnet session: standard files that match known CIDs are approved automatically, custom code is flagged for review, the network stays permissionless, and the DIN-Rep does not become a bottleneck.

Verified against origin/develop @ 37b2daf.

Problem

• dincli dinrep add-slasher checks nothing. dincli/cli/dinrep.py:189-246 sends DinCoordinator.addSlasherContract(addr) straight away. approve-registration-request / approve-manifest-update (dinrep.py:260, :282) are also plain transactions.
• Every trust anchor inside a task contract is set by the model owner.
  • DINTaskCoordinator.dinvalidatorStakeContract is a constructor argument (foundry/src/DINTaskCoordinator.sol:256).
  • dinToken comes from setDinToken, which is onlyOwner and can be called again at any time: no one-shot guard in either the coordinator (:1101) or the auditor (DINTaskAuditor.sol:433).
• Consequences for a model owner who deploys non-canonical code or wiring:
  • A modified coordinator can drop any access-control fix. For example, No. 181 moves dispute adjudication away from the model owner, and a modified coordinator could simply put it back.
  • A coordinator wired to a fake stake contract makes every slash a no-op, and makes owner()-based checks resolve to whoever deployed the fake.
  • Swapping dinToken after approval changes what dispute bonds and rewards are paid in.
• Manifest approval is fully manual. Most models reuse the standard services, and a manual review of each one is the bottleneck raised in the session.

Proposed change

All on the DIN-Rep side in dincli. No contract changes.

1. dincli dinrep verify-task-contracts --coordinator <addr> [--auditor <addr>]
   • Code: compare w3.eth.get_code(addr) with deployedBytecode.object from the canonical foundry artifact. Mask the byte ranges listed in deployedBytecode.immutableReferences first; modelId is immutable, so runtime code differs per model.
   • Accepted builds: a committed list of accepted build hashes per contract, one per release. That way a later docs-only .sol change doesn't fail verification for tasks deployed from an older release.
   • Wiring: read the public getters and compare them with the platform addresses from load_din_info():
     • dinvalidatorStakeContract() must be the platform DinValidatorStake.
     • dinToken() must be the platform DinToken.
     • The coordinator's dinTaskAuditorContract() and the auditor's coordinator must point at each other.
     • Both must report the same modelId.
   • Output: PASS / FAIL per check, with a reason.
2. add-slasher runs (1) first and refuses on FAIL. --force overrides it with a printed warning, for deliberately reviewed custom contracts.
3. dincli dinrep verify-manifest <manifestCID>
   • Fetches the manifest through dincli/services/ipfs.py.
   • Compares each service CID with a committed allowlist of standard service CIDs (the reference services in cache_model_0/services/).
   • A manifest with a task_contracts custom-ABI block counts as custom.
   • Result: STANDARD, or CUSTOM with the list of unknown CIDs.
4. dincli dinrep registry process-requests [--dry-run]
   • Walks pending requests the same way list-pending-requests does (dinrep.py:428).
   • Model request: run (1) on taskCoordinator/taskAuditor and (3) on manifestCID.
   • Manifest request: run (3) on newManifestCID.
   • Decision:
     • Contract FAIL → rejectModel. rejectModel does not refund the fee (DINModelRegistry.sol:261), so the report states that.
     • STANDARD + PASS → approveModel / approveManifestUpdate.
     • CUSTOM → leave pending and list it in the report for human review.
   • --dry-run prints the decisions without sending transactions.

Out of scope

• AI-assisted review of custom Python: the approval-automation analysis from the session (Santiago).
• Running process-requests on a schedule: a daemon job once PR No. 32 lands.
• An on-chain code-hash allowlist in DinValidatorStake.addSlasherContract: immutables make runtime code differ per model, so on-chain verification would need a factory that deploys the task pair. Worth revisiting post-mainnet.
• Making setDinToken one-shot: the contract-side fix is in No. 181 Stage 1. This issue only checks the value at approval time.

Verification

• pytest with typer.testing.CliRunner + monkeypatch, in the style of tests/test_dintoken.py:
  • code matches;
  • code differs;
  • only the immutable ranges differ (must PASS);
  • wrong stake or token wiring;
  • manifest STANDARD / CUSTOM;
  • add-slasher refuses on FAIL and proceeds with --force;
  • process-requests --dry-run report for a mix of requests.
• One integration-marked test: deploy a task pair on anvil with the real DeployPlatform flow, and check that verify-task-contracts PASSes.

Links

• No. 181: its adjudicator gate only holds if the coordinator is canonical code wired to the real DinValidatorStake, which this issue enforces.
• PR No. 183 touches dincli/cli/dinrep.py, so rebase onto it once it merges.
• Session notes 2026-09-18, Model Approval (M1 39:11–44:28) and decisions ("Automate approval for standard manifests; review custom code").