NFT Marketplace Aggregator Development

NFT Marketplace Aggregator Development

The problem an aggregator solves is simple: the same NFT can be listed on OpenSea, Blur, LooksRare, and X2Y2 simultaneously at different prices. A buyer looking for the best price is forced to open 4 tabs. An aggregator, like 1inch for tokens, collects orders from all platforms, shows a unified listing, and executes the trade through the optimal route. Gem.xyz and Reservoir did this and became industry standards — but opportunities for specialized aggregators remain.

Smart Contract Architecture

Multi-marketplace Trade Execution

The key component — an aggregator contract that buys NFTs from multiple platforms in one transaction:

contract NFTAggregator {
    struct TradeData {
        address marketplace;
        bytes tradeData;      // calldata for specific marketplace
        uint256 value;        // ETH for this part of trade
        bool isERC721;
    }

    function batchBuy(TradeData[] calldata trades) external payable {
        for (uint256 i = 0; i < trades.length; i++) {
            (bool success, ) = trades[i].marketplace.call{value: trades[i].value}(
                trades[i].tradeData
            );
            if (!success) {
                // Partial fill or revert depending on policy
                emit TradeFailed(i, trades[i].marketplace);
            }
        }
        // Return unspent ETH
        if (address(this).balance > 0) {
            payable(msg.sender).transfer(address(this).balance);
        }
    }
}

Critical moment: atomicity. If first 3 NFTs bought and 4th already sold — what do you do? Two modes: failOnRevert (revert everything if anything fails) and skipFailed (buy what you can, return money for rest). Gem used the second approach as UX optimization — user still gets part of what was requested.

Order Format Support

Each marketplace — its own standard:

Need separate adapter for each. Seaport — most complex: supports criteria-based orders (buy any token from collection with certain traits), advanced orders with partial fill, multiple recipients for royalties.

Sweeping and Trait-Based Purchases

Sweep (mass purchase from bottom of price range) — main function for collectors and traders. Trait-sweep: buy all "legendary" from available, regardless of marketplace. Requires criteria-based matching in Seaport or off-chain filtering with on-chain execution.

Indexing and Data Layer

An aggregator without current data — useless. 90% of complexity — in infrastructure for collecting and updating orders.

Data Sources

Marketplace API: OpenSea API v2, Blur API (partially closed), Reservoir protocol as meta-aggregator with open API. Reservoir indexes most marketplaces and provides unified API — makes sense to use it as foundation, adding own indexing for specific cases.

On-chain events: listen to OrderFulfilled, OrderCancelled events on Seaport and equivalents on other marketplaces. WebSocket subscription via Alchemy/Infura for real-time updates. 1-2 block delay — acceptable for most use cases.

Own indexer: for production — own indexer based on The Graph subgraph or custom solution on Go/TypeScript. Store orders in PostgreSQL with indexes on (contract, tokenId, price). Redis for hot data (floor price, recent sales).

Staleness Problem

Orders become stale. Best listing on OpenSea might already be executed while user clicks "Buy". Solutions:

• Check on-chain order status before display (expensive in RPC calls)
• Optimistic UI with fallback to next best order on fail
• Cache with 30 second TTL + real-time invalidation via events

Blur additionally complicates: bid pool lets you see "available" bids which might be filled by competitors faster than your transaction arrives.

Frontend Architecture

Search and Filtering

Full-text search by collection name + filters: trait-based, price range, marketplace source, verification status (verified/unverified collection). Elasticsearch or Meilisearch for fast search across millions of tokens.

Virtualized list (react-virtual or tanstack-virtual) — 10k token collections don't render in DOM entirely.

Cart

Aggregator without cart — just a search engine. Cart: add several NFTs from different marketplaces, show total cost + gas estimate, execute in one transaction. Technically — forming TradeData[] array on frontend with subsequent batchBuy() call.

Gas estimation for batch transactions non-trivial: each marketplace consumes different amounts of gas, plus aggregator overhead. Use eth_estimateGas with small buffer (10-20%) or precomputed gas lookup table by marketplace types.

Royalty Compliance

After Blur introduced optional royalties and captured market share, topic became political. Aggregator must explicitly show which royalties will be paid on each purchase and give user choice — or apply project policy automatically (relying on onchain royalty registry EIP-2981 + Manifold Registry).

Monetization and Competitive Positioning

Standard models: 0.5-1% fee on transaction volume, pro-subscription for analytics, API access for other projects. Blur destroyed the listing fees market — need to compete on UX, speed, analytics, specialization (niche chains, specific categories like gaming NFTs, phygital).

Multi-chain mandatory: Ethereum, Polygon, Base, Arbitrum, Blast. Each chain needs separate indexer, but aggregator contract and frontend — unified.

Timeline Estimates

MVP (Ethereum + OpenSea + Blur, basic cart): 2-3 weeks. Full product (multi-chain, 5+ marketplaces, analytics, trait-based search): 2-3 months.