NFT marketplace architecture decisions

Building an NFT marketplace isn’t “just deploying an ERC-721 and a React app.” The durable advantage comes from a handful of architecture decisions that determine security posture, liquidity, fees, compliance flexibility, and how fast you can iterate without breaking users.

Below are the most consequential choices we see teams make—along with the tradeoffs that rarely make it into pitch decks.

1) Custody model: non-custodial, custodial, or hybrid

Non-custodial marketplaces never hold user assets; users approve token transfers and sign listings. This is best for trust minimization and composability.

• Pros: strongest user trust, fewer regulatory headaches, assets remain in user wallets.
• Cons: harder UX (approvals, signatures), more onchain calls, more failure modes across wallets.

Custodial marketplaces hold NFTs in escrow (or in a platform wallet) and manage sales internally.

• Pros: simplest UX, easier refunds/disputes, fewer wallet quirks.
• Cons: major security liability, higher compliance obligations, custody risk is existential.

Hybrid patterns are common: non-custodial primary flows, but optional custodial accounts for fiat onboarding or “email-first” experiences.

Opinionated take: if you don’t need custody, don’t take it. Hybrid can work, but only if custodial paths are isolated and auditable.

2) Listing mechanism: escrow vs approvals vs offchain orders

There are three dominant listing architectures:

1. Escrow listings: seller deposits NFT into the marketplace contract; buyer purchases from escrow.

   • Simple purchase logic, but adds friction and custody-like risk.

2. Approval-based direct transfer: seller keeps NFT; marketplace contract is approved as operator and transfers on sale.

   • Better UX than escrow, but approvals can be dangerous if your contract has bugs.

3. Offchain signed orders (Seaport-style): seller signs an order offchain; anyone can fulfill it onchain.

   • Scales well, powers aggregators, enables complex orders (bundles, criteria-based offers).

If you want liquidity, aggregator compatibility, and lower gas, offchain signed orders are typically the winning design. You’ll pay for it in complexity (order validation, cancellations, nonce management).

3) Market contract choice: build vs integrate

You can:

• Integrate a proven protocol (e.g., Seaport, LooksRare v2-style, Rarible Protocol). You focus on UX, indexing, curation, and growth.
• Build your own exchange contract for custom fee logic, compliance gates, or novel trading mechanics.

Reality: most custom marketplace contracts are fragile for the first 6–12 months. If you’re not doing something meaningfully different, integrating a battle-tested protocol is often the highest-ROI security decision you can make.

4) Royalties: where enforcement actually happens

Royalties are not “solved” by ERC-2981 alone. ERC-2981 standardizes royalty information, not enforcement.

You have three strategies:

• Honor royalties at the UI level: simplest, but bypassable by direct contract calls or other marketplaces.
• Honor royalties at the exchange contract level: enforce within your execution path; still bypassable via other exchanges.
• Creator-controlled transfers (operator filters / transfer hooks): attempt stronger enforcement by restricting who can transfer.

Strong enforcement tends to reduce liquidity and aggregator reach. Many serious marketplaces now treat royalties as a policy/UX commitment rather than an enforceable global rule.

Practical suggestion: support ERC-2981, make royalty handling transparent, and offer creators configurable settings—but don’t architect your entire marketplace on the assumption you can force royalties everywhere.

5) Metadata architecture: onchain, offchain, or hybrid

Metadata decisions affect permanence, cost, and user trust.

• Fully onchain: highest permanence; expensive; often limits media types.
• Offchain (HTTP): flexible and cheap; weakest guarantees; requires operational maturity.
• IPFS/Arweave: middle ground; content-addressed (IPFS) or permanent storage (Arweave), but you still need pinning/gateway reliability.

Most marketplaces end up hybrid: token points to IPFS/Arweave for metadata JSON, with images/media also on decentralized storage. You still need a resilient gateway strategy and caching (especially for mobile).

6) Indexing and search: don’t pretend onchain is a database

A marketplace lives or dies by indexing: ownership, listings, offers, sales history, floor price, traits, rarity, and search.

Common approach:

• Event-driven indexer (The Graph or custom worker consuming RPC logs)
• Normalized database for listings/orders, trait stats, collection analytics
• Caching layer (Redis) for hot queries (collection pages, floors)

The big decision is The Graph vs custom. The Graph accelerates time-to-market, but some teams hit limitations around custom business logic, cross-chain views, or latency requirements. Custom indexers are work—but give you control over reorg handling, backfills, and bespoke aggregation.

Opinionated take: start with The Graph if you can, but design your data model so you can migrate to custom indexing without rewriting the product.

7) Scalability and chain strategy: single chain, L2, or multi-chain

Your marketplace architecture must match the liquidity and fee environment you’re targeting.

• Single chain (Ethereum mainnet): best blue-chip liquidity; worst UX fees.
• L2-first (Base/Optimism/Arbitrum/Polygon PoS): better UX and cost; fragmented liquidity.
• Multi-chain: biggest surface area and complexity: indexing, bridges, collection identity, and support.

A common pattern is: launch on one chain, prove demand, then expand with a shared order model and a chain-aware indexer. Avoid “multi-chain on day one” unless you have a clear distribution advantage.

8) Payment rails: ETH, ERC-20, and fiat onramps

Supporting ERC-20 payments seems easy until you handle:

• decimals, permits (EIP-2612), and approval UX
• routing for swaps (if you accept multiple tokens)
• fee extraction without breaking fills

Fiat adds another dimension: KYC, chargebacks, fraud, and custodial implications. Many teams use third-party providers for card checkout and keep onchain settlement for finality.

Decide early whether you’re building a crypto-native marketplace or a consumer marketplace that happens to use NFTs. The architecture is different.

9) Security model: audits are not the security plan

Marketplace risk isn’t just smart contracts.

• Smart contract: signature replay, order validation, token approval abuse, upgradeability pitfalls.
• Backend: webhook spoofing, price manipulation via stale cache, admin key compromise.
• Frontend: wallet-draining injection, malicious metadata rendering, compromised CDN.

Architecture choices that reduce risk:

• minimize privileged roles; use timelocks/multisigs for admin actions
• prefer immutable or minimally upgradeable contracts for exchange logic
• separate indexing from execution; never trust cached prices for settlement
• sandbox media rendering; treat metadata as untrusted input

Conclusion: optimize for liquidity, then UX, then novelty

The best NFT marketplace architectures usually look “boring”: offchain signed orders for liquidity, a robust indexer for discovery, a pragmatic metadata strategy, and security boundaries that assume every surface will be attacked.

If you’re choosing where to be custom, be custom in the product layer—curation, incentives, creator tooling, distribution—while leaning on proven standards for exchange execution and indexing patterns. In marketplaces, the fastest way to lose is to innovate inside the blast radius.