Skip to content

DIN Indexer

Jump to bottom
umermjd11 edited this page Oct 5, 2026 · 3 revisions

DIN Indexer

🚧 This wiki describes DevNet 2.0, soon to be launched. It follows the contracts and dincli on the develop branch; the currently running DevNet may still use older contracts and commands. Pre-launch discussion: #102.

⚡ Status: In progress, not on develop yet. A Graph Protocol subgraph (schema, event handlers, and a local Graph node via docker-compose), including the first CLI integration, lives in PR #29 and PR #72 on feat/din-indexer; it still needs re-wiring to the current contracts before it can merge. This page describes its design intent per the project roadmap (phase P4) and the indexer design doc; details may change.

What it will be

The DIN Indexer is the planned off-chain read layer for the DIN network: a service (a Graph Protocol subgraph, or a lighter equivalent) that ingests the event streams of the Platform Contracts — DinCoordinator, DinToken, DinValidatorStake, DINModelRegistry, and in DevNet 2.0 also DinFeeRouter, DinTreasury and DinEmission — and turns them into queryable entities.

The division of labour it establishes:

  • On-chain stays the canonical coordination and settlement layer: authorization, approvals, staking, slashing, state transitions, and the events that record them.
  • The indexer owns everything read-heavy: filtering, sorting, pagination, historical views, and cross-contract joins — model request queues, validator slash histories, fee-change timelines, activity feeds.

Why it exists

Today the DIN CLI reads all on-chain state live over RPC, and in several places it enumerates items by looping over on-chain counters with one contract call per item (for example, listing pending model registration requests). That works on a small devnet but scales poorly: query cost grows linearly with network history, and every richer view (dashboards, histories, per-owner filters) would otherwise push storage-heavy enumeration structures into the contracts themselves — paying permanent gas and audit complexity for what is fundamentally a read-layer concern.

An indexer solves this the way mature protocols do:

  • contracts stay minimal and events-first;
  • the CLI (and later the DIN Daemon) query indexed entities instead of looping over RPC;
  • dashboards, analytics, and governance views become possible without any contract changes.

The indexer also feeds the daemon: dind's planned on-chain event listening (reacting to GI state changes, registration windows, slash events) builds on the same event schema the indexer defines.

How it fits

  Platform Contracts (on-chain, canonical state)
        │  events
        ▼
  DIN Indexer  (planned — subgraph / event-poller + query API)
        │  queries
        ├──────────────┬─────────────────┐
        ▼              ▼                 ▼
    DIN CLI        DIN Daemon       dashboards &
  (list/filter    (event-driven      analytics
    views)         job triggers)     (future)

First integration target: replacing the CLI's pending-request enumeration loop with a single indexer query. Indexing of the per-model Task Contracts (which are deployed dynamically by model owners) requires a materially harder pattern and is deferred to a later phase.

Status & sequencing

Per the roadmap, the indexer is a P4 work-package series — design (approach choice and entity schema), implementation (event mappings and the first CLI integration), then test-suite integration — targeted for Oct–Nov 2026. The events it needs, including the task-level events, now exist on develop; the remaining gap is re-wiring the existing subgraph work to the current ABIs and merging it. Publishing to a hosted Graph endpoint is tracked separately (issue #174); for the devnet, hosting is user-side.

Further reading

Introduction

DIN Components

Network Roles

Clone this wiki locally