Building an NFT marketplace requires integrating blockchain smart contracts with a traditional web application. Here's the full architecture — from smart contract design to frontend implementation and indexing infrastructure.
Ankit Verma
Blockchain Lead
NFT marketplaces follow three models: curated (the platform selects which collections to list — Foundation, SuperRare), open (anyone can list any NFT — OpenSea), and collection-specific (a single collection's primary and secondary market — NBA Top Shot). Each model has different smart contract requirements. Curated marketplaces need approval workflows. Open marketplaces need efficient listing for any ERC-721/1155 token. Collection-specific marketplaces integrate the minting and trading into a single contract.
The marketplace smart contract handles three operations: listing (seller lists an NFT at a fixed price or auction), buying (buyer purchases a listed NFT), and offer/bidding (buyer makes an offer that the seller can accept). The critical design decision: custody model. In the custodial model, sellers transfer NFTs to the marketplace contract, which holds them until sold. In the non-custodial model (preferred), the marketplace uses ERC-721 approvals — the seller approves the marketplace contract to transfer their NFT, and the contract transfers it only when a sale occurs.
The non-custodial model is safer (the marketplace never holds user assets) and gas-efficient (no transfer on listing, only on sale). OpenZeppelin's ERC-721 holds the approval pattern. The marketplace contract uses transferFrom with the seller's approval to move the NFT to the buyer on purchase, taking a platform fee in ETH before transferring the remainder to the seller.
Querying blockchain state directly is too slow for a marketplace UI. You need an indexing layer that listens to blockchain events (ListingCreated, SaleCompleted, OfferMade) and stores them in a queryable database. The architecture: an event listener service (using ethers.js or viem) subscribes to marketplace contract events, processes them, and writes to a PostgreSQL database. The frontend queries the database, not the blockchain.
For production, we use The Graph Protocol (subgraph) or a custom indexer. The Graph provides decentralized indexing with a GraphQL API — you define a subgraph schema and mapping functions, and The Graph's network handles indexing and serving. For marketplaces needing custom query patterns or faster indexing, a custom indexer with PostgreSQL and a GraphQL API (Hasura or PostGraphile) provides more control.
The marketplace frontend is a standard Next.js application with Web3 integration. Wallet connection uses wagmi (React hooks for Ethereum) with RainbowKit or ConnectKit for the wallet UI. Transaction signing uses wagmi's contract write hooks. The frontend reads from the indexer's GraphQL API for listings, sales, and collection data — never directly from the blockchain for display data.
The critical UX challenge: blockchain transactions take 12–30 seconds to confirm. The frontend must handle this gracefully — show pending state immediately after the user signs, poll for confirmation, and update the UI when the transaction is indexed. Optimistic UI updates (showing the expected state before confirmation) improve perceived performance but require rollback handling if the transaction fails.
NFT metadata (image, description, attributes) is stored separately from the blockchain token. The token URI on-chain points to a metadata JSON file, which contains the image URL and attributes. Storage options: IPFS (decentralized, permanent — preferred for art NFTs), Arweave (permanent storage with upfront cost), or centralized storage (AWS S3 — cheaper but not decentralized). For marketplaces, support both IPFS and HTTP metadata — most existing NFTs use one or the other.
Image rendering should use a CDN-backed IPFS gateway (Pinata, Infura, or nft.storage) with fallback to alternative gateways. IPFS gateway reliability varies — implementing fallback logic prevents broken images when a primary gateway is slow or unavailable.
Gas costs are the biggest friction in NFT marketplace adoption. Three optimization strategies: batch operations (list multiple NFTs in a single transaction using ERC-721's batch approval), off-chain signatures (the seller signs a message authorizing the sale, and the buyer submits the transaction — only one gas payment instead of two), and L2 deployment (deploying the marketplace on Polygon, Arbitrum, or Base reduces gas costs by 10–100×). The off-chain signature pattern (used by OpenSea's Seaport and Blur) is the most impactful — it eliminates gas costs for sellers entirely. This is the exact architecture our NFT marketplace development team ships, built on the same smart contract development discipline used across every audited contract we deploy.
Tags
Continue Reading
Enterprise blockchain isn't about cryptocurrency. It's about multi-party workflows where trust is expensive. Hyperledger Fabric provides permissioned blockchain for supply chain, trade finance, and healthcare. Here's the architecture and implementation guide.
Smart contract vulnerabilities have cost over $3 billion in losses. Most vulnerabilities follow known patterns that are preventable. Here's the security checklist we use before deploying any smart contract to production.
A practical guide to building AI agents that actually work outside of demos — covering tool selection, memory, error recovery, and deployment patterns we've validated in production.
From AI agents to mobile apps — iMOBDEV builds what your business needs.
