We develop NFT marketplace aggregators that solve the liquidity fragmentation problem. Why open four tabs when you can buy an NFT at the best price in one click? Our aggregators unite OpenSea, Blur, LooksRare, X2Y2, and other platforms, collecting all orders into a single listing and executing the trade via the optimal route. Projects like Gem.xyz and Reservoir have become industry standards, but for specialized niches (gaming, phygital, traits), huge potential remains.
Assess your project for free — contact us.
How does an NFT aggregator work?
An aggregator is a combination of smart contracts and backend infrastructure. Smart contracts enable atomic purchase of multiple NFTs in one transaction, while the backend indexes orders from all platforms and provides an API for the frontend. The frontend displays a unified list, allows filtering by traits, price, and source, and enables a cart for bulk purchases.
Architecture at the smart contract level
Executing multi-marketplace trades
The key component is the aggregator contract, which in one transaction buys NFTs from several platforms:
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); } } } Why is atomicity of transactions important?
If the first 3 NFTs are bought, but the 4th is already sold — what to do? Two modes: failOnRevert (revert everything if any trade fails) and skipFailed (buy what you can, return funds for the rest). Gem used the second approach as a UX optimization — the user still gets part of what they requested. Atomicity is critical for sweeps, where a transaction can include dozens of orders.
Order format support
Each marketplace has its own standard:
| Marketplace | Standard | Peculiarities |
|---|---|---|
| OpenSea (Seaport) | Seaport 1.5 | EIP-712, zone/conduit architecture |
| Blur | Blur Exchange | Custom, bid pool |
| LooksRare | LooksRare v2 | ERC-2981 royalties mandatory |
| X2Y2 | X2Y2 v1 | Need backend to get callable calldata |
| Rarible | ExchangeV2 | ERC-1155 + bundles support |
| Foundation | Foundation Market | Only primary, custom format |
For each, a separate adapter is needed. Seaport is the most complex: supports criteria-based orders (can buy any token from a collection with certain traits), advanced orders with partial fill, multiple recipients for royalties. Seaport protocol specification
Sweeping and trait-based purchases
Sweep (mass buying from the bottom of the price range) is the main function for collectors and traders. Trait-sweep: buy all "legendary" 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 up-to-date data is useless. 90% of the complexity lies in the infrastructure for collecting and updating orders.
Data sources
- Marketplace APIs: OpenSea API v2, Blur API (partially closed), Reservoir protocol as a meta-aggregator with open API. Reservoir indexes most marketplaces and provides a unified API — it's reasonable to use it as a foundation, adding custom indexing for specific cases.
-
On-chain events: listen to
OrderFulfilled,OrderCancelledevents from Seaport and similar on other marketplaces. WebSocket subscription via Alchemy/Infura for real-time updates. A delay of 1-2 blocks is acceptable for most use cases. -
Custom indexer: for production — a custom indexer based on The Graph subgraph or a custom solution in Go/TypeScript. Store orders in PostgreSQL with indexes on
(contract, tokenId, price). Redis for hot data (floor price, recent sales).
The staleness problem
Orders become stale. The best listing on OpenSea may already be executed by the time the user clicks "Buy". Solutions:
- On-chain status check before display (expensive in RPC calls)
- Optimistic UI with fallback to the next best order on failure
- Cache with TTL 30 seconds + real-time invalidation via events
Blur adds extra complexity: the bid pool shows "available" bids that may 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 over millions of tokens. Virtualized list (react-virtual or tanstack-virtual) — collections with 10k tokens are not rendered in the DOM completely.
Cart
An aggregator without a cart is just a search engine. Cart: add several NFTs from different marketplaces, show total cost + gas estimate, execute in one transaction. Technically, forming a TradeData[] array on the frontend with a subsequent call to batchBuy(). Gas estimation for batch transactions is non-trivial: each marketplace consumes different gas, plus aggregator overhead. Use eth_estimateGas with a small buffer (10-20%) or a precomputed gas lookup table by marketplace type.
Royalty compliance
After Blur introduced optional royalties and captured market share, the topic became political. The aggregator must clearly show which royalties will be paid for each purchase and let the user choose — either apply project policy automatically (based on on-chain royalty registry EIP-2981 + Manifold Registry).
Monetization and competitive positioning
Standard models: 0.5-1% fee on volume, pro subscription for analytics, API access for other projects. Blur disrupted listing fees — compete on UX, speed, analytics, specialization (niche chains, specific categories like gaming NFTs, phygital). Multichain is a must: Ethereum, Polygon, Base, Arbitrum, Blast. Each chain needs a separate indexer, but the aggregator contract and frontend are unified.
Stages of NFT aggregator development
- Requirements analysis: define target audience, functionality (sweep, traits, cross-chain), list of marketplaces.
- Smart contract design: develop batchBuy architecture, adapters for each marketplace, test on fork networks.
- Indexing layer development: set up indexers, integrate with APIs and on-chain listeners, caching.
- Frontend: UI/UX design, implement search, cart, wallet integration (MetaMask, WalletConnect).
- Testing: unit tests for contracts (Foundry), fuzzing (Echidna), integration tests on testnet.
- Security audit: check contracts via Slither/Mythril, external audit.
- Deployment and monitoring: deploy on mainnet, configure Tenderly, Grafana.
What is included in the work
- Development of smart contracts for aggregator and adapters for 5+ marketplaces
- Backend order indexing (custom indexer or based on Reservoir)
- Frontend with search, filtering, cart, and wallet integration
- Multichain integration (Ethereum, Polygon, Arbitrum, Base)
- Security audit and gas optimization
- API and smart contract documentation
- Post-launch support (3 months)
Estimated timelines
| Stage | Duration |
|---|---|
| MVP (1 chain, 2 marketplaces) | 2-3 weeks |
| Full product (5+ marketplaces, multichain, analytics) | 2-3 months |
| Audit and optimization | +2-4 weeks |
Cost is calculated individually depending on complexity and number of integrations.
Our team has 5+ years of experience in blockchain development and has delivered over 20 projects in the DeFi and NFT space, including marketplace aggregators. We guarantee compliance with modern security standards and gas optimization.
Assess your project for free — contact us for a consultation.