← Back to Blog

Planning for SUI: Preparing the Indexer for EVE Frontier's Blockchain Migration

What happens when the entire blockchain your application depends on is about to change? EVE Frontier is migrating from Ethereum L2 (OP Sepolia with the MUD framework) to SUI—a fundamentally different Layer 1 blockchain with its own programming language (Move), consensus mechanism, and data access patterns. This is the story of how we're preparing EF-Map's indexer infrastructure for a seamless transition, expected in early 2025.

The Starting Point: What We Have Today

EF-Map's current data pipeline is remarkably cost-effective. The architecture we built for blockchain indexing and live event streaming already solved the hard problem: distributing ~1GB of constantly-updating game state to 500+ concurrent users for approximately $5/month (Cloudflare's paid Workers plan).

But live event streaming is only part of the story. The current infrastructure serves data in multiple ways:

Current Data Distribution Architecture

  • VPS Indexer + PostgreSQL: MUD indexer runs 24/7, populating a Postgres database with all blockchain state
  • Cloudflared Tunnels: Expose multiple API endpoints (assembly-api, ssu-api, killboard) from the VPS without public IP management
  • Direct Database APIs: Frontend makes lookups directly against Postgres for searches, filtering, and detail views
  • Cloudflare KV Workers: Snapshot storage for killboard events and smart assembly data—fast edge reads without hitting the database
  • Durable Objects WebSocket: Real-time event broadcasting to all connected clients via a single persistent hub
  • Client IndexedDB: Local storage of ~72 hours of event history for offline access and fast filtering

The full stack looks like this:

MUD Indexer → PostgreSQL → Multiple outputs:
                          ├─ Cloudflared APIs → Frontend lookups
                          ├─ KV Workers → Snapshot reads
                          └─ Event Emitter → Durable Objects → WebSocket → IndexedDB

The beautiful thing about this architecture? Only the first step needs to change. Everything downstream of PostgreSQL—the Docker event emitter, Cloudflare tunnels, KV snapshot workers, Durable Objects broadcasting, and client-side IndexedDB storage—are completely chain-agnostic. They just need a different source of events flowing into Postgres.

Discovering SUI: Research Through GitHub

Rather than waiting for official documentation, we went straight to the source: EVE Frontier's GitHub organization. What we found was illuminating:

Active Development on Move Contracts

The world-contracts repository contains SUI Move smart contracts at version 0.0.4, actively updated as recently as December 2025. The README is refreshingly honest:

"These contracts are intended for future use within EVE Frontier on SUI L1 and are not currently active in the game."

This tells us two things: (1) CCP is serious about SUI—they're not just experimenting, they're building production contracts, and (2) we have time to prepare—the current Ethereum contracts at projectawakening/world-chain-contracts remain the production system.

zkLogin Authentication

The evevault repository reveals the authentication strategy: a Chrome extension wallet using zkLogin via Enoki and FusionAuth OAuth. This means user authentication will shift from wallet signatures to OAuth-based identity—something to note for any wallet-related features in EF-Map.

Event Types: Cleaner Than MUD

One of the most encouraging findings was the event schema. MUD uses generic Store_* events that require complex ABI decoding. SUI's Move contracts emit purpose-built, strongly-typed events that are much easier to work with:

SUI Event Purpose Current MUD Equivalent
StatusChangedEvent Assembly online/offline/anchored SmartGate table updates
StorageUnitCreatedEvent New storage unit deployed SmartStorageUnit table
ItemMintedEvent Game → Chain item bridge Inventory updates
CharacterCreatedEvent New character registered Character tracking
MetadataChangedEvent Gate/storage renamed Assembly metadata

Each event includes exactly the fields we need—no parsing hex-encoded key tuples or decoding table IDs. This is a significant developer experience improvement.

The Great Debate: Full Indexer vs. Lightweight Subscriber

The core architectural decision we faced: how do we get SUI data into our pipeline? Two main options emerged:

Option A: Full sui-indexer (The Heavy Approach)

SUI provides an official indexer framework that maintains a complete local replica of chain state. The appeal is obvious: full data sovereignty, historical queries, object state access.

The reality is less appealing:

For indexing the entire SUI blockchain, this makes sense. For indexing just EVE Frontier events from a single package? Massive overkill.

Option B: gRPC Subscriptions (The Lightweight Approach)

SUI's gRPC API provides SubscriptionService—real-time streaming of events filtered by package ID. A lightweight TypeScript service subscribes to only the events we care about and writes them to Postgres.

Resource Comparison

Full Indexer: 128GB RAM, 4TB NVMe, $200-500/month
gRPC Subscriber: 512MB RAM, minimal storage, ~$5/month (existing VPS)

The subscriber approach mirrors what we already do with MUD—event-driven processing without trying to replicate the entire chain. Implementation would be roughly 500-1000 lines of TypeScript.

Option C: Hybrid (Our Recommendation)

The best approach combines both patterns:

  1. Primary: gRPC subscriptions for real-time event streaming
  2. Secondary: Periodic RPC queries to verify critical object states
  3. Fallback: Historical queries via public APIs if needed

This gives us real-time data, verification capability, and minimal infrastructure overhead. The subscriber runs alongside our existing Docker services on the VPS.

Timeline and Action Plan

With the migration expected around March 2025, we've structured a three-phase plan:

Phase 1: Foundation (January)

Phase 2: Development (February)

Phase 3: Integration (March)

What We're Watching

Key signals we're monitoring in the EVE Frontier repositories:

LLM-Assisted Monitoring

We've created a documented protocol for weekly repository checks. An LLM can compare current contracts against our event mapping, flag breaking changes, and recommend updates to our migration plan. The full protocol is captured in our internal planning document.

Key Takeaways

Architecture pays dividends. Because we designed the pipeline to be chain-agnostic from the start, a blockchain migration that could have been catastrophic becomes a contained problem—swap one component, everything else stays.

Research beats guessing. Rather than speculating about SUI, we went to the source code. The Move contracts revealed exactly what events we'll need to index, the evevault repo showed authentication changes, and the repository activity gave us confidence in the timeline.

Right-size your infrastructure. A full blockchain indexer is impressive but unnecessary. The lightweight gRPC approach does exactly what we need at 1/50th the cost.

As EVE Frontier evolves, so does EF-Map. The SUI migration is a significant undertaking, but with proper preparation, it's just another feature—not a crisis.

SUI blockchain blockchain migration Move contracts gRPC indexer architecture EVE Frontier Durable Objects event streaming