calendar_today
June 24, 2025
|
schedule
6
min read
Reading data is the real bottleneck
Backend
Infrastructure
“I thought that the difficult thing about databases and blockchains is how to write transactions consistently really fast.

It turns out that most of the time, what people actually do is read data. If you don’t make that an excellent experience for developers, then 90% of their experience is not so great.

We focused too hard on the very hard problem (writing data), and not enough on the common problem (reading data). Now we’re catching up with that.”


— George Danezis, Co-Founder and Chief Scientist, Sui Network -
https://youtu.be/0wzfRLGZDsQ?t=1522

When building Web3 apps, writing data sounds cool. But reading accurately, consistently, and under pressure is where most of the complexity hides.

The Popkins mint made that clear. With 97,000 NFTs issued across 17,000+ wallets, all driven by real-time logic from mint to pack opening. We had to build a full off-chain system that didn’t just observe the chain: it had to understand it, index it, and act on it.

Claynosaurz

When Claynosaurz shared their Popkins mint concept, we immediately saw it wasn’t going to fit any existing drop model. A system that combined gamification, live refunds, conditional outcomes, instant distribution, and zero user friction: all while running at massive scale. Technically, stacking that much complexity usually leads to problems you only see once it’s live. And often, those problems don’t come from writing transactions , they come from everything that happens after: tracking, interpreting, reacting.

Reading the chain correctly is what holds the system together.

But, this mint only worked the way it did because of Sui Network. The architecture made the refund logic viable. The speed and finality gave us the confidence to go hard. And parallel execution let us hit scale without flinching. We didn’t have to build around limitations.

  • If you build in Web3, you know how rare that is.
  • If you’re not building, you felt it in the minting process.

This level of conditional logic, instantaneous settlement, and concurrency would be nearly impossible elsewhere. The combination of parallel execution, object-centric state management, and real randomness meant we could architect this natively instead of duct-taping workarounds.

If you’re a smart contract engineer, you know how rare that stack combination is.

                                           


The Mint Flow

Each ticket minted was soulbound (non-transferable and permanently tied to a single wallet) used to trigger backend logic for assigning one of three pack types. Legendary Packs returned a fixed outcome with a Popkin and reward bundle, Escape Packs ran conditional logic to process full refunds on-chain while still distributing extras, and Rat Packs were tied to gated eligibility, surfacing only for specific collector criteria.

The flow began with users minting soulbound ticket NFTs. Each ticket entry was immediately registered on-chain, tied to wallet addresses, payment type, and eligibility flags. This guaranteed one-to-one linkage between users and outcomes.

All logic was deterministic upfront, computed at mint time, fully on-chain.


Indexer Powering the Mint

That gap George Danezis described (between writing and reading ) is exactly where our infrastructure started. The Popkins event indexer turned raw, high-volume on-chain events into actionable, real-time data streams the system could rely on.

At the heart of our infra was the Popkins event indexer. Built on top of sui-events-indexer, it gave us a foundation to track every relevant smart contract event in real time.

We extended this base to include:

• Custom TypeScript mappings for all Popkins SC events

• Checkpoint-driven polling to avoid gaps in data

• Structured storage in a relational database, optimized for frontend consumption

This allowed the system to mirror every mint, burn, claim, and refund, feeding a real-time understanding of each user’s state across the app.

Popkins API: The Execution Layer

Serving as the glue between frontend, backend logic, and blockchain, the custom-built Popkins API carried out some of the most critical tasks:

  • Generating and broadcasting mint and claim transactions
  • Interfacing with the treasury wallet to distribute assets
  • Syncing its logic with the indexer for up-to-date state awareness

One challenge was RPC stability. Under high load, even minor latency or throttling can lead to cascading failures. To counter this, we introduced:

  • Transaction retries and queuing
  • Non-blocking fallback patterns for time-sensitive actions
  • RPC health monitoring and isolation logic

The API was the system’s outer shell: invisible to the user, critical to everything.

Pack Opening

Behind the animations of opening a Popkins pack was a carefully coordinated orchestration engine.

Here’s how it worked:
  1. The user sends an on-chain transaction to burn the pack.
  2. The indexer detects the burn event.
  3. It determines the randomized contents of the pack.
  4. A “distribution receipt” is queued for fulfillment.
  5. The backend processes this queue FIFO-style, sending NFTs from the treasury wallet to the user.

