If you’ve ever tried to develop a real product on-chain, you know the real choke point comes after the transaction: reading state fast, reading it correctly, and reacting in real time when thousands of users pile in. That truth hit us early while building on Sui Network, and it pushed us to build tooling before we built anything flashy.

‍

This post walks through two milestones that shaped how we work on the Sui network:

• an open-source events indexer we released to kill boilerplate and make Sui data actually usable for app builders;
• the collaboration with Claynosaurz, where those indexing patterns helped us manage a high-volume, refund-heavy mint that needed tight read consistency.

Together, they point toward something bigger we’re now exploring: a flexible Sui data and indexing service with simple APIs for builders. Not ready to drop specs yet: but the direction is clear.

‍

‍

‍

Part 1: sui-events-indexer. Because reading Sui Events shouldn’t hurt

When we first started poking at Move packages on Sui Blockchain, we kept running into the same issue: every project that emitted events needed its own pile of glue code. Manually parse bytecode or source, map event structs, set up a database, write polling logic against RPC, keep cursors, recover from crashes, expose read endpoints so frontends and dashboards could breathe. None of that makes your product unique, yet every team was rebuilding it.

‍

So we built sui-events-indexer, and open-sourced it.

‍

At a high level it does four things:

1. Understands your Move package. Point it at a package ID; it inspects modules and hunts for event::emit calls.
2. Generates TypeScript types. It walks every event struct, recursively across imported modules so nested types aren’t lost. Large numeric Move types land as strings where needed; Sui object IDs come across as strings; options and vectors map cleanly into TS unions and arrays.
3. Builds storage. A Prisma schema and Postgres tables are generated for each event type so you can store and query clean data immediately (and trim what you don’t need later).
4. Ships an API. You get an Express.js server with indexing jobs, handlers per module, and REST endpoints to fetch events. Polling interval, network selection, and output path are all configurable.

‍

‍

‍

Why we Bothered

Developers shouldn’t spend their first week on Sui writing event scraping scripts. You want to focus on product logic (marketplaces, DeFi pools, games, wallets) not plumbing. sui-events-indexer turns event data into something you can join, chart, alert on, or feed into off-chain processes immediately. That’s the foundation we needed before stepping into larger Sui builds.

Run that and you’ll find a ready-to-run project folder: generated types, Prisma schema, Docker bits for Postgres, indexer loop with resume-from-cursor, and a tiny Express API exposing JSON routes like /events/<module>/<event>.

Because the generator keys off the package ID, if your contract upgrades and emits new events, you regenerate and redeploy with almost no manual diffing.

• GitHub repo: buidly/sui-events-indexer
• NPM: sui-events-indexer

‍

‍

Part 2: Claynosaurz. Indexing patterns under load

With Claynosaurz mint, the brief wasn’t “deploy a basic mint.” They wanted a Sui-based experience with tickets, conditional pack logic, and refund mechanics that had to stay honest in real time. No copy-paste template would do it.

Because we already had the event indexer patterns in muscle memory, we didn’t start from zero. We extended the generator output with Popkins-specific handlers: mint events, refund triggers, distribution receipts, and post-mint state tracking. A checkpointed polling loop made sure we never lost our place, even when load spiked. Indexed data flowed into a custom API that the frontend and ops tooling hit constantly during the drop.

The result: tens of thousands of tickets minted across thousands of wallets, live refunds processed quickly, and user state that stayed in sync throughout the rush. The heavy lifting wasn’t in writing the Move once, it was in reading the chain fast enough to make the experience feel trustworthy.

What we took away from Popkins mint

• Plan your read paths before launch day. UIs, treasuries, and eligibility logic all depend on indexed data.
• Checkpoint everything. If your indexer dies mid-drop, you cannot afford gaps.
• Make event types product-friendly early; rigid raw structs slow teams down later.

Those lessons folded back into how we keep evolving the open-source indexer.

‍

Looking Forward (Soft Tease)

The obvious next step is packaging that power behind simpler, higher-level APIs so builders don’t even have to run their own indexing infra unless they want to.

We’re exploring what that could look like: hosted or self-hosted, query models that surface objects and relationships (not just raw events), and lightweight SDKs you can drop into a Sui dApp stack. Nothing to announce yet. If you’re building on Sui Network and struggling with reads, ping us, we’re talking with teams while we shape the roadmap.

‍

‍

Buidly is a builder-first engineering team with deep reps in Sui development. We design smart contracts, indexing pipelines, backend orchestration layers, and production infra for teams that need their Sui apps to hold up under real traffic. Our open-source sui-events-indexer jump-starts event tracking; our work with Claynosaurz showed how far the model can scale.

‍

‍

‍