Skip to main content
Metaplex Core Guide: Solana Mint Costs Over 80% Lower - Featured image
NFTs

Metaplex Core Guide: Solana Mint Costs Over 80% Lower

BUILDERZ

BUILDERZ

Share

In this guide

The decisions and working steps ahead.

    Why Core Costs Less: One Account per Asset

    Set Up the Client and Mint Your First Core Asset

    Collections and Plugins: Where Core Earns Its Keep

You plan a 10,000 piece NFT drop and start pricing the mint.

On Token Metadata, every NFT needs three accounts. The rent adds up fast.

Core puts the whole NFT in one account.

Metaplex says that saves over 80% per mint.

This guide covers minting, plugins, collections, and when to skip Core.

Save the 8-point launch checklist for your next drop.

Why Core Costs Less: One Account per Asset

Token Metadata sits on top of SPL Token. Each NFT is a token with a supply of one. Extra accounts describe it.

The comparison counts three or more accounts per NFT: the mint, the metadata, and the associated token account. Core drops the token layer. One account holds the owner, the name, the link to your metadata, and any plugins.

The comparison page puts numbers on it:

  • Core: about 0.003 SOL per mint, in 1 account.
  • Token Metadata: about 0.022 SOL per mint, in 3 or more accounts.

Treat those numbers as a guide, not a quote. Your real cost depends on metadata size and how many plugins you attach. Measure your own mint on devnet before you quote a budget.

Here's what changes for you as a builder:

  • Ownership lives on the asset. You read the owner field instead of hunting for a token balance of one.
  • Collections are their own account type. You skip the separate verify step after mint.
  • Royalties are a plugin. It supports allow lists and deny lists of programs, so you no longer need the separate programmable NFT variant.
  • Behavior comes from plugins. Freeze, burn, transfer, and attribute logic are all add-ons you attach.

Set Up the Client and Mint Your First Core Asset

The JavaScript client for Core runs on Umi, the official client framework. The Core JavaScript SDK docs start with two packages.

Code examplebash
npm install @metaplex-foundation/mpl-core @metaplex-foundation/umi-bundle-defaults

Then create a client, register the Core program, and mint. This version points at a test cluster and mints one asset with a royalty plugin.

Code exampletypescript
import { createUmi } from '@metaplex-foundation/umi-bundle-defaults';
import { generateSigner, publicKey } from '@metaplex-foundation/umi';
import { mplCore, create, ruleSet } from '@metaplex-foundation/mpl-core';

const umi = createUmi('https://api.devnet.solana.com').use(mplCore());
// Attach a signer identity here. Load it from your key service, not a file in the repo.

const asset = generateSigner(umi);
const creator = publicKey('YOUR_CREATOR_WALLET');

await create(umi, {
  asset,
  name: 'Genesis #1',
  uri: 'https://example.com/genesis-1.json',
  plugins: [
    {
      type: 'Royalties',
      basisPoints: 500, // 5%
      creators: [{ address: creator, percentage: 100 }],
      ruleSet: ruleSet('None'),
    },
  ],
}).sendAndConfirm(umi);

The uri field points at your off-chain JSON. Upload the image and metadata first, then pass the final link. Keep the JSON shape you'd use for Token Metadata, since wallets read it the same way.

Before you go live, swap the public endpoint for a paid RPC provider. Public endpoints rate limit hard. A mint that stalls halfway through a drop is worse than a late one. Run the full script with real metadata first. Then read the asset back and check every field.

Collections and Plugins: Where Core Earns Its Keep

A Core collection is its own account. You create it once, then pass its address when you mint each asset.

Code exampletypescript
import { createCollection } from '@metaplex-foundation/mpl-core';

const collection = generateSigner(umi);

await createCollection(umi, {
  collection,
  name: 'Genesis',
  uri: 'https://example.com/genesis.json',
}).sendAndConfirm(umi);

// Later, add `collection: collection.publicKey` to each create() call.

The 3 kinds of plugin

The Core plugins docs split plugins by who controls them. Pick the wrong kind and you'll find out after launch.

  • Owner managed plugins need the owner's signature to add. Transfer Delegate, Freeze Delegate, and Burn Delegate live here.
  • Authority managed plugins can be added and updated by the asset or collection authority at any time. Royalties, Update Delegate, and Attribute live here.
  • Permanent plugins can only be added when the asset is created. Permanent Transfer, Freeze, and Burn Delegate live here.

