Meeting briefs: what happened since the last meeting

[umeradl]

A running log for our maintainer meetings. Just before each meeting, a comment goes here summarising what happened on GitHub since the previous one, so we start from the same picture and spend the meeting on decisions rather than catching up.

Format of each brief (one top-level comment per meeting, titled with the period it covers):

1. Headlines: the 3–5 things that matter.
2. Merged: PRs that landed on develop, with author and merger.
3. Opened / closed: new PRs and issues, closures, and anything closed without merging and why.
4. Discussions: decisions or open questions in other threads.
5. Open PRs: what each one is blocked on, and by whom.
6. For the meeting: questions that need a decision, and who owes what.

Replies under a brief are for corrections or follow-ups on that period. New topics go in their own thread. Status lives in the PRs and issues themselves; this thread only points at them.

cc @Santiagocetran @robertocarlous @Abidoyesimze @abrahamnash

[umeradl]

Brief: Mon 2026-11-02 → Fri 2026-11-06

Headlines

• The develop merge queue is live (11-02, Discussion 208). 14 PRs merged through it this week. develop CI has been green on every push since 11-02 evening; the one red run (cf80216) was fixed by PR No. 311.
• task_061026_21 (Full-GI alignment): Parts A+B (PR No. 287) and the Part C commands (PR No. 302) landed. Part C deploy (PR No. 314), Part D (PR No. 313, draft) and Part E (PR No. 315, draft) are open. A local isolated run now walks one complete GI end to end: 186/186 integration tests.
• S5 retro posted (Discussion 208, 11-05). @robertocarlous and @Santiagocetran agreed with ending the shadow window.

Merged (14)

Date	PR	Author → merged by	What
11-02	No. 308	umermjd11 → Santiagocetran	CI runs on merge_group so CI OK reports in the queue
11-02	No. 296	Santiagocetran → umeradl	Manual Full GI runs report their outcomes
11-02	No. 286	umermjd11 → Santiagocetran	MECHANISM_DESIGN: S5 escalation is MIN_STAKE + jail
11-02	No. 261	robertocarlous → Santiagocetran	cache_model_0 ABIs from foundry + deploy constructors (BL-25)
11-02	No. 254	robertocarlous → Santiagocetran	dincli system verify-deployment drift check
11-02	No. 311	umermjd11 → robertocarlous	Fix DeployPlatform/UpgradePlatform test race on DEPLOYMENTS_NETWORK
11-02	No. 304	Santiagocetran → umeradl	Docs: client training separate from model submission
11-02	No. 310	umermjd11 → Santiagocetran	MAINTAINING + skills: land PRs through the merge queue
11-03	No. 302	umermjd11 → robertocarlous	dincli rewards, encryption-key, release-slots, dispute commands
11-03	No. 289	robertocarlous → Santiagocetran	cache_model_1: Fashion-MNIST CNN example model
11-04	No. 280	abrahamnash → umeradl	README refresh, CITATION.cff, impact page
11-04	No. 241	Santiagocetran → umeradl	Keep diagnostics from isolated integration runs
11-05	No. 287	umermjd11 → umeradl	Richer GI states re-landed (peer-rule bypass logged in Discussion 170)
11-05	No. 293	Abidoyesimze → umeradl	DP docs: noise_multiplier is independently destructive, with a reproducible sweep script

Opened / closed

• New PRs: No. 310, No. 311 (both merged), No. 312 (dependabot), No. 313, No. 314, No. 315 (task 21).
• Closed without merging: No. 312, the dependabot pip bump for cache_model_1. None of its six requirements files could be installed: torch==2.15.0 against torchvision==0.21.0, and aiohttp 3.14.4 against yarl==1.24.2. A torch upgrade should be a separate PR that bumps torch, torchvision and yarl together.
• New issue: No. 309. Aggregators who never submit still earn reward weight in finalized T1/T2 batches. Not triaged yet.
• Issues closed (7): No. 244, No. 245, No. 246, No. 266, No. 274, No. 285, No. 307.

Discussions

• 208: merge-queue go-live (11-02) and the S5 retro (11-05). Agreed so far: whoever gives the final required approval queues the PR, and second-key or re-review requests get a ping in the PR after 2 working days.
• 170: two peer-rule bypasses logged on 11-05. PR No. 287 was merged by its own author's account, and develop stayed green. PR No. 218 was enqueued by a co-author and ejected on failed checks, so nothing landed.
• 231: @abrahamnash asked on 11-03 whether assignAuditTestDataset should be limited to AuditorsBatchesCreated. Today the owner can overwrite a batch's test data, and its commitment, after assignment. Still unanswered.

