Who pays for a Metaplex transaction on Solana?

The designated payer funds the Solana transaction fee and any new account balance required by the instruction. That payer may be the same wallet as the minter, owner, or authority, but the roles can differ. Candy Machine instructions can separate the payer and minter, while guards may still charge token-based requirements to the minter. Changing the payer does not transfer asset authority.

Can metadata change after an asset has been minted?

Metadata can change while the relevant update authority or an authorized delegate remains active. Core allows its authority to update the name and URI, while Token Metadata follows its own update-authority rules. For Core, setting the update authority to none makes the name and URI immutable; Token Metadata uses its isMutable flag. A fixed on-chain URI does not freeze a file served from mutable storage, so the storage method also affects permanence.

Where do images and attributes for a Solana NFT reside?

Images and extended attributes usually reside outside the asset account in a JSON document reached through its URI. The on-chain program stores the locator and the authority data needed for the selected asset standard. Applications then fetch the JSON and any media that it references. If those files become unavailable, the on-chain asset can remain valid while its image or extended description stops loading.

Is a DAS-enabled RPC required for every asset operation?

No, a DAS-enabled RPC is not required for every Core or Token Metadata instruction. Applications can fetch known program accounts directly and submit writes through standard Solana RPC methods. DAS becomes important for indexed queries across owners or collections, and compressed asset operations need it to retrieve asset data and Merkle proofs. The required read path therefore follows the selected asset model.

Does Token Metadata support direct conversion to Core?

Token Metadata does not provide an in-place conversion that turns an existing NFT into a Core Asset. The standards use different account structures, so a Core replacement receives its own address and state. Burning the original asset and creating another one are separate, potentially irreversible operations. Any migration must also account for collection membership, ownership records, and integrations that still reference the original address.

Will a royalty setting force every secondary sale to pay creators?

A royalty percentage alone does not force every sale path to distribute payment. Standard Token Metadata royalties can depend on marketplace cooperation, while programmable NFTs and Core can apply transfer rules through their respective rule systems. Core’s Royalties plugin can restrict which programs transfer an asset, but the marketplace still handles royalty collection and distribution. The exact behavior follows the asset standard and configured rules.

Metaplex

Metaplex helps creators choose Solana programs for minting and managing digital assets

Metaplex provides a set of Solana programs and developer tools for creating, organizing, distributing, and reading digital assets. The right path starts with the asset model: Core for account-based NFTs, Token Metadata for fungible tokens and established NFT workflows, or Bubblegum for compressed NFTs. Candy Machine adds a configurable drop layer, while Umi and the CLI provide different ways to call those programs. The choice determines account structure, required infrastructure, authority checks, and how applications confirm the finished asset.

Start with the asset that must exist

The intended asset type determines the program, account structure, compatible collection model, and read infrastructure.

Core fits new NFTs that benefit from a compact account model and extensible plugins. Use Token Metadata for fungible tokens, editions, programmable NFTs, and integrations that already expect its mint, metadata, and token accounts. This is a compatibility decision as much as a minting decision. Wallets, marketplaces, indexers, and existing collection state must understand the selected standard.

Bubblegum uses a different storage model. It represents compressed NFTs as leaves in a Merkle tree rather than separate asset accounts. That structure lowers per-asset storage requirements, while tree creation, proof retrieval, and compatible RPC infrastructure become part of the application design.

Distribution comes after the asset model. Add the matching Candy Machine when a collection needs a guarded public mint. A direct program instruction is simpler for an authority-controlled creation flow. If the task is a fungible-token launch rather than asset creation alone, Genesis is the specialized launch path.

Core keeps NFT state in one account

Core is the direct choice for an NFT that needs simple ownership state and optional behavior through plugins.

A Core Asset stores its owner, name, URI, and update authority in one Solana account. The URI points to extended off-chain metadata, such as an image, description, or attributes. This arrangement avoids the separate mint and token accounts used by traditional Solana NFTs.

Plugins add behavior without changing that basic ownership model. They can represent attributes, royalties, transfer delegates, freeze controls, and other rules. Collection plugins can supply shared behavior, while asset-level settings can override supported inherited values. Each plugin has its own authority, so ownership alone does not grant every management permission.

The update authority controls changes to the name, URI, and collection relationship. Setting that authority to none makes those fields immutable. That action cannot be reversed, and it does not make a mutable file at the URI permanent.

Token Metadata covers fungible and established NFT models

Token Metadata connects descriptive and authority data to assets that use Solana token accounts.

Open full-size image

For a fungible token, the SPL Token program governs supply and balances, while Token Metadata provides fields that applications use to identify and present the token. Its NFT model also supports standard NFTs, editions, collections, and programmable NFTs. Programmable NFTs support token records and optional authorization rule sets for controlled transfers.

Existing collections often retain this model because their assets and integrations already depend on its accounts. Moving to Core does not alter those original accounts in place. A project must create a separate Core asset if it decides to migrate, then handle the old asset deliberately.

Collection membership also needs a precise check. A Token Metadata asset can contain a collection key before the collection authority verifies it. Applications should treat the key and its verified flag as a pair rather than accepting the claimed collection address alone.

When does Bubblegum fit the job?

Bubblegum fits collections where compressed storage matters enough to accept proof-based reads and writes.

A concurrent Merkle tree stores hashed asset leaves and establishes the collection’s capacity. Tree configuration affects upfront rent and the proof size needed for later operations. A canopy can keep upper tree nodes on chain, which reduces the proof data that transactions must carry.

