Define the entities you need from your Move events and objects. Inodra runs the pipeline, the database, and the query API. You get clean tables over REST and GraphQL, not raw chain data to decode.
// your DEX package -> a "swaps" entityGET /v1/graphs/my-dex/query/swaps?filter[pool]=0x2ab...&sort=-timestamp&limit=50[ { pool, amountIn, amountOut,sender, timestamp, txDigest }, ... ]
The indexer node, the ETL, the database, the query layer become one graph you define. Inodra runs all of it, and you query tables instead of decoding events.
Rows land moments after checkpoints finalize, so a leaderboard, a positions view or an activity feed reads current data without a batch job in between.
Swaps, positions, proposals, items, whatever your Move package emits becomes an entity with filters, sorting and cursor pagination over it.
Each graph indexes from history and then follows the tip. The tables hold the full backfill and the latest checkpoint at the same time.
Every graph runs as its own pipeline with its own database. Your load and your schema do not sit next to anyone else's.
Graphs runs on the same indexing engine that powers Inodra's own production event pipeline on mainnet and testnet.
A small group of partners. Tell us what you would index and we set up a conversation.