An NFT aggregator shows listings from many marketplaces in one place and lets buyers purchase across them in a single transaction. The two hard parts are keeping a fresh, accurate index of other venues' orders and executing multi-venue purchases safely through a router contract. Everything else is a well-designed trading interface.
How aggregators changed NFT trading
In 2021 and 2022, aggregators such as Gem and Genie let traders "sweep" the cheapest items in a collection from several marketplaces in one transaction, saving time and gas. Both were acquired, by OpenSea and Uniswap respectively, in 2022. Blur launched later that year as a trader-focused marketplace with aggregation built in and a token incentive program, and quickly took a large share of Ethereum NFT volume, much of it from traders farming rewards. The lesson: aggregation became a feature that large marketplaces absorbed, and incentives can manufacture volume that disappears when rewards end.
A new aggregator therefore needs a reason to exist beyond "all listings in one place": a specific chain or niche that is under-served, better tools for a particular trader type, or aggregation embedded in another product such as a wallet or game.
Core features
- Unified feed: all active listings for a collection, normalized from each source with price, fees and expiry.
- Price comparison: the total cost per item including marketplace fees, creator royalties and gas, so buyers compare real prices.
- Cart and sweep: select many items across marketplaces, or "buy the cheapest N", and purchase in one transaction.
- Search and filters: by trait, rarity, price, marketplace, and listing age.
- Cross-listing: list an item on several marketplaces at once by signing each venue's order format.
- Collection bids and offers: show and accept the best offer across venues.
- Portfolio dashboards: holdings, estimated values, profit and loss, activity.
- Payments: pay in ETH, stablecoins or other tokens, swapped in the same transaction; card checkout through an on-ramp for mainstream users.
- Creator royalty handling: display each venue's royalty policy, and optionally let buyers pay full royalties even where they are optional.
Architecture
| Component | Role | Key challenges |
|---|---|---|
| Order ingestion | Collects listings and offers from each marketplace | Each venue has a different API, order format and rate limits; some orders are only fully available on-chain |
| Order validation | Removes stale orders | Orders become invalid when the item moves, approval is revoked, or the order is cancelled; check continuously |
| Normalized order book | Common schema across venues | Fee, royalty and currency differences; partial-fill ERC-1155 orders |
| NFT and metadata index | Collections, traits, ownership, rarity | Usually from an NFT API plus your own index; see the NFT API guide |
| Router contract | Executes purchases across venues atomically or with partial success | Security, gas efficiency, refund handling |
| Swap integration | Converts the buyer's token to what each order requires | Slippage limits, DEX aggregator integration |
| Frontend | Trading interface | Real-time updates, large collections, mobile performance |
The router contract
The router receives a list of purchase instructions, one per order, each targeting a specific marketplace contract. For every instruction it calls the venue's fill function, forwarding payment, and directs the NFT to the buyer. Design choices:
- All-or-nothing vs partial fills: if one item in a 20-item sweep was sold a second earlier, should everything revert, or should the router skip it and refund the unused funds? Most traders prefer partial fills with a refund.
- No standing approvals: buyers should not need to grant the router broad token approvals. Use exact-amount payments, Permit2-style signatures, or native currency.
- No custody: the router should never hold user NFTs or funds beyond a single transaction, and leftover balances should be impossible or sweepable only to the user.
- Venue adapters: isolate each marketplace's integration in a separate module, so adding a venue does not touch core logic.
Routers are attractive targets because they interact with many external contracts. A rigorous smart contract audit and conservative upgrade controls are mandatory.
Cross-listing
To list on several venues, the seller signs an order for each venue's protocol. Many Ethereum marketplaces use Seaport, so one approval often covers several venues, but each still has its own fee recipients and signing domain. When a sale happens on one venue, the other listings must be invalidated; the item moving achieves this automatically, but your UI should update immediately so buyers do not hit failed transactions.
Details traders notice
Aggregators compete for a demanding audience. Professional traders compare tools on small details, and they switch quickly:
- All-in prices: show the price including marketplace fee, royalty and estimated gas, and sort by that, not by the headline listing price.
- Freshness indicators: show when each listing was last validated, and remove items the moment they sell anywhere.
- Gas-aware sweeps: estimate the transaction's gas before signing and warn when a sweep is large enough to fail on block gas limits.
- Private transaction submission: offer submission through private relays so large sweeps are less exposed to front-running in the public mempool.
- Keyboard shortcuts and bulk actions: listing fifty items one by one is the kind of friction traders leave for.
- Clear attribution: show which marketplace each order comes from and its royalty policy, so buyers know who gets paid.
Building it: step by step
- Pick your chain(s) and niche. On Ethereum and its Layer 2s, most volume runs through Seaport-compatible venues plus Blur; on Solana the venue set and standards differ entirely, as the Solana marketplace guide explains.
- Integrate order sources: marketplace APIs where available, on-chain events otherwise. Get API agreements in writing, since venues can rate-limit or cut off aggregators.
- Build the normalized order book with continuous validation.
- Build the router contract with per-venue adapters, partial fills and refunds, and test it against forked mainnet state.
- Build the trading frontend: collection pages, trait filters, cart, sweep, bids, portfolio.
- Add swap-based payments and, optionally, card checkout.
- Audit, launch with a small set of venues, and expand.
Revenue models
- Aggregator fee on purchases. Competition pushed this to zero at many aggregators, so a fee needs a clear value story.
- Marketplace referral fees, where venues pay aggregators for routing volume.
- Premium tools: analytics, alerts, faster data, bidding bots.
- Your own marketplace fees, if you also run a venue and route some volume to it.
- Advertising and featured collections: clearly labeled, or you lose trader trust.
- Native token: possible, but incentive tokens tend to attract wash trading and mercenary volume. Treat as high-risk.
Risks to plan for
- Source dependence: if a major marketplace blocks your API access, your feed has a hole. Build on-chain fallbacks where possible.
- Infrastructure churn: several NFT data and order-routing providers have shut down or repriced since 2023. Keep integrations behind your own interfaces so you can switch.
- Stale data: failed purchases from stale listings destroy trust. Measure and display data freshness.
- Phishing and fake collections: aggregating many sources also aggregates their scams. Maintain verified-collection lists, flag lookalike contracts, and never let a listing's metadata inject links or scripts into your interface.
- Router exploits: a bug in the router can expose every user who has interacted with it. Keep approvals minimal, cap upgrade powers behind a timelock, and run a bug bounty from day one.
- Thin market: overall NFT volume is far below its 2021 to 2022 peak. Model revenue on realistic volume in your niche.
Cost and timeline
| Scope | Reasoned estimate | Assumptions |
|---|---|---|
| Single-chain aggregator MVP | 4–6 months | 5–6 engineers; 3–4 venues; NFT API for metadata; one router audit |
| Multi-chain aggregator | 8–12 months | Separate venue adapters per chain; Solana requires a separate program and indexer |
| Ongoing | Continuous | Venue integrations break when venues upgrade; budget permanent maintenance |
For a single-venue marketplace instead, see the NFT marketplace development guide; for an aggregator spanning chains, the cross-chain marketplace guide explains the extra messaging and bridging layer.
Frequently asked questions
Do aggregators hold users' NFTs or funds?
They should not. A well-designed router moves assets directly from seller to buyer within one transaction and refunds unused funds immediately.
How does an aggregator get listings from other marketplaces?
Through each marketplace's API, from on-chain order events, or both. Signed off-chain orders, such as Seaport orders, can be filled by anyone who has the order data.
Do creators get royalties on aggregator purchases?
The aggregator fills the underlying marketplace's order, so that venue's royalty policy applies. Some aggregators let buyers choose to pay full royalties voluntarily.
What happens if one item in a sweep sells before my transaction lands?
With partial-fill routing, that purchase is skipped and its funds refunded while the rest go through. With all-or-nothing routing, the whole transaction reverts.
Can an aggregator cover Ethereum and Solana together?
Yes, but as two separate backends and execution layers sharing a frontend. A single transaction cannot buy across both chains.
Is it better to build an aggregator or a marketplace?
An aggregator is useful only where liquidity is fragmented across venues. If your niche has one dominant venue or none, a focused marketplace with its own supply is usually the better bet.