Bubblegum V2 is not compatible with Bubblegum V1 trees. V2 also uses Core collections rather than Token Metadata collections. A library, tree, and collection from different generations cannot form a valid workflow merely because each belongs to the same broader ecosystem.

When does Bubblegum fit the job?: A concurrent Merkle tree stores hashed asset leaves and establishes the collection’s capacity.; Tree configuration affects upfront rent and the proof size needed for later operations.; A canopy can keep upper tree nodes on chain, which reduces the proof data that transactions must carry.

Open full-size image

Compressed asset operations rely on current Merkle proofs. A DAS-enabled RPC supplies the indexed asset data and proofs needed for transfers, updates, burns, and similar actions. Standard RPC access alone does not provide that read layer. The program still validates the required authority, tree, and proof when processing the instruction.

Candy Machine adds controlled distribution

Candy Machine organizes a collection drop after the underlying NFT standard has been selected.

Core Candy Machine mints Core assets. The Token Metadata Candy Machine path handles standard and programmable NFTs from that account model. Choosing the wrong branch creates a compatibility problem that guard settings cannot repair.

Candy Guards provide the access-control layer. Individual guards can enforce a start or end date, an allowlist, a mint limit, a required payment, or ownership of a qualifying asset. Guard groups let one machine expose different combinations of those conditions. A mint request must include any extra accounts or values required by the resolved guards.

Candy Machine adds controlled distribution: Candy Machine organizes a collection drop after the underlying NFT standard has been selected.

Open full-size image

When Bot Tax is active, a failed guard check can produce a successful transaction without minting an NFT. The guard can still collect the configured tax, so a transaction signature alone does not establish asset creation. Confirm the created asset and its expected owner before treating the mint as complete.

Tooling changes how the same program is called

The CLI suits direct terminal work, while Umi suits application code and repeatable transaction construction.

The CLI can create and inspect assets, manage metadata, select wallets and RPC endpoints, and prepare Candy Machine configurations. It is useful for bounded administrative operations where an interactive command or configuration file is enough. Command support varies by program, so the installed command set should match the intended operation.

Umi composes program plugins with an RPC connection, identity, payer, storage uploader, and transaction builders. It provides more control when an application must calculate inputs, collect signatures, or react to program state. Switching from the CLI to Umi does not change the asset standard because both routes call the selected on-chain program.

DAS is an indexed read layer rather than a replacement for program authority. It can assemble ownership, metadata, collection data, and plugin information for queries. Direct account fetching may suit a known Core or Token Metadata address, while compressed assets require the indexed proof path.

A failed write should narrow the next attempt

Assume a Bubblegum transfer cannot obtain an asset proof because the configured RPC lacks DAS support. Repeating the same transaction will not supply the missing dependency.

Use this decision checklist before another attempt:

Identify the Bubblegum version and the tree that contains the asset.
Confirm that the RPC supports DAS and returns a current proof.
Check whether the signer is the recorded owner or an authorized delegate.
Rebuild the instruction with the current proof and intended recipient.
After confirmation, fetch the asset again and compare its owner field.

If every prerequisite holds, the refreshed proof lets the program evaluate the transfer against the tree’s current state. A changed owner field then confirms the expected state transition.

Add access to a DAS-enabled RPC when proof retrieval is unavailable, or use a library that supports the asset’s tree version. Do not retry the transfer until that missing dependency is in place.

Metaplex questions, answered

Who pays for a Metaplex transaction on Solana?: The designated payer funds the Solana transaction fee and any new account balance required by the instruction. That payer may be the same wallet as the minter, owner, or authority, but the roles can differ. Candy Machine instructions can separate the payer and minter, while guards may still charge token-based requirements to the minter. Changing the payer does not transfer asset authority.
Can metadata change after an asset has been minted?: Metadata can change while the relevant update authority or an authorized delegate remains active. Core allows its authority to update the name and URI, while Token Metadata follows its own update-authority rules. For Core, setting the update authority to none makes the name and URI immutable; Token Metadata uses its isMutable flag. A fixed on-chain URI does not freeze a file served from mutable storage, so the storage method also affects permanence.
Where do images and attributes for a Solana NFT reside?: Images and extended attributes usually reside outside the asset account in a JSON document reached through its URI. The on-chain program stores the locator and the authority data needed for the selected asset standard. Applications then fetch the JSON and any media that it references. If those files become unavailable, the on-chain asset can remain valid while its image or extended description stops loading.
Is a DAS-enabled RPC required for every asset operation?: No, a DAS-enabled RPC is not required for every Core or Token Metadata instruction. Applications can fetch known program accounts directly and submit writes through standard Solana RPC methods. DAS becomes important for indexed queries across owners or collections, and compressed asset operations need it to retrieve asset data and Merkle proofs. The required read path therefore follows the selected asset model.
Does Token Metadata support direct conversion to Core?: Token Metadata does not provide an in-place conversion that turns an existing NFT into a Core Asset. The standards use different account structures, so a Core replacement receives its own address and state. Burning the original asset and creating another one are separate, potentially irreversible operations. Any migration must also account for collection membership, ownership records, and integrations that still reference the original address.
Will a royalty setting force every secondary sale to pay creators?: A royalty percentage alone does not force every sale path to distribute payment. Standard Token Metadata royalties can depend on marketplace cooperation, while programmable NFTs and Core can apply transfer rules through their respective rule systems. Core’s Royalties plugin can restrict which programs transfer an asset, but the marketplace still handles royalty collection and distribution. The exact behavior follows the asset standard and configured rules.

Last updated · 17-Sep-2026