That last group matters most. Does your game need to freeze items later? Then add the permanent plugin at mint, because you can't add it afterward.

Collection plugins and overrides

Plugins on a collection apply to every asset in it. Collections only hold authority managed and permanent plugins. When an asset and its collection carry the same plugin type, the asset's own plugin wins.

The docs give a royalty example. Set 2% on the collection and 5% on one rare asset. That asset pays 5% and the rest pay 2%.

This is where collections pay off in daily operations. The Core overview says you can update royalties, freeze assets, or change metadata for a whole collection in a single transaction. On a game with thousands of items, that turns a weekend script into one signed call.

The 8-Point Core Launch Checklist

Here's a checklist to run before a Core mint goes live. Each line is cheap to fix in testing and costly after launch.

Code exampletext
[ ] Mint cost measured on devnet with final metadata size and plugins
[ ] Permanent plugins decided and added at create time (cannot add later)
[ ] Collection authority held by a multisig, not a hot wallet
[ ] Royalty basis points and creator split checked against the contract
[ ] Plugin authorities listed: who can freeze, burn, transfer, update
[ ] Update authority plan written: who keeps it, and when it is removed
[ ] Metadata JSON pinned to durable storage before mint opens
[ ] Wallet and indexer display tested with a real Core asset

Authority keys cause the most pain. They sit in a laptop wallet from testing, and nobody moves them. Then that person leaves.

Write the authority plan down before mint. Name who holds each key, which multisig signs, and when you'll drop update authority. Once an asset has no update authority, nobody can change it again.

What to carry over from Token Metadata builds

Two historical case studies, both built before Core, show which problems carry over. Renaissance was a royalty tool for Solana communities, built in about three months. On Core, royalty rules like those live in the royalty plugin on the asset.

The Hashlings mint and staking build is the other. Staking means locking items without moving them. On Core, that maps to a freeze plugin, decided before mint.

When to Stay on Token Metadata or Use Compressed NFTs

Core is the sensible default for new collections because it's cheaper per mint and keeps each item's rules on the asset. It isn't the right answer for every project.

The choice comes down to three questions. Do you already have holders? How many items will you mint? Does each item need its own state on-chain?

Stay on Token Metadata when you have a live collection with holders, listings, and integrations. Core assets are different accounts. Moving means burning the old NFTs and minting new ones, so you need holders to opt in and a plan for every open listing.

Look at compressed NFTs when you're minting millions of items, such as tickets or loyalty points. Compression swaps per-item accounts for a shared tree. That cuts cost again but makes you depend on an indexer. The trade is covered in why cNFTs on Solana are shaking up NFTs.

Pick Core when each item needs its own on-chain state, its own plugins, or direct program control. Game items, membership passes, and art with enforced royalties fit well. If you want the plugin and freeze logic reviewed before mint, our Solana development service covers program and client work.

FAQ

Is Metaplex Core cheaper than Token Metadata?

Yes, by over 80% per mint according to the official comparison page. The saving comes from storing the NFT in one account instead of three or more.

Can I migrate existing Token Metadata NFTs to Core?

Not automatically. Core assets are different on-chain accounts, so migration means burning the old NFT and minting a new Core asset. Plan holder opt-in and metadata continuity before you start.

Do Core royalties get enforced?

Yes, through the Royalties plugin, which supports allow lists and deny lists of programs. You set basis points and a creator split on the asset or the collection. An asset-level setting overrides the collection default.

Can I add a freeze plugin after minting?

It depends on the plugin. The owner can add a Freeze Delegate at any time, but a Permanent Freeze Delegate can only be added at creation. Decide on permanent plugins before your mint opens.

Where is the Core source code?

The program and clients are open source in the Core GitHub repository. Read the plugin code there before you depend on a rule in production.

Ship Your Core Collection With a Plan

Core makes the account model simpler and the mint cheaper. The hard choices move to plugin design and authority control, and those choices stick once you mint.

Want a second set of eyes on your plugin plan? Our Architecture Sprint runs $3K to $5K and includes an architecture map, a risk register, and a build plan. Try the checklist on your collection first, then tell us about it.

Continue reading

Want to turn your idea into reality?

Book a 20-minute intro call, or send a short project brief. We reply within one business day.