The Tari network has three primary clients, namely Validator Nodes, Wallets, and Indexers, excluding the Minotari network clients. Validator nodes execute transactions and reach an agreement using a variant of the Cerberus consensus, while wallets serve as an interface for clients. However, what is the role of Indexers?

To enable the Tari network to process thousands of transactions per second, the network has been sharded. This means that no validator node stores the entire network’s data and would probably be unable to do so, even if it wanted to. Moreover, specific assets and contracts are spread across different shards to avoid overloading some shards while leaving others idle. However, this also means that if you’re only interested in a single asset, your wallet would need to request the data for that asset from every shard. To address this issue, Tari has developed an Indexer that can be run locally to scan the shards and download all data related to assets you’re interested in.

Indexers function similarly to base nodes for the Minotari layer, providing a unified view of an asset as though it were a dedicated blockchain.

You can think of the distinction between validator nodes and indexers as cutting vertically and horizontally through the contract-shard space. This is illustrated in the image below. Validator nodes – during a single epoch – are only concerned about what happens in a small fraction of the shard space, but are prepared to validate any instruction for any contract that touches the shard space the node is responsible for. Indexers, on the other hand, are typically only interested in following what happens to a single contract, and will follow that contract across the entire shard space.

For this reason, indexers and nodes have orthogonal responsibilities. This configuration may feel somewhat strange if you’re used to global state machines, like Ethereum or Solana. The polarisation of indexers and nodes is a natural result of the highly sharded and linear scalability of the Cerberus consensus algorithm.

It also means that tools like [etherscan.io] become very difficult to implement in Tari – as it should be: global surveillance of a chain that aims to scale to thousands of transactions per second should be very difficult – the default-private nature of Tari notwithstanding!

Which software would you run? Typically, if you’re interested in helping scale the Tari network (and earn a return for doing so), you would run a validator node.

If you’re interested in building a distributed client application, you would implement an indexer that follows your contract.

As an example, suppose you run a real-world coffee shop and want to create a loyalty points system. In that case, you can use the fungible loyalty points contract template and publish it on the network. Your customers can interact with and store their loyalty points in Tari DAN wallets. Finally, to validate or display transactions for whatever reason, you can set up a Tari Indexer node to monitor the resource and component address of your contract.

The development of the Indexer is still ongoing, with the Tari development community working on adding GraphQL and event scanning capabilities. If you’d like to try it out, you can find it here: https://github.com/tari-project/tari-dan/tree/development/applications/tari_indexer.