Blockchain Indexing Layer
Blockchains are excellent ledgers and terrible databases: asking 'show me this user's last twenty positions, newest first' means replaying history yourself. An indexing layer solves that by subscribing to contract events, materialising them into structured entities, and exposing a query API. Three separate subgraphs cover the prediction protocol, the reward centre and the core protocol — kept separate so a schema change in one does not force the others to re-index.
Three subgraph packages: prediction protocol, reward centre, and core protocol
Documented as an architecture record. A hosted query endpoint is an operational concern rather than a portfolio artefact.
From an emitted event to a query result
Follow one contract event into the index and back out as a query. Note that nothing is ever written to the index by hand.
Emit events as state changes. The only source of truth.
How chain history becomes queryable.
Highlights
Events in, queryable entities out
Each subgraph declares which contracts and events it watches, maps those events onto entities, and serves them over a query API. The important property is that everything is reproducible from chain history — the index can always be rebuilt.
Manifest and schema
Declares the contracts, events and entity shapes for a subgraph.
- Entity schema defines what applications will be able to ask for.
- Each subgraph has its own manifest and its own deployment lifecycle.
Event mappings
Handlers translating raw contract events into entity writes.
- Deterministic: the same chain history always produces the same index.
- Derived fields let related entities be traversed in one query.
Query API
Serves indexed entities with filtering, ordering and pagination.
- Replaces per-read history replay in application backends.
- The read path for anything the chain cannot answer efficiently.
The three subgraphs
Kept separate so a schema change in one protocol area does not force the others to re-index from genesis. 13 units across 4 groups.
Subgraphs
3Definition
3Processing
3Serving
4Stack by layer
Delivered work
Indexing
- Three independently deployable subgraphs across prediction, rewards and core protocol.
- Entity schemas defining the application query surface.
- Deterministic event handlers, so any index is rebuildable from chain history.
- Derived relationships letting one query replace several chain calls.
Modules and demo strategy
Separation into three subgraphs
Limits the cost of a schema change.
- A re-index affects one protocol area, not everything.
Deterministic mappings
Keeps the index a projection, never a source of truth.
- Same chain history always yields the same entities.
- Means the index can be discarded and rebuilt safely.