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:
- 128GB+ RAM minimum requirement
- 4TB+ NVMe SSD for chain data (and growing)
- Days to weeks for initial sync
- Estimated cost: $200-500/month for dedicated infrastructure
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:
- Primary: gRPC subscriptions for real-time event streaming
- Secondary: Periodic RPC queries to verify critical object states
- 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)
- Weekly monitoring of EVE Frontier GitHub repositories
- Prototype gRPC subscription client locally
- Document gaps between current schema and SUI events
- Request testnet access when available
Phase 2: Development (February)
- Build production-ready SUI indexer service
- Implement Postgres schema migrations for SUI fields
- Add checkpointing and error handling
- Integration tests against SUI testnet
Phase 3: Integration (March)
- Deploy SUI indexer alongside MUD indexer
- Implement dual-write pattern during overlap period
- Validate data consistency between chains
- Gradual traffic migration and MUD deprecation
What We're Watching
Key signals we're monitoring in the EVE Frontier repositories:
- New release tags—schema changes or new event types
- Move.toml updates—SDK version requirements
- README mentions of "testnet" or "mainnet"—timeline indicators
- New Move modules—features we need to index
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.