Open PRs

PR	Author	Blocked on
No. 314	umermjd11	Peer review (Santiagocetran or robertocarlous). CI green
No. 313	umermjd11	Draft; waits on No. 314, then peer review
No. 315	umermjd11	Draft; waits on No. 313 and No. 314. CI green
No. 305	Santiagocetran	CI red: check_task_artifacts.py says the cache_model_0 creation bytecode differs from the build. The code is identical; only the solc metadata hash differs, so the artifacts need regenerating from a clean npm ci && forge build. Then re-reviews from umeradl and robertocarlous
No. 292	Abidoyesimze	Approved by umeradl; the 10-28 change requests from Santiagocetran and robertocarlous need a re-review at a9787c9
No. 259	Abidoyesimze	Approved by umeradl (second key); needs robertocarlous's peer approval at 837ce49
No. 218	robertocarlous	Approved by Abidoyesimze; ejected from the queue on 11-05 on failed checks, needs a fix and re-queue
No. 253	robertocarlous	Merge conflict + umeradl's 11-05 change request
No. 294	Abidoyesimze	Santiagocetran's change request

For the meeting

1. Discussion 231: should assignAuditTestDataset check the GI state? In task 21, or a separate issue?

• What @abrahamnash found (11-03): DINTaskAuditor.assignAuditTestDataset checks onlyOwner, onlyCurrentGI and pendingReassignment, but not the GI state. So the model owner can still overwrite a batch's test data, and its commitment, after AuditTestDataAssigned, or even once LMSevaluationStarted has begun.
• Why it matters: auditors score against the committed test data. If the owner can swap it mid-evaluation, they can steer scores for specific batches. That undermines the commitment the richer GI states (PR No. 287) were meant to give.
• Proposed fix: allow assignAuditTestDataset only in AuditorsBatchesCreated. Any change after that goes through reassignAuditTestDataset, which only runs via a dispute.
• Decide:
  • (a) Put it into task_061026_21. Parts D and E are still open, but A–C have landed, so it would be a new contract change on top.
  • (b) A separate issue. Contract changes in foundry/src need the second key, and keeping them out of task 21 lets Parts D and E close sooner.
  • This existed before PR No. 287 too. Abraham said it's not a reason to hold that PR. No reply on the thread yet (3 days).

2. Issue No. 309: aggregators who never submit still earn reward weight. Triage and owner.

• The bug: finalizeT1Aggregation and finalizeT2Aggregation (DINTaskCoordinator.sol around :975 and :1123) add aggregatorWeight and totalAggregatorWeight for every aggregator assigned to a finalized batch. The increment sits outside the submitted check. A batch finalizes with 2 of 3 reveals, so an aggregator who never commits, or commits and never reveals, takes the same share of the aggregator pool as the two who did the work. They do get S2-slashed, but they keep the reward.
• Proposed fix (in the issue): move both increments inside the submitted check, so the claim maths stays the same. Update the NatSpec, DINTaskCoordinator.md and MECHANISM_DESIGN.md. Add RewardEngine.t.sol tests for both tiers, including TA_NoRewardEarned.
• Decide:
  • Is this a mechanism change needing sign-off, or a bug fix against the intended design? I'd say a bug fix: the intent is "only revealers earn".
  • Who owns it? It touches foundry/src, so robertocarlous or Abidoyesimze implement it and the other reviews, plus the second key.
  • Should it go through din-approve-issue first?
  • It's labelled bug, with no assignee and no comments.

3. Reviews: who takes what

• PR No. 314 (task 21 Part C deploy: deploy sets DinToken on both task contracts, and --model-id defaults to the next registry ID):
  • It's ready, CI is green, and it has 8 new tests.
  • Santiagocetran and robertocarlous are requested. umeradl can't approve: it's Umer's own PR.
  • It blocks PRs No. 313 and No. 315.
• PR No. 313 (task 21 Part D: the integration suite walks one complete GI on the foundry contracts):
  • Still a draft, waiting on No. 314. A local isolated run passes 186/186.
  • It also carries three dincli fixes that the full GI uncovered:
    • per-wallet commit caches for auditors and aggregators
    • register exits 1 when it fails
    • evaluate no longer fails to decrypt every batch's test data (a 0x-prefix bug that left nothing committed, so lms-evaluation close reverted)
  • Reviewer: Santiagocetran (dincli/tests owner) is the natural fit.
