Indexer

The MUD Indexer is an offchain indexer for onchain applications built with MUD.

Why an offchain indexer?

Reads with onchain apps can be tricky. What does it mean to be able to query the Ethereum network? Technically, given a node with a fully synced state, we can explore just about everything using the EVM, but the “exploring” would be looking at raw storage slots for accounts corresponding to smart contracts. A way around this exists by providing view functions on smart contracts: these effectively are just wrappers around raw storage and expose a more friendly API. Instead of having to figure out where the balances for an account are stored in the storage tree, we now can call a function that does the lookup via Solidity via an RPC endpoint.

The issue with view functions is that for any sophisticated application the calls needed to get the “full picture” of the state from the chain are very complex. Servicing so many view function calls also creates the need to run a set of dedicated nodes instead of relying on a third-party provider's free tier.

The MUD indexer solves this problem by listening to the MUD store events to automatically replicate the entire onchain state in a relational database. Having such a database allows clients to quickly and efficiently query the onchain data.

See here how to integrate the indexer with your MUD application.

Which indexer to use?

If you use our blockchains, either production (Redstone) (opens in a new tab) or testing (Garnet) (opens in a new tab), we provide an indexer you can use.

• Redstone: https://indexer.mud.redstonechain.com/
• Garnet: https://indexer.mud.garnetchain.com/

Note that those indexers are still experimental, and there might be downtime. If you need production-level reliability, contact us on Discord (opens in a new tab).

If you use a different blockchain, you need to host your own indexer. There are several options:

• SQLite, which is intended for relatively small amounts of information. This indexer always contains both the events and the latest available snapshot of the data.

• Postgres for events, which only stores the events. This lets the indexer use less CPU and less storage on the database.

• Postgre for data and events, which stores the events and decodes what they mean to have the latest available snapshot of the data.