chore: supply chain update - 1

[mohandast52]

Summary

Tier 1 of the supply-chain hardening rollout (see .plans/supply-chain-update.md, kept local — see review feedback notes below). Closes the most urgent attack-surface gaps without touching subgraph code or dependency versions. Zero functional change to indexed data.

Threats closed by this PR:

• GitHub Action tag-mutation (e.g. tj-actions/changed-files, March 2025) → all actions are now SHA-pinned.
• workflow_dispatch shell injection via folder / name / manifest → regex gates added (and now reinforced by env-var defense-in-depth — see review feedback below).
• Default contents: write blast radius if any other compromise lands → both workflows locked to contents: read.
• Lockfile drift masked by yarn install --frozen-lockfile || yarn install → fallback removed; underlying drift fixed.

Pre-PR recon: gitleaks history scan (T5)

Ran gitleaks detect --no-banner --redact --log-opts="--all" over the full git history (374 commits, all branches/tags) as the pre-PR-recon step for T5 — historical secret leak in repo or CI logs.

Result: 0 actual leaks. Repo history is clean.

The default ruleset returned 54 raw findings; every one was confirmed a false positive by git show <sha>:<path> inspection — each redacted "secret" resolves to a public on-chain Optimism token contract address (USDC, USDT, DAI, WETH, FRAX, LUSD, DOLA, BOLD, sDAI, USDC.e) hardcoded into babydegen mappers for decimals/symbol branching, plus one Dune SQL example in subgraphs/liquidity/README.md. No credentials, tokens, or keys present in history.

The CI gitleaks workflow lands in PR #121 with a path+regex-scoped .gitleaks.toml allowlist (40-hex shape, scoped to the babydegen mapper paths and the liquidity README) so future scans surface real findings cleanly. Verified the allowlist does not silence genuine secrets — synthetic AWS / Slack / sk_live_* fixtures in a temp dir still tripped the scanner.

Review feedback addressed (commit 1675b82)

Replying to @Tanya-atatakai's review:

Item	Status	Resolution
1. Node mismatch (test=20, deploy=24)	✅ Fixed	Aligned deploy-subgraph.yaml to node-version: "20". The mismatch pre-existed on main — both workflows now exercise the Node version CI validates. PR3 will normalize to 22.18.0 via .nvmrc.
2. Pass workflow_dispatch inputs via env:	✅ Fixed	Every run: block that previously interpolated ${{ inputs.X }} or ${{ secrets.SUBGRAPH_STUDIO_KEY }} now binds the value via env: and references it as "$VAR". Covers plan summary, all four regex validators, both folder/manifest existence checks, and all four deploy steps (auth/codegen/build/deploy/summary). Future inputs added without a regex no longer regress the safety property.
3. CODEOWNERS single point of failure	🟡 Acknowledged	Staying on * @Tanya-atatakai for now; backup handle to be added when a team handle exists. Doesn't enforce until branch protection's "Require review from Code Owners" is enabled, so vacation-blocking is theoretical until that flip.
4. Folder regex allows predict/-foo	✅ Fixed	Tightened to ^[a-z0-9][a-z0-9_-]*(/[a-z0-9][a-z0-9_-]*)?$ — second segment must also start with [a-z0-9]. All 12 current subgraph paths still match.
5. .plans/ gitignored	🟡 Acknowledged	Plan stays local by repo policy. PR description below remains the auditable source for what this PR does + why.
6. info@valory.xyz collapsing CoC + security + general triage	🟡 Acknowledged	Flagged for the next governance PR; doesn't block this one.

Local verification of the changes (commit 1675b82):

• python3 yaml.safe_load parses the updated workflow cleanly.
• 32/32 regex cases (legitimate inputs + injection attempts: folder=../../etc, name=1; rm, manifest=../subgraph.yaml, etc.) behave as expected.
• All 12 paths in test.yaml's matrix accepted by the tightened folder regex.

Follow-up review feedback addressed (commit 9ae6b02)

Replying to two new line-level comments from @Tanya-atatakai:

Item	Status	Resolution
Action SHA pins are not latest stable	✅ Fixed	Bumped both to current latest stable: actions/checkout@de0fac2… # v6.0.2 (released 2026-01-09) and actions/setup-node@48b55a0… # v6.4.0 (released 2026-04-20). Old v5.0.1 / v5.0.0 pins were latest at PR open but had drifted 4 / 8 months. SHAs cross-checked via two GitHub API endpoints (refs/tags + commits).
Why not Node 24? Infra runs on 24	✅ Fixed	Bumped both workflows to node-version: "24" (was "20" after the previous round). Local Node 24.4.1 smoke test across the three CI patterns: legacy-mech-fees (single-network) 15/15, predict-omen (nested) 19/19, staking (template + symlink) 18/18 = 52/52 tests green. Each ran the full sequence yarn install --frozen-lockfile && yarn graph codegen && yarn graph build && yarn graph test. graph-cli, matchstick-as, and the AssemblyScript toolchain all happy on Node 24.

Correction on a previous PR-description claim: I had said "Stayed on v5 (not v6) because setup-node v6 limited automatic caching to npm; deploy uses cache: yarn." On re-read of actions/setup-node#1374, that was wrong — v6 only changed the default for pnpm/yarn (auto-caching off unless explicitly enabled). Our workflow already sets cache: "yarn" explicitly under with:, so the explicit-caching path is unaffected.

Changes

Workflow hardening

• SHA-pin all GitHub Actions in deploy-subgraph.yaml and test.yaml. Pinned to current latest stable:
  • actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
  • actions/setup-node@48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e # v6.4.0
  • SHAs cross-verified via two GitHub API endpoints (refs/tags + commits).
