Core and Compressed NFTs

Token Metadata uses two accounts per NFT: SPL Token mint + metadata PDA. Works, but expensive. Metaplex Core simplifies with one account containing everything. Compressed NFTs go further: millions of NFTs in one account using Merkle trees.

Core provides cleaner architecture. Compressed NFTs enable massive scale. Both reduce costs dramatically.

Metaplex Core: Single Account NFTs

Token Metadata NFTs require:

• Mint account (82 bytes, 0.00144 SOL rent)

• Metadata PDA (~700 bytes, 0.012-0.02 SOL rent)

• Total: ~0.015 SOL per NFT

Metaplex Core NFTs require:

• Single Core Asset account (~300-400 bytes, 0.006-0.008 SOL rent)

• Total: ~0.007 SOL per NFT

50% cheaper, simpler, no SPL Token dependency.

How Core works:

Core Asset account contains everything:

pub struct Asset {
    pub key: Key,
    pub owner: Pubkey,
    pub update_authority: Pubkey,
    pub name: String,
    pub uri: String,
    pub seq: u64,  // Sequence number for updates
}

No separate mint account, token accounts, or SPL Token program involvement—pure NFT program handling everything.

Transfers:

Token Metadata transfers involve SPL Token program (transfer token from one token account to another).

Core transfers happen entirely within Core program (change owner field in Asset account).

Simpler validation. Fewer accounts. Lower compute costs.

Metadata:

Same off-chain JSON approach. URI points to Arweave/IPFS. On-chain account stores minimal data (name, URI, owner).

Collections, royalties, attributes work similarly. Different program, same concepts.

Core Advantages

Cost:

50% cheaper per NFT. 10,000 collection: save ~$75 in rent deposits.

Simplicity:

One account instead of two. Fewer PDAs to derive. Less complex transaction building.

Performance:

Smaller accounts = less data to read/write. Faster transactions. Lower compute usage.

Flexibility:

Plugin system for custom behavior. Add royalty enforcement, transfer restrictions, custom logic without protocol changes.

Core Disadvantages

Newer standard:

Less battle-tested. Fewer years in production. Some tools/integrations still catching up.

Compatibility:

Programs expecting Token Metadata SPL Tokens won't work with Core assets. Requires explicit Core support.

Marketplaces adding Core support but Token Metadata more universal.

Migration:

Existing Token Metadata collections can't easily migrate. Would require minting new Core versions.

Compressed NFTs: Merkle Tree Architecture

Regular NFTs (Token Metadata or Core): One account per NFT. 1 million NFTs = 1-2 million accounts = $15,000-30,000 in rent.

Compressed NFTs: Many NFTs in one Merkle tree account. 1 million NFTs in one tree = ~$500.

How compression works:

Merkle tree stores hashes of NFT data, not full data. Tree account contains root hash and proofs.

NFT "exists" as proven membership in tree. No dedicated account per NFT.

Tree structure:

Tree Account
├─ Max depth (determines capacity)
├─ Max buffer size
├─ Root hash
└─ Proofs for all NFTs

Depth 14 tree = 16,384 NFTs max. Depth 20 tree = 1,048,576 NFTs max. Depth 30 tree = 1,073,741,824 NFTs max (billion+).

Tree account rent depends on depth, not number of NFTs actually minted. Pay once for capacity, fill gradually.

Compressed NFT Operations

Creating tree:

const tree = await createTree(umi, {
    maxDepth: 14,         // 16,384 NFT capacity
    maxBufferSize: 64,
});

Cost: ~$10-500 depending on depth. One-time payment for tree account.

Minting compressed NFT:

Update tree with NFT proof. No new accounts created.

await mintToCollectionV1(umi, {
    tree: tree.publicKey,
    leafOwner: owner,
    metadata: {
        name: "My NFT #1",
        uri: "https://arweave.net/...",
    },
});

Cost: ~$0.0001 per mint (proof update cost).

Transferring:

Update tree proof, change owner. Requires proof of current ownership.

