Arbitrum NFT Integration
Development Status
Phase: Contract Testing & Indexer Integration Target Network: Arbitrum Sepolia (testnet) → Arbitrum One (mainnet) Next Milestone: Complete indexer configuration for Arbitrum events
Quick Navigation
| Document | Purpose |
|---|---|
| Smart Contracts | Contract architecture, factory pattern, 0xSplits integration |
| Technical Architecture | System-wide details: indexer, generation pipeline |
| Development Plan | Phase breakdown, milestones, and success criteria |
The Story
EmProps received a grant from the Arbitrum Foundation to extend our AI-powered creative platform to the Arbitrum ecosystem. This document explains what we've built, why we made the technical decisions we did, and how we plan to bring this infrastructure to Arbitrum.
What We've Already Built
Before diving into the Arbitrum-specific work, here's an overview of the foundation we're building on.
The platform consists of three major systems:
- Workflow Execution System - A sophisticated job queue for running AI generation pipelines
- Collection Management - Tools for creating, organizing, and publishing generated assets
- NFT Launchpad - Infrastructure for deploying and minting NFT collections on-chain
The EmProps Service
The EmProps Service is the API backbone that powers everything. It orchestrates workflow execution, manages collections and assets, and coordinates between our various frontend applications. All client applications—whether the desktop studio or mobile miniapp—connect to this unified backend.
Workflow Execution System
The workflow system handles AI generation at scale through a distributed job queue.
The Job Queue is the heart of our infrastructure. When a user requests AI generation, their job enters a Redis-based queue where workers claim tasks based on their capabilities. This isn't a simple first-in-first-out queue—it's a sophisticated matching system where jobs find workers that have the right hardware, the right models cached, and the capacity to serve them quickly.
We chose Redis over traditional message brokers like RabbitMQ or Kafka because it serves multiple purposes simultaneously: job queue, state store, and pub/sub messaging. One dependency instead of three. The performance is exceptional (sub-millisecond latency for job claims), and the operational simplicity is invaluable when you're managing distributed infrastructure.
The Worker Network supports multiple execution environments:
- API Direct Workers: Handle jobs that call external AI services directly (OpenAI, Gemini, etc.). These are lightweight workers that don't require GPUs—they coordinate job flow while the actual computation happens in managed cloud services.
- ComfyUI GPU Workers: Ephemeral spot instances from vast.ai running ComfyUI with local GPU acceleration. These handle Stable Diffusion workflows that require dedicated GPU hardware for image generation. They spin up and down constantly based on demand.
- ComfyUI API Workers: Run ComfyUI workflows that use API-based nodes (Gemini, Veo, fal.ai, etc.) rather than local GPU inference. This allows complex multi-step workflows without GPU hardware—the workflow orchestration runs locally while AI inference happens via cloud APIs.
- n8n Workers (coming soon): Automation workflows using n8n for complex multi-step processes, integrations, and business logic that extends beyond pure AI generation.
All worker types connect to the same job queue and can be mixed within a single workflow. A workflow might use Gemini for text analysis, then hand off to a GPU worker for image generation, then use Veo for video animation—all orchestrated through our unified job system.
Workers use a pull-based architecture: they request jobs they can handle rather than having jobs pushed to them. This provides natural backpressure—workers only ask for work when they're ready. It also eliminates the need for a centralized scheduler that could become a bottleneck or single point of failure.
Collection Management: EmProps Studio
EmProps Studio is our desktop application where creators compose AI workflows and manage their collections. Built with Next.js 14 and TypeScript, it provides a visual workflow builder where users can chain together AI operations—text-to-image generation, upscaling, style transfer—without writing code. The interface feels like a creative tool, not a technical dashboard.
The studio includes robust asset management: organizing generated outputs into collections, curating which pieces to publish, managing metadata, and preparing assets for NFT minting.
Social Experience: Emerge Miniapp
Emerge Miniapp is our mobile-first consumer application, distributed as a Farcaster miniapp. Built with Next.js and integrated with the Farcaster social graph, it provides a frictionless experience for discovering and generating AI art. Users authenticate via their Farcaster identity, pay with any currency with Diamo Pay, and receive their generated images instantly.
The miniapp features:
- Social Discovery: Browse featured workflows, see what friends are creating, and discover trending art styles through Farcaster's social layer
- One-Tap Generation: Select a workflow, customize parameters, and generate—all within the Farcaster or Coinbase Wallet app
- Creator Economics: Revenue splits automatically via 0xSplits contracts—50% to creators, 25% to platform, 25% to the EMERGE token buyback
- Reward System: Users earn EMERGE tokens for generating, which can be claimed directly to their wallet
- Feed & Leaderboards: View recent generations from the community, top creators, and trending workflows
The miniapp connects to the same EmProps API and job queue infrastructure as our desktop studio, ensuring consistent generation quality across platforms.
NFT Launchpad
The NFT Launchpad is the on-chain component that enables creators to deploy and sell their collections. This is the system we're overhauling for the Arbitrum grant.
The Current Architecture was built on Tezos, then retrofit for Base. That system used a single contract for all collections—every NFT from every creator lived in one shared contract. This worked, but it has significant limitations:
- Collections aren't truly independent
- Harder to verify ownership on marketplaces
- Limited customization per collection
- Complex upgrade paths
The New Architecture for Arbitrum gives each collection its own contract. This provides:
- True collection independence
- Better marketplace compatibility
- Per-collection customization
- Cleaner upgrade paths
We're also updating the Emerge Miniapp to enable a simplified launch process—creators will be able to deploy collections directly from the mobile experience
What We Plan to Build for Arbitrum
The Arbitrum integration brings a new contract architecture to production. Here are the components and our goals for each:
Smart Contract Components
| Component | Goal |
|---|---|
| One contract per collection | Each creator's collection gets its own contract address—not a shared contract like our legacy system. Works properly with OpenSea, Blur, and other marketplaces. |
| Token upgrades | Let creators add value to existing collections post-launch. Token holders opt-in to receive new content. |
| Dynamic metadata | Serve content on-demand from our API. Support upgrades by returning version-aware metadata. |
| Gasless approvals | Let users approve actions (like token upgrades) without paying gas. Platform submits signatures on their behalf. |
| Automatic revenue splits | Trustless distribution via 0xSplits. Creators, platform, and Arbitrum Foundation receive their share without manual intervention. |
See Smart Contracts for implementation details.
Infrastructure Components
| Component | Goal |
|---|---|
| Blockchain Indexer (Ponder) | Keep our UI in sync with on-chain state in real-time. Provide fast queries for collection listings, ownership, and history. |
| Metadata API | Serve ERC721 metadata dynamically. Handle version-aware content for upgraded tokens. |
| Generation Pipeline | Produce collection assets across our worker network. |
User Experience Goals
| Component | Goal |
|---|---|
| Miniapp Launch Flow | One-tap collection deployment from mobile. No wallet complexity—users select images, set price, deploy. |
| Gasless Minting | Users never pay gas. Platform handles all transactions via centralized minting. |
| Flexible Payments | Accept credit cards, crypto, or any currency via Diamo. Blockchain is invisible to buyers. |
Development Approach
We plan to build incrementally:
Phase 1: Smart contract deployment and testing on Arbitrum Sepolia. Verify ERC721A minting, factory deployment, and 0xSplits integration work as expected.
Phase 2: Ponder indexer configuration for Arbitrum. Adapt our existing schemas and handlers to the new chain.
Phase 3: Frontend integration. Update EmProps Studio to support Arbitrum chain selection, wallet connection, and contract interaction.
Phase 4: Production deployment to Arbitrum One, monitoring, and creator onboarding.
What Success Looks Like
A successful Arbitrum integration means:
- Creators can deploy: Any EmProps user can launch an NFT collection on Arbitrum
- Revenue flows correctly: 0xSplits integration distributes mint revenue automatically
- Real-time data: Ponder indexer keeps UI in sync with blockchain state
- Low friction: Gas costs are reasonable; transaction confirmations are fast
- Documentation: Clear guides for creators choosing between chains
Related Documentation
Arbitrum Deep Dives
- Smart Contracts - Contract architecture, factory pattern, 0xSplits
- Technical Architecture - Indexer design, generation pipeline
- Development Plan - Phase breakdown with success criteria
Technical Reference
- Hardhat Package - Full contract source documentation
- Blockchain Indexer (Ponder) - Indexer API and schema
- React Web3 Patterns - Frontend integration patterns
Context
- Current State - Full inventory of existing NFT infrastructure
- Legacy Tezos System - Production Tezos implementation (for reference)
- Integration Evaluation - Technical feasibility analysis
Architecture Decisions
- NFT Minting Infrastructure Integration - ADR for integration approach
