Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Start DIN-Indexer

Open
  • Is something wrong?
#24 8 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@robertocarlous is already working on this.

Since Jul 15, 2026.

Assessment

This issue has not been assessed yet.

Description

Long run

Branch: feat/din-indexer
Assignee: @robertocarlous
Roadmap ref: P4-IDX1 (design) · P4-IDX2 (implementation) · P4-IDX3 (integration) · Developer/issues/indexer.md

Long-running issue. This was Option B of Robbert's original two-option task (June 2026); he chose Option A — upgradeable platform contracts, delivered as PR #13 and tracked in Developer/tasks/task_240626_0b.md. Option B now becomes its own effort here, aligned with the P4-IDX work-package series (scheduled Oct–Nov 2026, but design work can start earlier). Detailed task files under Developer/tasks/ will follow.

Goal

Build an indexer over the events of the 4 platform-level contracts (DinCoordinator, DinToken, DinValidatorStake, DINModelRegistry) and wire at least one real dincli RPC-loop call site to query it instead of enumerating on-chain counters over RPC.

Guiding principle (from Developer/issues/indexer.md): contracts stay the canonical coordination/settlement layer with strong events; the indexer owns filtering, pagination, dashboards, and historical queries. No storage-heavy on-chain enumeration for read convenience.

Scope

Design (P4-IDX1)
  • Choose the indexing approach and document the tradeoff: The Graph Protocol subgraph (preferred — production experience) vs. a lighter alternative (Ponder, or a custom event-poller backed by a local DB) if local subgraph test infra is a blocker
  • Entity schema covering all event streams of the 4 platform contracts (registrations, requests/approvals, stake/slash/blacklist, fee changes, transfers)
  • subgraph.yaml + schema.graphql (or the equivalent for the chosen tool)
  • Local Graph node (or equivalent) running against the local Hardhat chain for development testing
  • Event-coverage audit: which meaningful state transitions currently emit no event, or events with insufficient/unindexed fields, for clean state reconstruction — propose minimal contract-side event additions rather than storage changes
  • Daemon event schema: define which events dind needs to subscribe to and current coverage gaps — this feeds P4-7.1 (on-chain event listening) in the "start DIN daemon" issue (#21)
Implementation (P4-IDX2)
  • Mapping handlers for all platform-contract events; verify entities index correctly against test transactions on the local node
  • Replace the pending-request enumeration loop in dincli/cli/dindao.py (lines ~441–465: for idx in range(totalModelRequests) and the matching manifest-request loop) with an indexer-backed query, proving the integration end-to-end
  • Local run instructions (setup steps, docker-compose if needed) + ≥3 example queries covering validator registry, model registry, and reward/slash history
  • Write-up: approach chosen and why, integration point, and the follow-up candidate loop sites — known ones today: dincli/cli/modelownerd/lms.py (~line 62) and aggregation.py (~lines 76, 95, 136)
Integration & wrap-up (P4-IDX3)
  • Wire the indexer into the dincli test suite; the replaced call site passes tests against the indexed local node
  • Handoff notes: what follows in P5+ (task-level contract indexing via dynamic data sources, event-schema extensions for dind)
  • Doc-correction pass on Developer/issues/indexer.md: note stale references or contradictions with current contract code (same convention as the PR #13 doc-inaccuracy list)

Explicitly out of scope

  • Dynamic data sources for task-level contracts (DINTaskCoordinator/DINTaskAuditor) — materially harder Graph pattern with its own deploy/hosting story; deferred to P5+, document as follow-up only
  • Rewriting dincli's general data-access layer (DinContext stays as-is beyond the one wired call site)
  • Hosting / production deployment of the indexer
  • Governance dashboards — the DIN-DAO issue (#23) designs its contracts events-first so this indexer can cover them later

Dependencies & sequencing

Per Developer/ROADMAP.md, P4-IDX1 depends on stable contract ABIs (P3-6.3b) and proxy contracts deployed (PR #13) — indexing against ABIs that are still churning means redoing mappings. Design work (approach tradeoff, entity schema, event-coverage audit) is safe to start earlier; hold mapping implementation until the ABI surface settles.

References

  • Developer/issues/indexer.md — the indexer-first architecture blueprint (events-first contract design, what stays on-chain vs. moves to the indexer)
  • Developer/ROADMAP.md — P4-IDX1/IDX2/IDX3 work packages
  • Original task spec: Option B in Robbert's June task (kept outside the repo); condensed Option A record at Developer/tasks/task_240626_0b.md
  • Related issues: #21 "start DIN daemon" (consumes the daemon event schema), #23 "Start DIN-DAO" (future governance event streams)

Branching note

feat/din-indexer on the main repo (contributor branch, not a fork-based trial). Indexer code should live in its own top-level directory (e.g. indexer/ or subgraph/ — pick one and document it) so it doesn't tangle with dincli/, foundry/, or hardhat/.

Dominant language
Python
Stars
4
Forks
7
Avg merge
3d 5h
Merged PRs (30d)
34

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from InfiniteZeroFoundation/DevNet

All issues in InfiniteZeroFoundation/DevNet

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.