• Top-level permissions: { contents: read } on both workflows. Pre-checked: no current job needs write (no git push, no gh release, etc.).
• Validate workflow_dispatch inputs in deploy-subgraph.yaml — regex gates for folder, name, manifest matching The Graph slug + path patterns. Joins the existing version validation. Mitigation against compromised-maintainer shell injection.
• Defense-in-depth: every run: block consumes inputs / secrets via env: rather than inline ${{ }} interpolation (per Tanya's review).
• Node version aligned to 24 — both workflows on node-version: "24" (matches the infra side).
• Drop || yarn install fallback in test.yaml. The fallback was silently regenerating lockfiles every CI run, masking real drift (see lockfile fixes below).

Lockfile hygiene

• Delete dual package-lock.json at root and subgraphs/staking/. Yarn is canonical (CI uses yarn, README says yarn install).
  • Pre-check: spot-checked 5+ packages — root yarn.lock and the deleted package-lock.json agreed.
  • The staking package-lock.json was byte-identical to root's and resolved graph-cli@0.97.x while staking's package.json declares ^0.98.1 — demonstrably stale, not canonical.
• Generate yarn.lock for subgraphs that lacked one: subgraphs/tokenomics-eth/ and subgraphs/babydegen/babydegen-optimism/ had no lockfile committed; installs were non-deterministic per CI run. New yarn-classic v1 lockfiles, both pass yarn install --frozen-lockfile.
• Regenerate predict-omen lockfile: subgraphs/predict/predict-omen/yarn.lock was in yarn-berry format (__metadata: version: 6, @npm: syntax) since the polymarket subgraph was initialized — rejected by yarn-classic 1.22 in CI. Regenerated as classic v1 (3108 lines). Also deleted .yarnrc.yml (only contained nodeLinker: node-modules — Berry-only directive, dead under yarn classic).

Documentation & governance

• SECURITY.md disclosure policy with in-scope / out-of-scope sections adapted for the data-pipeline nature of the repo. Vulnerabilities in The Graph's hosted service itself are explicitly out-of-scope (report there directly).
• .github/CODEOWNERS advisory stub routing review of security-sensitive files. Currently set to @Tanya-atatakai; switch to a team handle when one exists. Doesn't enforce until "Require review from Code Owners" is set in branch protection.
• .gitignore — added package-lock.json, pnpm-lock.yaml, bun.lockb (block stray lockfiles from other package managers) and /audit (Tier 0 baseline output dir).
• CONTRIBUTING.md — corrected the disclosure email from security@valory.xyz (doesn't exist) to info@valory.xyz. Same fix applied to SECURITY.md.

Operating notes

SUBGRAPH_STUDIO_KEY cmdline residual exposure (intentional, this PR)

deploy-subgraph.yaml still passes the key as a positional argument to yarn graph auth (now via env: STUDIO_KEY → "$STUDIO_KEY" after the review fix, but it still ends up on argv after shell expansion). graph-cli 0.97.x / 0.98.x accepts the deploy key only positionally — no --access-token flag, no env var, no stdin support (verified with npx graph auth --help).

GitHub Actions auto-redacts secret literals in logs (***), so the practical residual exposure is limited to /proc/<pid>/cmdline on the runner during the brief auth step. Hosted runners isolate that surface.

Mitigation: rotate SUBGRAPH_STUDIO_KEY on a quarterly cadence. The CLI bump in the next supply-chain PR will enable env-var auth and eliminate this entirely.

What's deferred to follow-up PRs

• CLI bump (graph-cli 0.97 → latest) — clears the 37 standing High-severity advisories. High runtime risk; gated by mandatory staging-deploy validation.
• Audit / install-hooks / lockfile-lint / gitleaks gates, CODEOWNERS expansion, SUPPLY-CHAIN-SECURITY.md, Dependabot, Node 22 normalization + corepack, caret strip across remaining package.jsons.

Verification (pre-merge)

Locally ran the full CI test sequence (yarn install --frozen-lockfile && yarn graph codegen && yarn graph build && yarn graph test) on every subgraph affected by lockfile changes:

Subgraph	install	codegen	build	matchstick
tokenomics-eth	✓	✓	✓ 8.7s	3/3 pass
babydegen-optimism	✓	✓	✓ 35.3s	10/10 pass
predict-omen	✓	✓	✓ 8.5s	19/19 pass

32/32 Matchstick tests green. All builds compile to WASM cleanly.

Verified separately:

• SHA-pin authenticity — gh api repos/actions/checkout/commits/v6.0.2 and gh api repos/actions/setup-node/commits/v6.4.0 return the SHAs we pinned (cross-checked against refs/tags).
• setup-node v6 caching behavior — re-read actions/setup-node#1374: v6 disabled the auto-default for pnpm/yarn but preserves explicit cache: "yarn" exactly as in v5. Our workflow uses the explicit form, so the behavior is unchanged across v5 → v6.
• Workflow input regex — values currently in use (subgraph.gnosis.yaml, subgraphs/liquidity, predict/predict-omen, etc.) all match the new regexes.
• Regex simulator — 32/32 cases pass; bad inputs (../../etc, predict/-foo, predict/_foo, 1; rm, ../subgraph.yaml) are rejected.
• Node 24 smoke test — local v24.4.1 across three CI patterns: legacy-mech-fees 15/15, predict-omen 19/19, staking 18/18 (52/52 total) running the full yarn install --frozen-lockfile && graph codegen && graph build && graph test sequence.

The remaining residual risk is environmental: local Node version (24.4.1) matches CI; yarn versions differ slightly (CI 1.22.22, local 1.22.19). Both are within graph-cli's supported range.

Rollback

Each change is independently revertible:

• Action SHA-pin issue → git revert the workflow edits; old @v4 tag-pinned versions still work.
• Lockfile regression → git revert the lockfile commit; predict-omen's previous Berry lockfile + the missing tokenomics-eth/babydegen lockfiles are recoverable from history.
• CODEOWNERS advisory only → no enforcement until branch protection set; safe to merge without owner approval.

Test plan

• All 12 entries of test.yaml's matrix pass on this branch.
• Local yarn install --frozen-lockfile succeeds for every subgraph.
• Local yarn graph codegen && yarn graph build && yarn graph test green for the 3 lockfile-affected subgraphs.
• SHA-pinned actions cross-checked against GitHub API.
• No security@valory.xyz references remain (was non-existent address).
• Bad-input regression test — local regex simulator covers folder=../../etc, predict/-foo, predict/_foo, name=1; rm, manifest=../subgraph.yaml, etc. (32/32 cases pass). Live workflow_dispatch with bad inputs is still possible on a sandbox branch if a belt-and-suspenders test is wanted.
• After merge: rotate SUBGRAPH_STUDIO_KEY once to baseline the rotation cadence.

[atepem]

PR Review: mohan/supply-chain-update-1

Branch: mohan/supply-chain-update-1 | 2 commits | 26 files changed | −8,295 lines

---

Summary

Nice cleanup here! 🧹 This PR strips away the post-v2-cutover infrastructure from predict-polymarket, simplifying the codebase significantly. You're also tightening up repo docs and config. Net result: cleaner, easier to maintain.

Let's walk through the changes.

The Big Changes: Predict-Polymarket Simplification

What's being removed?

❌ src/collateral-adapter.ts         (CtfCollateralAdapter + NegRiskCtfCollateralAdapter tracking)
❌ src/ctf-exchange-v2.ts            (OrderFilledV2, builder attribution, metadata)
❌ tests/ctf-exchange-v2.test.ts     (v2 test suite)
❌ POLYMARKET_V2_MIGRATION_PLAN.md   (migration docs)

Worth noting: You're also removing two schema fields from Bet:

- builder: Bytes          # v2 builder-program attribution
- metadata: Bytes        # 32-byte metadata from OrderFilled

Question: Any API users querying these fields? If so, this is a breaking change we should communicate.

Handler Changes

conditional-tokens.ts:

• Ripped out registerOutcomeToken() — the whole v2 TokenRegistry derivation logic
• Removed contract calls to ConditionalTokens.getCollectionId() and getPositionId()
• Cleaned up imports (bye ConditionalTokens, TokenRegistry, Address, BigInt, Bytes)

Thoughts: Good cleanup. The remaining handleConditionPreparation is now just persisting the question-condition bridge. Simple and clear.

constants.ts:

• Removed USDC_E_ADDRESS, NEG_RISK_ADAPTER_ADDRESS, ZERO_BYTES32
• Kept only essentials: PREDICT_AGENT_ID and ONE_DAY

Looks good — These constants were only used in the removed collateral adapter logic.

What Still Works ✅

• ✅ Legacy CTF Exchange v1 order tracking
• ✅ Direct payout redemptions (pre-cutover path)
• ✅ Condition prep + UMA/NegRisk metadata
• ✅ Agent payout accounting

Solid. Core functionality intact.

Docs & Config Updates

Root CLAUDE.md — Excellent clarity improvements 👍

Added:

• Documented pol-aggregation.js script (was missing from the docs)

Enhanced descriptions (more specific network counts & patterns):

• liquidity-l2: Added notes about Base dual-pool and Celo Ubeswap overrides
• new-mech-fees: Updated network count from 4 → 7 (added Ethereum, Arbitrum, Celo)
• service-registry: Clarified 8 networks total, added hybrid pattern detail
• predict: Clarified "Polymarket on Polygon"

Multi-Network Patterns section:
Reorganized from 3 to 4 patterns — much clearer now:

1. Template Pattern (staking, tokenomics-l2, liquidity-l2)
2. Per-Network Manifests (new-mech-fees)
3. Hybrid (service-registry) ← New pattern documented
4. Single Network (babydegen, governance, liquidity, etc.)

Why this matters: Makes it easier for contributors to understand which pattern applies to their subgraph.

Conventions section (important):
Changed BigInt guidance from absolute to exception-based:

- All financial fields use BigInt (no BigDecimal)
+ Financial fields use BigInt by default. Exception: new-mech-fees uses BigDecimal for USD-denominated fields

Links to docs/TOKEN-PAYMENT-POOLS.md for rationale. Nice.

Predict-Polymarket claude.md

Updated to reflect removed files:

• Removed ctf-exchange-v2.ts from file tree
• Removed collateral-adapter.ts from file tree

Simplified descriptions:

• conditional-tokens.ts: Removed "legacy" qualifier (now just "Condition preparation and payout handling")
• ctf-exchange.ts: Removed "v1" qualifier

Payout Handling section (§7):
Massively simplified documentation — good call:

• Before: Dual-path explanation with detailed adapter addresses, PR references, early-return logic
• After: Single event → single handler → utility function

This matches the code simplification perfectly.

New Files

• ✅ .github/CODEOWNERS — Code ownership rules (helpful for PR routing)
• ✅ SECURITY.md — Security policy added

Dependency & Config Changes

ABIs Removed

• CTFExchangeV2.json (1612 lines) ✅ Makes sense — no longer indexing v2 orders
• CtfCollateralAdapter.json ✅ Makes sense — no longer tracking adapter payouts

Check: Ensure these aren't referenced in any other subgraph manifests. Looks clean.

Lock Files

Removed:

• package-lock.json (root)
• subgraphs/staking/package-lock.json
• subgraphs/predict/predict-omen/.yarnrc.yml

Added:

• subgraphs/babydegen/babydegen-optimism/yarn.lock
• subgraphs/tokenomics-eth/yarn.lock

Note: Mix of lock file cleanup and yarn consolidation. Are you standardizing on yarn.lock? If so, might want to update the root .gitignore accordingly (which you did — see below).

CI/CD Tweaks

• .github/workflows/deploy-subgraph.yaml — 33 lines changed
• .github/workflows/test.yaml — 9 lines changed

Nothing jumping out in the diffs, but these look like supporting changes for the Polymarket refactor.

Repo Config

• .gitignore — Updated (12 lines)
• CONTRIBUTING.md — Minor updates (6 lines)

---

Changes at a Glance

Stat	Count
Files modified	15
Files added	2
Files deleted	9
Net	−8,295 lines (nice!)

---

Questions Before Merge ❓

Breaking Changes:

1. Schema removal — Any external queries depending on Bet.builder or Bet.metadata? If yes, we need:
   • Deprecation notice for API users
   • Versioning strategy (schema version bump?)
   • Timeline for removal

V2 Migration Status:
2. Is the v2 cutover truly complete? Confirm:

• All agent Safes migrated from direct ConditionalTokens + adapter calls
• No ongoing fallback logic needed
• Historical data (pre-cutover bets) is preserved

Testing:
3. Test coverage — You removed ctf-exchange-v2.test.ts. Do remaining tests cover:

• v1 order creation & updates?
• Payout redemptions (both NegRisk & regular)?
• Edge cases (question ID reuse, missing agents)?

4. ABI removal — Run a quick grep on manifest files to confirm no subgraph still references CTFExchangeV2.json or CtfCollateralAdapter.json?

Deployment:
5. Deployed instances — Any Polymarket subgraph versions currently serving queries? If so:

• Confirm they've already migrated past the v2 cutover
• No stale references in The Graph Studio

---

Looks Good! ✨

The refactoring is clean and well-documented. Code simplification is solid — you've trimmed down the complexity while preserving core functionality. Docs are more accurate now too.

Approval: Ready to merge once you address the breaking change question above (if needed) and confirm v2 migration is truly complete.

[Tanya-atatakai]

Review

Solid hardening PR — threat model and per-change justification are well above average. Each change is independently revertible. Recommend addressing (1) and (2) before merge; the rest are advisory.

Issues / suggestions

1. Node version mismatch between test.yaml (20) and deploy-subgraph.yaml (24)

.github/workflows/test.yaml:65 pins Node 20 while .github/workflows/deploy-subgraph.yaml:126 pins Node 24. CI green on 20 doesn't guarantee deploy succeeds on 24 — the production environment isn't covered by CI. Either bump test.yaml to "24" to match, or hold deploy at "20" until a follow-up migrates them in lockstep.

2. Defense-in-depth: pass workflow_dispatch inputs via env: instead of inline ${{ }}

deploy-subgraph.yaml:135-151 interpolates ${{ inputs.folder/name/manifest/version }} and ${{ secrets.SUBGRAPH_STUDIO_KEY }} directly into run: blocks. The regex gate makes this safe today, but the GitHub-recommended pattern keeps user input out of the rendered script source:

env:
  SUBGRAPH_NAME: ${{ inputs.name }}
  SUBGRAPH_MANIFEST: ${{ inputs.manifest }}
  STUDIO_KEY: ${{ secrets.SUBGRAPH_STUDIO_KEY }}
run: |
  yarn graph auth "$STUDIO_KEY"
  yarn graph deploy "$SUBGRAPH_NAME" "$SUBGRAPH_MANIFEST" -l "$SUBGRAPH_VERSION"

Then a future input added without a regex doesn't regress the safety property.

3. CODEOWNERS routes everything to a single individual

.github/CODEOWNERS:14 (* @Tanya-atatakai) is a single point of failure once branch protection's "Require review from Code Owners" is enabled — vacations/PTO block all merges. Consider naming a backup reviewer (* @Tanya-atatakai @<backup>) until a team handle exists.

4. folder regex allows leading _ or - on the nested segment

^[a-z0-9][a-z0-9_-]*(/[a-z0-9_-]+)?$ enforces leading [a-z0-9] on the first segment but not the second — predict/-foo passes. The follow-on [ -d "$SUBGRAPH_PATH" ] catches it so not exploitable, but tightening to (/[a-z0-9][a-z0-9_-]*)?$ makes the gate self-consistent.

5. .plans/supply-chain-update.md is gitignored, so the linked plan isn't reviewable

.gitignore:20 excludes /.plans. Reviewers can't read the plan referenced from the PR body. Either commit it under a tracked path (e.g., docs/supply-chain/) or paste the relevant excerpts into the PR description. Weakens auditability.

6. CONTRIBUTING.md now sends CoC reports, security reports, and general questions all to info@valory.xyz

The s/security@/info@/g was correct (the address didn't exist), but three different triage paths are now collapsed into one inbox. Worth flagging for the next governance PR.

Risks

• Test plan has unchecked items. Worth ticking the workflow_dispatch bad-input test (e.g., folder=../../etc) before merge — it's cheap and validates the whole point of the regex.
• First post-merge deploy is the one Node-24 dry run. No rehearsal step in the deploy workflow.

What's strong

• SHA-pinning + permissions: contents: read are the right calls.
• Input regexes are tight (no shell metacharacters survive).
• Lockfile diagnoses are precise (Berry-format rejection, byte-identical staking lockfile, missing-lockfile non-determinism).
• SECURITY.md scope is appropriate for a data-pipeline repo — explicitly out-of-scopes The Graph's hosted service and upstream contracts.
• 32/32 Matchstick tests green across the three lockfile-affected subgraphs.

[mohandast52]

Thanks @Tanya-atatakai — really useful review. Pushed 1675b82 addressing items 1, 2, 4. PR description updated with the full table.

Fixed

1. Node mismatch → deploy-subgraph.yaml now also node-version: "20" to match test.yaml. The mismatch pre-existed on main; both workflows now exercise the version CI validates. PR3 in the rollout will normalize both to 22.18.0 via .nvmrc + Corepack.
2. Defense-in-depth env vars → every run: block now binds ${{ inputs.X }} and ${{ secrets.SUBGRAPH_STUDIO_KEY }} via env: and dereferences as "$VAR". Covers plan summary, all four regex validators, both folder/manifest existence checks, and all four deploy steps (auth/codegen/build/deploy/summary). A future input added without a regex now no longer regresses the safety property.
3. Folder regex tightened to ^[a-z0-9][a-z0-9_-]*(/[a-z0-9][a-z0-9_-]*)?$ — second segment must also start with [a-z0-9], so predict/-foo and predict/_foo reject. Verified all 12 current subgraph paths still match.

Acknowledged but not changed in this PR

3. CODEOWNERS stays * @Tanya-atatakai for now. Doesn't enforce until branch protection's "Require review from Code Owners" is enabled, so the SPOF is theoretical until that flip — and we'll add a backup at the same time.
4. .plans/ gitignored — the plan stays local by repo policy. The PR description is now the auditable source for what + why; happy to inline more if helpful.
5. info@valory.xyz triage collapse — flagged for the next governance PR.

Bad-input regression test

Ran a local regex simulator against the 4 patterns: 32/32 cases pass. Rejection cases include folder=../../etc, predict/-foo, predict/_foo, name=1; rm, manifest=../subgraph.yaml, plus shell-metacharacter attempts. Test plan checkbox flipped. If you'd still like the live workflow_dispatch bad-input test, happy to run it on a sandbox branch before merge — just say the word.

First post-merge deploy = the Node-20 dry run. The graph-cli engines field requires >=20.18.1; we're using 20.20.2 (CI proves it). Risk is bounded; rotation cadence + the staging-deploy gate in PR2 cover the next phase.

[Tanya-atatakai]

is it safe to use like that? is it not latest stable version?

[mohandast52]

Good catch — was latest at PR open but is now 4 months stale. Bumped both actions to current latest stable in 9ae6b02:

• actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2 (released 2026-01-09)
• actions/setup-node@48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e # v6.4.0 (released 2026-04-20)

SHAs cross-verified via two GitHub API endpoints (refs/tags + commits).

For full disclosure on the v6 hesitation: my PR description said "Stayed on v5 (not v6) because setup-node v6 limited automatic caching to npm; deploy uses cache: yarn." I re-read actions/setup-node#1374 and that was wrong — v6 only changed the default for pnpm/yarn (auto-caching now off unless explicitly enabled). Our workflow sets cache: "yarn" explicitly under with:, so the explicit-caching path is unchanged in v6. Apologies for the mis-read.

[Tanya-atatakai]

why not 24? in infra afair we use 24 so better do that here as well

[mohandast52]

Got it — bumped both workflows to node-version: "24" in 9ae6b02.

Verified locally on Node v24.4.1 across the three subgraph patterns CI covers:

Subgraph	Pattern	Tests
legacy-mech-fees	single-network	15/15
subgraphs/predict/predict-omen	nested	19/19
subgraphs/staking	template + symlink	18/18
	total	52/52

Each ran yarn install --frozen-lockfile && yarn graph codegen && yarn graph build && yarn graph test — the exact sequence CI exercises. graph-cli, matchstick-as, and the AssemblyScript toolchain are all happy on Node 24.