NFT Marketplace Architecture Decisions That Actually Matter

Building an NFT marketplace is less about “deploy a contract and add a React app” and more about making a few early architecture decisions that lock in your security model, operational load, and unit economics. Below are the decisions that consistently separate robust marketplaces from fragile ones.

1) Custody model: escrow vs non-custodial

Escrow (custodial contracts) means NFTs are transferred into a marketplace contract while listed. Pros: simple execution, fewer signature edge cases, easier cancellation semantics. Cons: higher user friction (approval + transfer), greater contract risk (a bug can lock assets), and more expensive listings.

Non-custodial (off-chain signed orders) keeps NFTs in the user’s wallet until sale. The “listing” is a signature authorizing a future transfer. This is the dominant approach for scale: it reduces on-chain writes (cheaper listings), keeps user custody, and enables cross-market order sharing.

Practical recommendation: default to non-custodial signed orders unless you have a strong reason to escrow (e.g., game assets needing rental mechanics, or compliance constraints). If you do escrow, isolate escrow logic in a minimal, heavily-audited contract.

2) Listing mechanism: on-chain listings vs signed orders

You have three common patterns:

1. On-chain listing state (mapping of tokenId → price). Easy to reason about, but each list/update/cancel costs gas and creates state bloat.
2. Signed orders (EIP-712) with on-chain validation at fill time. Cancellation via nonce, order hash invalidation, or “cancel-all” mechanisms.
3. Hybrid: signed orders for most items, on-chain state only for special sales (auctions, allowlists, mints).

If you want liquidity and low friction, signed orders win. But you must design around:

• Nonce strategy: per-user incremental nonce vs bitmaps vs order-specific nonces.
• Partial fills: relevant for ERC-1155 or floor orders.
• Expiration: don’t accept infinite orders unless you’re comfortable with stale approvals and user confusion.

3) Settlement architecture: direct fill vs router/aggregator

A marketplace can be:

• Single venue: your contract matches buyer and seller.
• Router-based: a settlement router can fulfill your orders and also route to external liquidity (or be routed into).

Routers are becoming the “default” because they support composability: a wallet or aggregator can fill multiple orders across venues in one transaction. The trade-off is complexity and additional surface area.

Design tip: separate concerns.

• Order validation + asset transfer in one audited settlement contract.
• Fee logic in a modular component.
• Optional router that calls the settlement contract, not the other way around.

4) Token standards and asset coverage

Supporting only ERC-721 is easy; supporting the real world is not.

Decide early:

• ERC-721 vs ERC-1155: 1155 adds batch operations and semi-fungible inventory, but complicates partial fills and UI.
• Metadata expectations: on-chain vs IPFS/Arweave vs centralized URLs. Your indexer must tolerate broken metadata.
• Collection-level permissions: are you curating collections, or permissionless? Permissionless requires stronger spam defenses and indexing strategy.

If you’re building for gaming or membership, ERC-1155 support is often non-negotiable. If you’re building for art, ERC-721 might be sufficient initially—just don’t hard-code assumptions that prevent 1155 later.

5) Royalties: policy, enforcement, and reality

Royalties are as much a product and business decision as a technical one.

Architecture options:

• Marketplace-enforced royalties: your settlement contract calculates and pays royalties. Works only for trades executed through your contract.
• Creator-controlled royalties: enforced by custom token contracts (rare, can break composability).
• Optional royalties: buyer chooses; controversial but common in bear markets.

In practice, royalties are difficult to enforce universally because NFTs can move via simple transfers or alternative settlement. If you enforce royalties, do it transparently and align with ecosystem standards (e.g., royalty registries where relevant). Also consider split payouts and multiple recipients.

Opinionated guidance: be explicit. If your marketplace depends on creator royalties for its identity, enforce them in your settlement path and accept that some volume will route elsewhere.

6) Payments: native, ERC-20, and wrapped assets

You need to decide what currencies you support and how you handle them.

Key choices:

• Native ETH/MATIC is simplest but complicates refunds and multi-fill routing.
• ERC-20 (USDC/WETH) enables exact pricing, batching, and aggregator-friendly flows.
• Permit flows (e.g., EIP-2612 where supported) reduce approvals but add edge cases.

Most mature marketplaces converge on WETH/USDC-first for routing and predictable UX, while still allowing native currency for convenience.

7) Indexing and data: The Graph, custom indexers, and truth

Your frontend cannot query blockchain state directly for a real marketplace. You’ll need an indexing layer for:

• Active listings (especially off-chain orders)
• Sales history
• Floor prices, traits, and rarity
• User portfolios and activity feeds

Common architecture:

• Event-driven indexer (custom) + database (Postgres/ClickHouse) for speed and flexibility.
• Optional The Graph for standardized indexing, but expect limitations for complex off-chain orderbooks.
• A signed order store (your API) if you use off-chain listings; it must handle spam, duplicates, and order invalidation.

Important: your index is not the source of truth—your settlement contract is. Always design UI to handle reorgs, stale data, and failed fills.

8) Security posture: approvals, signature replay, and upgradeability

The failure modes in marketplaces are repetitive:

• Signature replay across chains or contracts (fix with domain separators, chainId, verifying contract).
• Approval phishing and over-broad approvals (help users revoke; encourage per-collection approvals where possible).
• Reentrancy and callback hazards with ERC-721/1155 receiver hooks.
• Fee manipulation and rounding issues.

Upgradeability is another fork in the road:

• Immutable contracts: highest trust, harder to iterate.
• Proxy upgradeable: operational agility, but introduces governance/key risk.

Practical compromise: keep the settlement contract immutable and minimal; place evolving logic (indexing, UI, routing, merchandising) off-chain or in separate, replaceable modules.

9) Multi-chain and L2: one marketplace, many environments

If you plan to support multiple networks, avoid accidental fragmentation.

Decide:

• Separate deployments per chain with shared branding, or a unified cross-chain experience.
• How you handle collection identity across chains.
• Whether you support bridged NFTs (often messy) or chain-native collections only.

From an architecture perspective, multi-chain amplifies the need for:

• Strict signature domain separation
• Chain-aware indexing
• Clear UX around currency and gas

Conclusion

An NFT marketplace is a settlement engine plus an indexing and distribution machine. The architecture decisions that matter most are custody (escrow vs non-custodial), order design (on-chain vs signed), settlement modularity, royalty policy, and a serious indexing layer that treats the chain as truth.

If you’re optimizing for scale and composability, choose non-custodial signed orders, modular settlement contracts, ERC-20-friendly payments, and a custom indexer that can evolve with your product. If you’re optimizing for simplicity and tight control, escrow and on-chain listings can work—but you’ll pay in gas, friction, and contract risk. Either way, decide deliberately early; retrofitting these choices later is where timelines and budgets go to die.