• PR No. 315 (task 21 Part E: GI docs): a draft that goes after No. 313 and No. 314. Any maintainer can review it.
• PR No. 292 (update_laplace DP mechanism):
  • umeradl approved it at a9787c9.
  • @Santiagocetran and @robertocarlous still have change requests from 10-28, at bb48f2e. Both asked for (1) qualified sensitivity and calibration claims, and (2) an end-to-end clipping test. Both are now in.
  • GitHub keeps counting a change request until the person who made it re-reviews. Ask: both of you re-review at a9787c9.
• PR No. 259 (gas caching in foundry/src hot paths):
  • umeradl approved it at 837ce49 as the second key.
  • The peer approval is missing. @robertocarlous last checked it on 10-26, at 6493426, and his formal reviews were dismissed when new commits were pushed.
  • Two commits since need a peer: bec5dd0 (new finalizeT2Aggregation caching) and 837ce49 (the develop merge).
  • Ask: robertocarlous re-reviews 6493426..837ce49 and approves. It's past the 2-working-day mark (comment of 11-05).

4. PR No. 305 (disabled models can't start new GIs): what's left

• CI is red on 2d9f5c9 (11-06). The new check_task_artifacts.py reports creation bytecode differs from build for cache_model_0/abis/DINTaskCoordinator.json and DINTaskAuditor.json.
  • umeradl reproduced it locally with forge 1.7.1, the same version as CI.
  • The contract code is byte-identical; only solc's metadata hash at the end differs. So the committed artifacts were built from source that differs from the commit, most likely uncommitted local edits.
  • Ruled out: submodules, remappings / node_modules, compiler settings (all pinned in foundry.toml), and the hardhat build.
  • Fix: regenerate both artifacts from a clean npm ci && forge build on the committed tree, then update the cache_model_0/manifest.json CIDs that point at them.
  • In CI the artifact check runs before the size gate and forge test, so neither has run on 2d9f5c9 yet. Locally, after a clean build, the size gate passes and forge test gives 534 passed, 0 failed, so nothing else is hiding behind the artifact failure.
• Reviews after that:
  • umeradl's 10-30 approval was dismissed by later pushes. Five pushes since then need re-review, including the new protocol-version check in the deploy CLI.
  • @robertocarlous's change request (the BL-34 row) was fixed in 6970f5d, but it still needs his re-review.
  • It touches foundry/src, so it needs a peer approval plus the second key.
  • Mechanism sign-off: Abraham's design decision is on issue No. 224 (10-26, decision 1: disabling a model must stop new GIs, with the check in the auditor). umeradl's 10-30 review asked for Abraham's approval as well. Decide whether the decision on issue No. 224 covers that, or whether we want an explicit sign-off on the PR.

5. Dependencies: PR No. 312 was security-driven, not routine

• PR No. 312 (closed) bumped torch 2.6.0 → 2.15.0 in cache_model_1 without bumping torchvision, so none of its requirements files could be installed.
• It came from Dependabot's security updates, not a version-update config: there's no .github/dependabot.yml on develop. So the underlying need, getting off torch==2.6.0, is still open, and it applies to every reference model and cid_services, not just cache_model_1.
• Maintainers can see the details under the repo's Security → Dependabot alerts. I'll go through the torch items in the meeting rather than here.
• Decide:
  • (a) A coordinated upgrade PR: torch + the matching torchvision in every requirements file, plus the other flagged Python pins. Then a full GI run to confirm the reference models still train and score.
  • (b) A .github/dependabot.yml that groups torch + torchvision, so future security PRs bump them together instead of breaking the install.
  • (c) Who triages the remaining alerts, including the JS dev-tooling ones under hardhat/ and foundry/?
  • Owner?

[Santiagocetran]

Small update on PR No. 305: the artifact mismatch is resolved, and CI is green on c8a7224.
The diagnostics showed identical source hashes and compiler settings, except for two auto-detected dependency remappings. Local builds selected the copies under openzeppelin-contracts-upgradeable, while CI selected those under openzeppelin-contracts. Those paths changed Solidity’s metadata hash.
Pinning both remappings fixed reproducibility. No contract logic, bundled artifacts, or manifest CIDs needed changing.
Fresh reviews from @umeradl and @robertocarlous, the required second sign-off, and clarification of the mechanism sign-off remain outstanding.