Metaplex
Metaplex uses distinct asset lifecycles for Core and Token Metadata
Metaplex gives Core and Token Metadata different account lifecycles for Solana assets. Core keeps NFT ownership and basic metadata in one Asset account. Token Metadata coordinates a Mint account, Metadata account, and holder token account, with more records for some standards. That structural choice changes creation, updates, transfers, burns, authority checks, and the evidence an application must read before treating an operation as complete.
Account topology changes what each lifecycle check must read
One account versus at least three changes what an application must create, fetch, authorize, and reconcile. A Core Asset stores its owner, name, URI, and update authority in one Solana account. Collection membership and plugins can still introduce collection-level rules, so the Asset account is the base record rather than the only possible input to every instruction.
Token Metadata distributes state across a Mint account, a program-derived Metadata account, and the owner’s token account. A non-fungible asset also uses an Edition account, while a programmable NFT can require a Token Record and authorization rules. This model supports fungible tokens and established NFT forms, though it requires applications to reconcile several related records.
Creation commits different on-chain structures
The account model becomes fixed when the asset is created. A later metadata update does not convert one model into the other.
Core creates the Asset account
Core creates an NFT through a create instruction that initializes the Asset account with an owner, name, URI, and update authority. The creation can also establish collection membership or supported plugins. Confirmation proves that the transaction ran, while a subsequent fetch shows the committed account data and any collection relationship that later lifecycle checks must consider.
Token Metadata assembles linked records
Token Metadata creation establishes a mint and attaches program-owned metadata to it. An NFT also needs ownership state in a token account and an edition record. Client helpers may package several instructions into one transaction, yet the resulting state remains distributed. A newly assigned collection field begins unverified and requires the collection authority to verify it through another instruction.
Authority checks set the practical boundary
Account structure identifies where state resides, while authority determines which state transition may proceed.
Core validates plugins and collection rules
The owner normally controls transfers and burns, while the update authority controls the name, URI, and collection-related updates. Delegate plugins can grant narrower powers. Plugins on the Asset or its Collection participate in lifecycle validation and may approve, reject, or force-approve an event. The helpers
canTransfer,
canBurn, and
canUpdate
expose those checks as Boolean results.
Token Metadata separates owners, delegates, and mutability
Token ownership supports transfers, and the owner or an authorized delegate may burn under the applicable standard. Metadata changes instead require the update authority or a suitable delegate. The Metadata account must also remain mutable. Locks can prevent transfers or burns, and programmable NFTs add Token Record state and authorization rules to the decision.
How do updates differ after creation?
Core updates fields in the Asset account, while Token Metadata updates its separate Metadata account and preserves the Mint and ownership records.
A Core update can change the name, URI, collection membership, or update authority when the signer has permission. Changing ownership requires a transfer instead. Setting the update authority to none makes the relevant Asset data immutable, so a later signer cannot restore ordinary update access.
Token Metadata uses its update instruction for the name, symbol, URI, seller fee basis points, creators, collection field, and related metadata properties. The current update authority must sign unless an authorized delegate acts. Setting a new collection initially marks that relationship unverified, and the collection authority must complete verification separately.
Neither model stores an image merely because its URI changed. The URI points to off-chain JSON, so the referenced file must contain the intended image, description, and attributes. An immutable on-chain pointer cannot repair unavailable or incorrectly published off-chain content.
Transfers move ownership through different records
A Core transfer changes the owner recorded in the Asset account. Collection context must accompany the instruction when the Asset belongs to a Collection, and plugins may block the event. A successful transfer leaves the update authority unchanged and revokes the ordinary Transfer, Burn, and Freeze Delegate plugins tied to the previous ownership state.
Token Metadata transfers move token ownership to the destination owner while retaining the Mint and Metadata accounts. The exact account set depends on the token standard; programmable NFTs can add Token Record and authorization-rule inputs. Neither model creates a cancellable transfer queue. Before confirmation, pending status belongs to the transaction client. After confirmation, ownership changes atomically.
A transfer comparison before and after commitment
Assume three changing inputs: one hypothetical Core Asset address, one hypothetical Token Metadata NFT mint address, and one hypothetical recipient public key. Every value is hypothetical and identifies no live account. Compare both paths through the same dimensions: required records, signer authority, collection involvement, transfer restrictions, and the final ownership record.
Normal path
For Core, fetch the Asset and its Collection when applicable, evaluate
canTransfer, submit the transfer, and fetch the Asset again. The new owner field supplies completion evidence. For Token Metadata, fetch the mint, Metadata account, current token ownership, and any standard-specific records. After the transfer confirms, a fresh read must show that the recipient’s token account holds the NFT. Core uses fewer base records, while Token Metadata preserves its established account model.
Edge case and recovery boundary
If a Core freeze plugin rejects the transfer, or a Token Metadata asset is locked or the instruction lacks a required Token Record or authorization-rule account, stop before signing. Resolve the blocked condition before retrying: the authorized party must remove the applicable lock, or the application must supply the required account data. Repeat the same checks afterward. If confirmation succeeds while a cached view remains stale, refresh on-chain account data before considering another transfer.
What does each burn leave behind?
Burning removes different account sets, so the word “burned” does not describe identical on-chain remnants.
A Core owner or Burn Delegate may burn an unfrozen Asset. The operation clears the Asset data, returns most of the account rent, and leaves a small marker balance that prevents address reuse. Any SOL, tokens, or other assets held by the Asset Signer PDA must leave before the burn because the Asset can no longer execute transactions afterward.
For a non-fungible Token Metadata asset, the burn closes the token, Metadata, and Edition accounts. A programmable NFT also closes its Token Record when applicable. The Token Metadata Burn instruction does not close the Mint account because the SPL Token program does not allow that account to close. Off-chain files may remain retrievable even after their on-chain metadata link disappears.
Reconciliation checks the intended lifecycle result
A successful confirmation establishes execution, while reconciliation establishes that the intended state now exists. Core applications can refetch the Asset and applicable Collection, then inspect owner, update authority, URI, and plugin state. Token Metadata applications must inspect the records relevant to the token standard, including token ownership and any programmable state.
Off-chain metadata availability remains a separate observation in both models. A reachable JSON file does not prove ownership, transferability, collection verification, or update permission. Likewise, an on-chain URI does not prove that the referenced media will remain available.
Core fits new NFT lifecycles that benefit from one base account and plugin-based behavior. Token Metadata still supports fungible tokens, NFTs, programmable NFTs, and editions created under its account model. There is no in-place conversion between them. One concrete Core verification example is
canTransfer(authority, asset, collection).
Metaplex: reader questions
Which asset types still call for Token Metadata?
Token Metadata remains appropriate for fungible tokens and assets already built around its account model. Those assets include existing standard NFTs, programmable NFTs, and printed editions whose integrations rely on Metadata, Edition, or Token Record accounts. It remains supported, although Core is the recommended model for new NFT projects. Changing models requires a migration rather than an ordinary metadata update.
Does a Core Asset need an Associated Token Account?
No. A Core Asset records ownership directly in its Asset account and does not require an Associated Token Account. That single-account description applies to the base NFT state. Some operations still need additional context, such as the Collection account or plugin-related authorities. An application should therefore distinguish between the Asset’s storage model and the complete account list required by a particular instruction.
Can an existing Token Metadata NFT be converted directly to Core?
No. The two models use different on-chain accounts, and there is no in-place instruction that changes a Token Metadata NFT into a Core Asset. A migration would require burning the old asset and creating a new one. The new Asset would have a different address, and its metadata, collection relationship, authorities, and supported behavior would need to be established under the Core model.
Why can a Core transfer fail after the owner signs?
The owner’s signature does not override every lifecycle restriction. An active Freeze Delegate plugin can block transfer, while collection-level plugins may also affect validation. A collection member also requires the applicable Collection account in the instruction. Checking the fetched Asset, its collection relationship, and the result of canTransfer exposes these conditions before the application asks the owner to sign.
When is a Token Record required during transfer or burn?
A Token Record belongs to the programmable NFT model, not to an ordinary non-programmable NFT. It stores programmable state used during controlled actions, including delegated or locked conditions. A programmable transfer or burn may also require authorization-rule accounts. The token standard must therefore be identified before constructing the instruction, since a standard NFT and a programmable NFT do not present the same account set.
Is changing a metadata URI enough to update an NFT image?
No. The URI is an on-chain pointer to an off-chain JSON document. The intended image address and other descriptive fields must exist in that JSON. If the updated JSON is published at a new address, an authorized update must place that address in the Core Asset or Token Metadata account. An immutable pointer cannot be changed later, and changing on-chain text does not rewrite the referenced file.
Does an NFT transfer also move its update authority?
No. Ownership and metadata update authority are separate roles in both models. A Core transfer changes the owner field while retaining the existing update authority. A Token Metadata transfer moves token ownership while leaving the Metadata account’s update authority in place. If the recipient should also control future metadata changes, the current update authority must perform a separate authorized reassignment.
How are royalties handled across these two asset models?
Core represents royalty settings through a Royalties plugin that can sit on an Asset or Collection, with an asset-level plugin overriding the collection setting. Its ruleset can restrict which programs transfer the Asset. Standard Token Metadata NFT royalty fields depend on marketplace cooperation, while programmable NFTs can apply authorization rules. Metadata alone does not guarantee that every secondary transfer distributes a royalty payment.