Skip to content

DIN Indexer

umeradl edited this page Jul 8, 2026 · 1 revision

DIN Indexer

📋 Status: Planned — the DIN Indexer does not exist yet. This page describes its design intent per the project roadmap (phase P4) and the indexer design doc; details may change as the design is finalized.

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 four Platform ContractsDinCoordinator, DinToken, DinValidatorStake, DINModelRegistry — 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 late 2026. It deliberately follows the contract-stability milestones: mapping implementation waits until the platform contract ABIs settle after the upgradeable-contracts migration, so mappings aren't rebuilt against a moving target.

Further reading

Clone this wiki locally