NFT Marketplace
Mint District
A place to launch a collection, sell it fairly on secondary, and actually get paid when the floor moves, without duct-taping five tools together.
Project Overview
Mint District is the marketplace we built for creators and teams who were tired of one-off mint pages, unclear royalties, and buyers who could not figure out what they were buying. Creators get a launch flow, collection pages they can manage, and pricing models that match how they want to sell: drops, auctions, or fixed price. Royalties are not a polite suggestion in the copy; they are enforced in the contract path we ship, so when something resells, the split is visible and automatic where the chain allows it. On the buy side, wallets connect through a normal React app, listings and images load fast, and search is backed by a real index instead of asking the RPC for the entire chain on every page load. We kept images and long metadata off the critical path where it made sense: IPFS or CDN for assets, hashes and pointers on-chain, so you are not paying rent to store banner art inside a transaction.
Problem
Most "marketplaces" in the wild are either a pretty mint button with no secondary story, or a generic exchange where your collection looks like everyone else's. Creators still had to explain royalties in Discord because buyers did not trust the fine print. Secondary sales are where long-term revenue lives, but only if splits are enforced and discoverable. When royalty support varies by marketplace or gets ignored, creators feel like they are subsidizing flippers. Buyers were stuck too: floor price scattered across Twitter, rarity buried in spreadsheets, and transaction states that left people wondering if they owned the thing yet. Gas spikes and failed mints without a clear message did not help. The client wanted one product: launch, list, trade, and report, with a backend that could index events fast enough that search felt like a web app, not a block explorer.
Solution
We started with Solidity for ERC-721 style collections, royalty hooks where the standard allows, and modules for timed auctions and fixed-price listings so the same contracts could cover more than one drop strategy. The Node layer listens to chain events, normalizes listings, owners, and sales into Postgres, and serves APIs for the React front end. That is how you get pagination, filters, and "sort by recent sale" without hammering the public RPC. Wallet connect and signing flow through Ethers.js patterns people already know: connect, approve where needed, mint or buy, see confirmation. We spent time on the boring states: pending, confirmed, failed, with copy that matches what actually happened. Creators get a dashboard for collection settings, mint windows, and basic analytics so they are not exporting CSVs from someone else's admin. Images and heavy JSON metadata go to IPFS or CDN; the app resolves URIs and caches what it can so repeat visits do not feel slow.
Technology Stack
Node.js
ReactEthers.jsArchitecture
Contracts own minting, sales, and royalty parameters. The browser never becomes the source of truth for balances or ownership; it reads indexed state and verifies on-chain when the user takes an action. An indexer service subscribes to events from the contracts we deploy, writes structured rows into Postgres, and powers search, listings, and history. That keeps the UI responsive even when the chain is noisy. The React app talks to the API for reads and writes that need server-side signing or secrets; for pure reads, we can still hit the node where it is simpler. Static assets and metadata go through a CDN where possible so the first paint is not blocked on IPFS. Upgrade paths for contracts were scoped carefully: we avoided "admin can change anything" defaults. Where we needed fixes, we used patterns the client could audit, not magic proxies.
Results
- 50+ collections launched
- Automatic royalty distribution to creators
- Sub-2s transaction confirmation UX