Trust Indexer

Trust Indexer is the read-side bridge between governance events and OAN service behavior. Governance events are durable and auditable, but service nodes should not each implement their own chain event scanner. Trust Indexer reads governance events, normalizes them, stores an audit trail, and exposes current node status in a form Root and related services can consume.

The most important boundary is this: Trust Indexer is not a signing authority. It does not issue Root authorization credentials. It does not decide resource publication. It projects governance state so services can enforce current authority.

That boundary makes the system easier to reason about. Governance events are the durable record. Trust Indexer makes them queryable. Root turns valid current state into protocol enforcement. If the indexer is wrong or stale, Root should detect the risk rather than silently treating the stale read model as truth.

Governance boundary

Why an Indexer Exists

Chain or bulletin events are the durable source for infrastructure lifecycle decisions, but raw event APIs are inconvenient for every service request path. Root should not need to parse chain pagination, checkpoint details, event encodings, retry behavior, and provider quirks inside every authorization check.

Trust Indexer turns that raw stream into OAN-facing state:

governance events
  -> Trust Indexer
  -> durable local projection
  -> current Registrar / Discovery / issuer status
  -> Root authorization cache and service checks

This is a common pattern in distributed systems: use a durable event source, then build a queryable read model for operational services.

It is especially important when the event source is a blockchain or bulletin-like layer. Raw event scans can involve package versions, pagination, checkpoint ranges, provider limits, and replay behavior. Those concerns belong in a dedicated indexer and shared runtime, not duplicated inside every service handler.

What It Tracks

Trust Indexer can track:

  • initialization events;
  • governance execution events;
  • subject DID;
  • subject type, such as Registrar or Discovery;
  • current status, such as active, suspended, or revoked;
  • authorized domains;
  • effective and expiry times;
  • policy and metadata hashes;
  • event sequence and digest continuity;
  • sync cursor and lag;
  • raw event envelopes for audit and replay.

This lets operators and services answer concrete questions: which Registrars are active, which Discovery nodes are active, which domains they cover, whether the indexer is caught up, and whether event continuity looks healthy.

The continuity fields are not decoration. If the governance contract is upgraded, event packages change, or an indexer starts scanning from the wrong point, a gap may appear. The indexer should make that visible so operators can rebuild or repair the projection before Root relies on it for sensitive decisions.

What It Does Not Do

Trust Indexer does not create governance proposals, cast votes, hold private keys, submit governance transactions by default, issue Root authorization credentials, resolve DID Documents, store ordinary resource records, perform semantic Discovery, or decide ranking.

This boundary protects the trust model. The indexer reports current governance facts. Root still verifies submissions and produces Root proof. Discovery still indexes resource packages. Clients still verify before use.

Keeping write-path governance tooling separate is also safer. Proposal creation, voting, contract deployment, and private operator keys should live in official operations tooling, not inside the community-facing indexer behavior.

Effective Authorization

For infrastructure service interactions, effective authorization should combine two things:

  1. valid Root-issued authorization material for the infrastructure subject;
  2. current governance state projected by Trust Indexer.

Either side missing should be treated carefully. A Root credential is not enough if the latest governance state says the node is revoked. A governance-active event is not enough if the subject lacks valid Root-issued authorization material. The two layers answer different questions.

This double condition prevents two opposite mistakes. It prevents old credentials from surviving revocation, and it prevents raw governance events from being treated as protocol credentials before Root has issued or refreshed authorization material.

Freshness and Gaps

Indexer freshness matters. If the indexer is stale, has sequence gaps, or detects digest discontinuity, services may be enforcing an incomplete trust view. A conservative deployment should fail closed for trust-sensitive operations when the governance projection is too stale or unhealthy.

This is why indexer status endpoints and rebuild procedures matter operationally. They are not public marketing features; they are the maintenance tools that keep governance state reliable.

A rebuild should be deterministic from the authoritative event source. Operators should know the chain network, contract or package identifiers, start checkpoint or event cursor, expected latest cursor, and whether all required event types were discovered. Rebuild documentation should be good enough that the same state can be reconstructed after server migration or database loss.

Public Understanding

Ordinary community users do not need to run a Trust Indexer to register a resource through official services. Root uses it behind the scenes. Third-party operators may run their own indexer or consume a trusted indexer depending on deployment. What users should understand is that current node authority is not just a static config file.

For third-party infrastructure, the choice of indexer model should be explicit. A serious operator should explain whether it follows the official governance event source directly, consumes a hosted read model, or runs a private governance domain. Clients and reviewers can then understand what “current authorization” means for that deployment.

Further Reading