NFTs & Metaplex Blueprint
NFTs on Solana are not a separate ledger object. They combine scarce on-chain ownership, program-defined metadata, and off-chain media that wallets and markets agree how to display. Metaplex supplies the standards, SDKs, and launch tooling most teams use; once you see model, storage, collection, mint path, and read path as one stack, Core vs Token Metadata, Candy Machine, and DAS stop looking like unrelated products.
NFT Basics on Solana is the hands-on entry; Metaplex Core, Metadata & Storage, Collections & Verification, Candy Machine, and Reading NFTs (DAS API) each zoom into one layer. This page sits underneath: how the pieces connect, which standard to pick, and how production apps mint and read assets.
Summary
- A Solana NFT is ownership plus metadata under a Metaplex (or compression) program - Core Asset accounts, Token Metadata mint graphs, or compressed tree leaves - with JSON and media usually off-chain and DAS as the standard client read surface.
- Insight: Wrong standard choice burns rent and integration time; weak storage or verification ruins trust; launch without guards or scale planning fails at mint; reading raw PDAs instead of DAS breaks wallets and galleries.
- Key Concepts: NFT model (supply, decimals, ownership), Metaplex Core, Token Metadata (legacy), uri + off-chain JSON, collections and verification, Candy Machine / guards, compressed NFTs (cNFT), DAS API.
- When to Use: Designing new collections, integrating marketplaces or token gates, choosing Core vs legacy vs cNFT, planning a public drop, or building portfolio and explorer UIs.
- Limitations/Trade-offs: Off-chain media can rot or be mutated depending on host; royalties need marketplace or program enforcement; cNFTs trade simpler accounts for proofs and indexer dependence; DAS requires a DAS-enabled RPC provider.
- Related Topics: NFT basics, Metaplex Core, metadata and storage, collections and verification, Candy Machine, DAS reading.
Foundations
Solana has no native "NFT type" in the runtime. Scarcity and identity come from programs and conventions: a unique asset identity, an owner, and metadata that markets treat as art, tickets, or items.
Historically that meant SPL Token mints with supply = 1 and decimals = 0, plus Metaplex Token Metadata for name, uri, creators, and collection. That multi-account graph still holds huge secondary volume. Metaplex Core modernizes the story: one Asset account (plus optional plugins) holds name, uri, owner, and update authority with lower rent. Compressed NFTs go further: leaves in a concurrent merkle tree make per-mint cost tiny in exchange for proofs and indexer reliance.
Layers from ownership out to product surfaces:
+------------------------------------------+
| Product UI (wallet, gallery, gate) | <- DAS + your app logic
+------------------------------------------+
| Launch / mint path (Candy Machine, |
| Core create, Bubblegum, custom program) |
+------------------------------------------+
| Collection identity + verification |
+------------------------------------------+
| Metadata JSON + media (Arweave/IPFS/HTTP)|
+------------------------------------------+
| On-chain asset model |
| (Core | Token Metadata | cNFT leaf) |
+------------------------------------------+
| Cluster / RPC (Agave, kit, DAS-RPC) |
+------------------------------------------+On-chain asset model answers what is owned and who can update it. Core stores owner on the Asset; Token Metadata ties ownership to an SPL token account holding the mint's single unit; cNFTs encode ownership in tree state verified by proofs.
Metadata and storage answer what it looks like. On-chain fields stay short (name, uri). The uri points at JSON with image, attributes, and optional animation. Arweave optimizes for permanence; IPFS needs pinning; plain HTTPS is convenient and mutable.
Collections and verification answer which group is real. Anyone can paste a collection pubkey into cosmetics. Markets and gates trust verified membership from the collection authority (or Core collection linking).
Candy Machine answers how many people mint fairly. Config, guards (payment, allowlist, limits, go-live), and item lists drive public drops, often Token Metadata via Sugar. Huge free or low-value drops often use Bubblegum cNFTs instead.
DAS (Digital Asset Standard) answers how clients read everything the same way. Provider methods such as getAsset, getAssetsByOwner, and getAssetsByGroup unify Core, Token Metadata, and cNFTs so apps avoid raw GPA and PDA math for galleries.
This site pins @solana/kit 7.0.0 for standard RPC and transactions. Metaplex Umi plugins remain the common write path for Core, Candy Machine, and Token Metadata. Custom programs that validate NFT ownership use Rust 1.91.1 and, when chosen, Anchor 0.32.1.
Mechanics & Interactions
Choose the ownership model first
Pick the on-chain standard before art pipelines or mint sites.
| Model | Identity | Ownership | Best fit |
|---|---|---|---|
| Metaplex Core | Asset pubkey | Field on Asset account | New 1/1s and collections (default 2026) |
| Token Metadata | Mint pubkey | SPL token account (supply 1) | Legacy integrations, older markets |
| cNFT (Bubblegum) | Asset id / leaf | Tree leaf + proof | High volume, low rent per item |
Metaplex Core is the greenfield default: program CoREENxT6tW1HoK8yfYWXSzaXUcGUimvH2vQJ55jEo, with plugins for royalties, attributes, freeze, and collection links. Use Token Metadata when partners still require mint + metadata PDA + master edition (metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s). Use cNFTs when full-account rent dominates (game drops, large free mints). Layouts: NFT Basics on Solana.
Metadata is a uri contract, not only on-chain bytes
Mint and update instructions store a short uri. Clients fetch JSON, then media. Accounts stay small; permanence and mutability live in storage.
on-chain asset (name, uri, authorities)
|
v
metadata JSON --> image / animation_url / attributes
|
v
Arweave | IPFS | HTTPS hostProduction collections usually upload with Sugar or similar bundlers, validate schema, and prefer content-addressed hosts. Mutable HTTPS is fine for prototypes and controlled reveals; it is a trust risk if the host can swap art after sale. See Metadata & Storage.
Collections need a verify step to mean anything
A collection is a shared identity (Core collection account or Token Metadata collection mint) plus a link from each item. Verification is the authority-signed proof that the link is intentional.
Collection authority --verifies--> Asset/metadata --> Collection identity
|
v
DAS grouping / marketplace badge / token gateUnverified collection fields are spoofable. Gates and secondary markets should require verified membership. Query with DAS getAssetsByGroup, not client-supplied labels. See Collections & Verification.
Candy Machine is launch orchestration, not the NFT standard
Candy Machine v3 holds launch config: supply, redeemed count, hidden settings, and guards (payment, allowlists, mint limits, start times). Each mint creates assets per config (often Token Metadata). Sugar is the operator CLI: validate, upload, deploy, test mint, reveal.
assets/ + config --> sugar validate/upload --> CM + guards
--> public mints (itemsRedeemed++) --> optional reveal urisFor very large drops, compare rent against Bubblegum instead of full Token Metadata accounts. Candy Machine is the fair-launch control plane for classic generative drops; it is not required for a handful of Core creates. See Candy Machine.
DAS is the production read path
Wallets should not discover NFTs by scanning Metaplex programs with raw getProgramAccounts. DAS-enabled RPC returns shaped assets:
| Method | Typical use |
|---|---|
getAsset | Single detail page |
getAssetsByOwner | Wallet portfolio |
getAssetsByGroup | Collection explorer / gate |
searchAssets | Filtered discovery |
@solana/kit --> JSON-RPC (send tx, balances, status)
DAS RPC --> getAsset* / searchAssets (portfolio, gallery)
Umi + mpl-* --> mint, update, CM, Core instructionsUse kit for transactions and chain status; DAS for asset graphs and cNFT surfaces. Plan for provider pagination and caching. See Reading NFTs (DAS API).
How the pieces interact in one launch week
- Pick Core vs Token Metadata vs cNFT from scale and integration constraints.
- Prepare media and JSON; choose Arweave/IPFS/HTTPS and uri freeze policy.
- Create collection identity; verify at mint or immediately after.
- Public drops: Candy Machine guards on devnet; small Core sets: Umi
createplus collection plugins. - Point UIs at DAS for portfolios; use kit for payments and non-DAS RPC.
- Document royalty bps and which markets or plugins enforce them.
- Reveal if needed; spot-check uris and DAS rows after mint.
Advanced Considerations & Applications
Match scale, marketplace needs, and read complexity to a path; deepen launch and indexing only as risk grows.
| Path | What you run | Strengths | Weaknesses | Best fit |
|---|---|---|---|---|
| Core 1/1 or small set | Umi + mpl-core, permanent storage, DAS | Low rent; plugins; simple ownership | Some legacy TM-only tooling | New art, tickets, memberships |
| Generative public mint | Sugar + Candy Machine + guards + reveal | Fair phases; proven ops | Higher per-mint cost; TM-oriented | Classic PFP launches |
| Mass distribution | Bubblegum trees + DAS | Cheap per item; huge supply | Proofs, tree capacity, indexers | Games, POAPs, coupons |
| Legacy integration | Token Metadata + DAS | Max secondary compatibility | Multi-account rent and complexity | Older collections or partners |
Core small set is the default for product NFTs that are not mass free mints. Plugins cover royalties and rules without a parallel metadata program.
Generative public mint optimizes timed fairness and payment routing. Stress-test guards, priority fees, and sold-out races on devnet; automate reveal.
Mass distribution optimizes economics. Budget tree depth and canopy; treat DAS as required infrastructure.
Legacy integration is marketplace reality. Prefer DAS for reads; hand-derive metadata PDAs only for custom indexers or non-DAS environments.
Do not conflate layers: Candy Machine is not Core, DAS is not a mint path, a collection name is not verification, and HTTPS is not permanence. Design reviews should lock ownership model, storage permanence, verification, mint fairness, and DAS methods first.
Common Misconceptions
- "Solana has a built-in NFT opcode." Scarcity and metadata are program conventions (Core, Token Metadata, Bubblegum), not a special runtime type.
- "Core and Token Metadata are the same under the hood." Different account graphs, transfer semantics, and SDKs; only the product concept "NFT" is shared.
- "Setting a collection field is enough for a blue check." Without verification (or Core collection rules), the field is spoofable.
- "Royalties always pay on every transfer." Secondary royalties depend on marketplace policy and optional on-chain enforcement plugins or hooks, not plain SPL moves alone.
- "Candy Machine is required for every collection." Use it for fair multi-phase launches; small Core mints can call create instructions directly.
- "getProgramAccounts is fine for wallet galleries." It is fragile, heavy, and incomplete for cNFTs; DAS is the production read standard.
- "IPFS without pinning is permanent." Availability lasts only as long as something pins the CID; plan pinning or prefer Arweave for permanence goals.
- "cNFTs remove the need for infrastructure." They remove per-mint rent; they increase dependence on trees, proofs, and indexers.
FAQs
What is the single most important idea in Solana NFTs?
Treat an NFT as ownership plus metadata under a chosen standard (Core, Token Metadata, or compressed leaf), with off-chain media and DAS as the usual product read path.
Should new projects use Metaplex Core or Token Metadata?
Default to Metaplex Core for new assets unless a partner, marketplace path, or tooling still requires Token Metadata layouts.
When should I use compressed NFTs instead?
When you need very large mint volume and per-item rent would dominate cost (game items, mass tickets, free drops), and you accept proof and DAS dependencies.
What does the on-chain uri actually store?
A short pointer (HTTPS, ar://, IPFS gateway URL, and so on) to JSON that describes the asset and links media; it is not the full image bytes.
Why do marketplaces care about collection verification?
Unverified collection labels can be forged; verification proves the collection authority endorsed the asset membership.
Is Candy Machine only for art PFPs?
No. Any multi-item drop that needs timed access, payments, allowlists, or mint limits can use Candy Machine guards; art PFPs are just the famous case.
How does DAS relate to @solana/kit?
Kit targets general Solana RPC and transactions. DAS is an extended JSON-RPC surface on provider nodes for digital assets; many apps use both.
Can I read Core and Token Metadata with the same client code?
Yes for portfolio-style reads: DAS normalizes them. Write paths still use the matching Umi plugin or program instructions per standard.
Do I need Anchor to ship NFTs?
No. Most mint and update flows are client-side with Metaplex SDKs. Anchor helps when your program must validate ownership, gates, or custom NFT-linked state.
Where do royalties live?
In metadata fields or Core royalty plugins (basis points and creators). Enforcement is a separate marketplace or plugin concern, not automatic on every transfer.
How do I token-gate by collection in an app?
Query DAS for the wallet's assets in the collection group (or verify on-chain as needed), then authorize your API or program from that membership check.
Is Sugar required for Candy Machine?
Not strictly, but it is the standard operator path for validate, upload, deploy, and reveal. Umi suits custom mint UIs after deploy.
What should I build first for a minimal NFT feature?
Mint one Core asset with a permanent uri, read it with getAsset, add collection verification, then Candy Machine or cNFT only if scale requires it.
Related
- NFT Basics on Solana - account-level NFT models and standard choice overview
- Metaplex Core - single-account Asset standard and plugins
- Metadata & Storage - off-chain JSON, Arweave, IPFS, and uris
- Collections & Verification - grouping assets and why verification matters
- Candy Machine - fair mint config, guards, and Sugar launches
- Reading NFTs (DAS API) - portfolio, collection, and search reads
Stack versions: This page was written for Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1, and @solana/kit 7.0.0.