The Indexooor Stack, is an open-source project for indexing and querying smart contract data for EVM based chains. Our unique database schema allows for complex join queries and fetching full arrays and mappings from smart contracts, without the need for smart contracts to emit events.
Refer our comparison with the graph to get a better idea of what we can do and why!
The stack is composed of several submodules, each serving a specific purpose:
🚀 Core: Our core indexing service, written in Go, indexes smart contract slot data using a lightweight algorithm that detects slot changes for a contract in each block. All slot data is stored in a PostgreSQL database.
🔍 Queriooor: Our querying service, written in Python using FastAPI, allows developers to upload a storage layout for their contract address and query variables by their name. The service finds the slot and data type of the variable, fetches data, and decodes it before returning it to the user.
🖥️ Goooi-queriooor: Our UI web-app, built using Vite, simplifies querying by allowing developers to query in the browser instead of calling a REST API.
🎮 Simulatooor: Our simulator service, written in Go, simulates all our services and demonstrates the workings of the Indexooor Stack.
🐘 Op-geth: Our version of the Optimism Go Ethereum, which has the Indexooor Core integrated into the node for indexing smart contract data. This makes things easier for developers, who can then run an extra querier connecting their database with it for users to query data!
Our stack is lightweight and easy to run, making it accessible for developers of all levels.
As mentioned above, the Indexooor stack is highly optimised for fetching smart contract state without them emitting events. The stack has several components and each of them has something worth mentioning.
🚀 Core: The core component of Indexooor is designed to fetch slot-level data for contracts directly through an RPC call, rather than requiring access to a node. By making a few RPC calls and accessing low-level state, the indexer service pulls data for required contracts and dumps it into a database. Users can then build their own service on top of their database with custom logic. This works for all EVM chains that have "debug" endpoints enabled.
🔍 Queriooor: With the data dump for all the slots of a contract, it can be difficult to build context and make the data queryable based on a variable name, which is why low-level indexing is not available out of the box as a service. To solve this problem, we extended the Queriooor service to support multiple data types, including elementary types, basic and nested mappings (1-level deep), and arrays for elementary types. This was a tricky part of the project, but it allows users to make group queries to the underlying database based on their query, making it easy to use out of the box.
🐘 OP Stack and Op-geth: The OP stack from optimism allows users to spin up their own rollups, which is a helpful tool for users who want to build app-specific rollups. We added the core indexing service features available to the L2 client of OP Stack (i.e., op-geth) through a bunch of flags. This means that users can now index all relevant data on their own rollup without any extra setup. We modified the op-geth implementation to work with the whole OP setup, including an L1 chain, op-node, and batcher for a devnet.