Building a Solana NFT Marketplace: Standards, Programs and Indexing

A Solana NFT marketplace lets users list, buy and bid on NFTs that are stored as separate Solana accounts, not as entries inside one contract. This guide explains the asset standards a marketplace must read, the listing program, the indexer and the build steps, so you can scope the engineering work.

This page covers the technical build. For the business side, the feature checklist and the choice of a niche, read the separate Solana NFT marketplace development guide.

The Solana NFT marketplace landscape in 2026

Two marketplaces carry most Solana NFT trading, and their shares of trading volume change from month to month, and published figures conflict.

Both marketplaces already trade most of the Solana NFT standards described below, so a new Solana NFT marketplace needs a narrower audience, such as a game, a brand, a loyalty program or one artist community.

How Solana stores an NFT

On Solana, programs (Solana's name for smart contracts) hold no data of their own. Data lives in separate accounts, and each account is owned by one program.

A classic Solana NFT is a set of accounts: an SPL token mint with a supply of one token and zero decimals, a token account in the owner's wallet that holds that token, and a Metaplex metadata account that stores the name, symbol, URI, creators and royalty share.

Every account must hold a deposit of SOL called rent, which grows with the account's size and comes back when the account is closed. Solana is cutting the rent rate in five steps under SIMD-0437, and the first two steps went live in September 2026, lowering the rate from 6,960 to 5,080 lamports per byte. The Solana reduced-rent page tracks the remaining steps, and lower rent makes it cheaper to mint NFTs and to create listing accounts.

The NFT standards a marketplace must read

The mint costs come from the Metaplex Core documentation and the Bubblegum v2 documentation, and the rent cuts in 2026 make current costs lower than these published figures.

Collectors hold all of these types, so a general marketplace supports at least legacy NFTs, pNFTs, Core assets and compressed NFTs. Bubblegum v2 replaced v1 for new projects, and v2 trees cannot hold v1 leaves. The Metaplex documentation says Magic Eden and Tensor do not yet trade v2 compressed NFTs, so a marketplace that trades them would face no large competitor yet.

Metaplex also lists several older programs as deprecated, including the original Candy Machine, Auction House and Token Auth Rules. Token Auth Rules holds the rule sets of existing pNFTs, so a marketplace still reads it for pNFT transfers. New launches use Core Candy Machine instead of the original Candy Machine.

Listing models: escrow and escrowless

Early Solana marketplaces moved a listed NFT into an escrow account owned by the marketplace program, so the NFT left the seller's wallet and the seller could not list it on a second marketplace.

Most marketplaces now use escrowless listings. The seller gives the marketplace program the authority to transfer the NFT, and the NFT stays in the seller's wallet. When a buyer pays, the program uses that authority to move the NFT, and the same transaction pays SOL to the seller, to the creators and to the marketplace's fee account.

An escrowless design has to handle these cases:

• The seller moves or sells the NFT elsewhere, so the listing must become invalid.
• A delegation stays open after a delisting, so the program must revoke it.
• pNFTs and Core assets carry royalty rules, so the sale transaction must follow those rules.
• Traders place bids on any item in a collection, and the bid's SOL sits in an escrow account that the marketplace program controls until a seller accepts.
• Every Solana transaction lists the accounts it touches, and pNFT and compressed NFT transfers touch many accounts. Versioned transactions and address lookup tables keep these transfers under the transaction size limit.

Writing the Solana smart contract

The marketplace's Solana smart contract is a program, usually written in Rust, that handles five instructions: list, delist, buy, place a bid and accept a bid. Most teams use the Anchor framework, where the developer declares which accounts and signers each instruction needs and Anchor checks them. Anchor also generates an IDL file, which describes the program's interface for client code. Anchor reached version 1.x in 2026, and its release page lists the current version.

The tools and fee settings around the program are these:

• Metaplex Umi is a JavaScript client for minting and reading Core, Token Metadata and Bubblegum assets.
• Solana Kit (@solana/kit) is the current JavaScript SDK, which new projects use, while older code uses @solana/web3.js 1.x, which now receives fixes only.
• Wallet adapter code connects Phantom, Solflare, Backpack and other wallets.
• Local testing runs a local validator with the Metaplex programs cloned from mainnet, and LiteSVM runs fast program tests without a validator.
• Fees: each signature costs a base fee of 5,000 lamports. During congestion, a transaction also needs a priority fee and a compute-unit limit to be included in a block.

Most Solana program exploits come from missing checks. A program must check that the right wallet signed, that each account belongs to the expected program and that derived addresses use the expected seeds, and a program that skips one of these checks lets an attacker pass a fake account. The smart contract audit guide explains how to scope a review of these checks.

Indexing with the DAS API

A marketplace cannot list a wallet's NFTs fast by reading Solana accounts one by one, and compressed NFTs do not exist as accounts at all. The Digital Asset Standard (DAS) API, which many Solana RPC providers offer, solves both problems. It returns assets by owner, collection or creator across all standards, and also returns the Merkle proof that a compressed NFT transfer needs.

DAS covers the assets, and your own indexer covers marketplace events such as listings, sales and bids, reading them from Geyser plugin streams or from your RPC provider's webhooks. The NFT API guide explains how to compare providers. Metadata and images for Solana NFTs usually sit on Arweave, and the marketplace caches them.

Build steps

1. Choose the asset standards for launch, the marketplace fee and the royalty policy for legacy NFTs.
2. Write the marketplace program in Anchor with escrowless listings, collection bids and royalty payment.
3. Test the program on a local validator with cloned Metaplex programs, then on devnet, and fuzz the account checks.
4. Build the indexer and API on DAS and your program's events.
5. Build the front end: wallet connection, collection pages, sweeping, bids and activity feeds.
6. Add priority fees, compute-unit limits and retries for expired blockhashes.
7. Commission an external audit of the program before mainnet.

Cost and timeline

These figures are an estimate based on the scope above, not on quotes. An MVP that covers escrowless listings for legacy, pNFT and Core assets, DAS indexing and a full front end needs four to six engineers for three to five months, and at least one of them needs production experience with Rust and Anchor.

Compressed NFT trading and pool-based trading are outside this MVP, and each adds several weeks of engineering. An external audit of a marketplace program adds its own fee and two to six weeks of calendar time. If you plan to mint collections as well, the minting platform guide covers launch tools.

Frequently asked questions