await transfer(umi, {
    tree: tree.publicKey,
    leafOwner: currentOwner,
    newLeafOwner: newOwner,
    proof: ownershipProof,
});

Proof verification ensures only real owner transfers. Tree update changes ownership record.

Reading compressed NFT:

Can't read directly from tree (hashes only). Requires indexer.

Indexers watch tree updates, maintain database of current state. DAS (Digital Asset Standard) API provides queries.

Wallets query indexers, not tree directly. Indexers return NFT data, ownership, metadata.

Compressed NFT Trade-offs

Massive cost savings:

1 million NFTs:

• Token Metadata: $28,800 rent

• Core: $7,000 rent

• Compressed: $500 tree + $100 minting = $600 total

48x cheaper than Token Metadata, 12x cheaper than Core.

Requires indexers:

Can't query tree directly. Must use indexer (Helius, Triton, etc.).

Indexers are centralized services. If indexer goes down, can't read NFT data.

Solana Foundation runs public indexer (DAS API), but adding dependency.

More complex transfers:

Regular NFTs: Just sign transfer transaction.

Compressed NFTs: Include proof of ownership. Proof must be current (from latest tree state).

Concurrent transfer limitations:

Multiple simultaneous transfers to same tree can conflict. Tree updates are sequential.

High-throughput applications need careful coordination.

When to Use Each Standard

Use Token Metadata when:

Maximum compatibility critical. Every tool supports it.

Existing project already using it.

Programmable NFTs needed (pNFTs require Token Metadata).

Can't depend on indexers (want pure on-chain reads).

Use Core when:

Starting new project, want best practices.

Lower costs matter (50% cheaper than Token Metadata).

Simpler architecture preferred.

Willing to verify marketplace/tool support.

Use Compressed NFTs when:

Scale matters (millions of NFTs).

Cost optimization critical (100x cheaper than regular).

Can depend on indexers (acceptable centralization).

Use cases: gaming (millions of items), loyalty programs (millions of members), large collections, event tickets at scale.

Real World Examples

Mad Lads (Compressed NFTs):

10,000 NFT collection using compressed NFTs. Backpack team demonstration of scale.

Chose compression for cost efficiency and technical showcase.

Drip Haus (Compressed NFTs):

Fashion NFTs. Thousands of digital fashion items.

Compression enables affordable mass minting for fashion drops.

Tensor (Marketplace):

Supports Token Metadata, Core, and Compressed NFTs.

Shows all three standards viable in production.

Star Atlas (Gaming):

Thousands of in-game items as NFTs.

Uses compression for scale (ships, weapons, resources).

Most major collections (Token Metadata):

Okay Bears, DeGods, Famous Fox Federation all use Token Metadata.

Standard remains most widely adopted for established projects.

Practical Comparison

10,000 NFT collection costs:

1,000,000 NFT collection costs:

The scale difference is dramatic. Compressed NFTs enable applications impossible at regular NFT costs.

Choosing Your Standard

Decision framework:

1. How many NFTs? (under 10K: any standard. Over 100K: consider compressed)

2. Need maximum compatibility? (Yes: Token Metadata. No: Core or Compressed)

3. Can depend on indexers? (No: avoid compressed. Yes: compressed is option)

4. Cost sensitivity? (High: Core or Compressed. Medium: Token Metadata fine)

5. Existing project? (Yes: probably stick with current standard. No: evaluate all options)

Migration is hard:

Once you choose, switching is difficult. Token Metadata to Core requires minting new NFTs. Can't "convert" existing tokens.

Plan for your scale. Starting with 10K but eventually want 1M? Consider compressed from start.

Recommendation for new projects:

Small collections (under 10K), maximum compatibility desired: Token Metadata

Small collections, cost-conscious, modern stack: Core

Large collections (over 100K), gaming, loyalty programs: Compressed NFTs

All three are production-ready. Choose based on your requirements, not "newest is best."

Next: Wrapping up what you learned and next steps for building NFT projects.