To maintain reliability, we implemented:
  • A persistent, observable queue tied to block heights
  • Visibility tooling for receipt backlogs and execution metrics
  • Real-time logging to trace failures and retries

In short: behind every pack open was a tightly timed, fully automated system that understood and executed the right next move.

Indexing the Collection & Tracking 25,000 NFTs

Once all NFTs were minted, the question became: how do you track distribution, ownership, and marketplace activity?

Sui's object model is powerful but layered. Every NFT is its own object, and objects come in a wide variety of types and structures. There’s no built-in, high-level abstraction for “collection state” out of the box.

To solve this, we introduced a second indexer, based on sui-indexer-alt.

This allowed us to:
  • Track all Popkins objects in circulation
  • Monitor Kiosk-based activity (transfers, listings)
  • Parse and store marketplace events across supported platforms
  • Normalize ownership data into a usable format for other Clayno systems

Without this secondary layer, tracking something as “simple” as who owns what would’ve required expensive on-demand queries or manual reconciliation. The indexer turned it into a clean, queryable dataset.

Lessons from the Trenches

As George Danezis said: “Now we’re catching up with that.”

There’s tangible progress. Tools like sui-events-indexer and sui-indexer-alt are game changers, the building blocks for real infra.

What we learned:

  • RPC reliability is critical. Rate limits and instability caused the biggest user-facing issues. Having multiple providers (or self-managed infra) should be standard for any production-grade app.
  • Reusable tooling has room to grow. Event indexing and transaction orchestration still require a lot of bespoke wiring. There’s clear room for standardized dev kits that reduce boilerplate and surface common patterns.
  • Object-centric state demands new mental models. You don’t “query” for state, you traverse it. Developer experience tools should reflect that shift.

The pressure test

The system went live, processing real money across thousands of users, with full concurrency and no margin for error.

  • 97,347 tickets minted, and 17,760 unique wallets participating
  • $17.6M USDC collected, and $13.9M USDC refunded live within 60 minutes
  • 69,000+ refund transactions executed atomically
  • ~770 $SUI spent across entire contract run

Contract engine architecture

The on-chain logic powering Popkins was designed by Mysten Labs, leveraging Sui’s object model to handle complex state transitions at scale. Every minted ticket was registered into shared registries, tying ownership, payment, and eligibility directly to wallet addresses. Refund pools were structured as isolated shared objects holding USDC deposits, allowing fully atomic refund executions across thousands of transactions without cross-user contention.

Randomness was sourced directly on-chain using Sui’s native module, eliminating external oracles and keeping winner selection fully transparent. Programmable Transaction Blocks batched high-volume operations (mints, refunds, burns) into single atomic transactions, keeping gas costs low even under heavy load. Move’s ownership model enforced access controls across all financial flows, with admin-only authority over sensitive operations like fund withdrawals or draw phase transitions.

Sui’s architecture allowed the system to remain fully composable, scalable, and transparent throughout the entire mint.

For the full deep dive on Mysten Labs’ contract system, read the full technical breakdown: https://blog.sui.io/claynosaurz-popkins-nft-technical-launch/

Final Thoughts

This was a milestone in how complex Web3 systems get built, monitored, and scaled on Sui Network. We didn’t just write data. We watched it, read it, and reacted to it in real time.

> For Claynosaurz, this was more than a mint. It was the foundation of their entire on-chain architecture, the first major live test of a system that will underpin future gameplay mechanics, asset flows, and cross-media integrations. The next phases (free-to-play games with Gameloft, animated IP, physical toy integrations) will all build on top of this same core registry-based contract system.

> For Buidly, this was a chance to prove that Web3 infra doesn’t have to break under real load. We architected something that worked transparently, deterministically, and under pressure.

> For Sui, it’s exactly the kind of on-chain system the architecture was built to support.

This foundation marked the start of something bigger. The success of Popkins cemented the partnership between Claynosaurz and Buidly, as development partners shaping their future on Sui Network. From here, we’re working side by side to expand the technical stack that will power the next phase of their ecosystem.

In production, reads are the product. That’s the part everyone feels, and the part that needs to hold under pressure.

Placeholder

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.