SageSage NFT Minting With Metadata and Royalty Settings
Sage supports minting Chia NFTs with file references, custom metadata, and royalty settings. Its minting inputs distinguish the NFT's media from descriptive metadata and any license file. These files connect to the token through locations and cryptographic hashes. Finalize their contents before minting, because the default NFT1 metadata updater cannot replace existing hashes. Royalties govern payments on eligible later sales, while minting creates the token itself. The light wallet remains in beta.
Updated onKey takeaway: Finalize metadata before minting, because the default NFT1 updater cannot replace its hash when you correct a file.
Media Files and Custom Metadata
Media references identify the NFT's underlying content, while metadata describes the item through fields a compatible wallet or marketplace can interpret. Sage's minting API separates data, metadata, and license URI lists, with corresponding SHA-256 hash fields. A URI identifies a file location, while a hash identifies its contents. Keeping these purposes separate prevents a metadata description from replacing the actual media reference, or a license location from becoming the artwork location. Custom metadata can hold descriptive attributes and collection information. A license file states the terms associated with the item. Each category needs its own preparation when you include it.
Hosting files and minting serve separate purposes: the token records references and hashes, while the hosting service supplies the file bytes. A successful mint therefore does not make an unavailable file accessible.
What Can Change After Minting?
The default NFT1 updater lets an owner prepend new file locations while preserving existing locations and hashes. The default NFT1 metadata updater cannot change the metadata hash. Adding another location can preserve access when hosting changes. Editing the metadata file changes the material the stored hash identifies, so a new location does not make revised contents match the original commitment.
File integrity depends on exact bytes, so reformatting a JSON metadata file can change its hash even when its descriptive meaning stays the same. An image host can also alter an uploaded file through conversion or compression. Keep the final files intact, and calculate their hashes from the same bytes their locations return. Visual similarity alone does not establish a matching file.
Public metadata also deserves a content review before minting. Names, descriptions, attributes, and collection details can disclose information once someone retrieves the file. The standard updater cannot remove an existing location from the token. Avoid embedding private contact details or secrets in a file intended for public retrieval. Removing a hosted copy does not erase copies other people retain.
Custom metadata updaters can have different rules, so the default updater's location updates do not establish an editing capability for every NFT implementation.
Royalty Settings Define Eligible Sale Payments
Royalty settings specify a payment percentage and recipient for eligible sales under the NFT's transfer program. The standard NFT1 royalty structure is permanent after minting. Standard offer sales for fungible assets include the configured royalty payment. The buyer pays that royalty in addition to the seller's requested amount. The transaction fee remains separate. An NFT's initial recipient and its royalty recipient also have different roles, even when the same address fills both.
Direct transfers and NFT-for-NFT swaps do not incur sale royalties under the standard transfer program. Separately arranged payments can fall outside an offer's royalty calculation. A configured percentage does not establish a resale price or create liquidity. Its payment amount follows the eligible trade's actual inputs.
Signing, Confirmation, and Minting Costs
Minting requires a signing wallet with spendable funds for the transaction's outputs and any selected fee. Sage connects to Chia peers or a trusted full node, so running a local full node is optional. Its minting API supports transaction preparation and an automatic-submission option. A prepared transaction and a returned NFT identifier can exist before blockchain confirmation. Confirmation establishes inclusion on the selected network; the NFT's ownership and file integrity require their own checks.
Minting costs vary with the transaction's coin spends, NFT outputs, and execution requirements. Fee pressure also changes with competing transactions. Creator identity operations can add work. A royalty percentage does not set the minting fee.
Hypothetical Edition Batches and Confirmed Outputs
A hypothetical comparison asks whether to mint 12 editions or 22 editions of the same finalized files. Both drafts assume a synchronized signing wallet, a selected creator DID ( decentralized identifier ), sufficient spendable funds, the same media and metadata bytes, one chosen NFT recipient, unchanged royalty settings, and the same total transaction fee. Assume each NFT output carries one mojo, Chia's smallest native unit.
The 12-edition draft assigns 12 mojos to NFT outputs, and the 22-edition draft assigns 22 mojos. Increasing the batch adds 10 mojos to those outputs, before the fee and any other outputs. The NFT output amounts remain in the created coins; they are separate from the transaction fee. More editions also add execution work. Holding the total fee constant therefore does not hold the transaction's fee per unit of execution cost constant.
For the 12-edition draft, completion means a confirmed mint containing 12 distinct NFTs at the selected recipient. Their edition fields should match the chosen numbering and declared total. File hashes and royalty fields should match the finalized inputs. Returned identifiers alone do not prove confirmation. These records establish the issuance even if no sale follows. Choosing 22 editions changes the expected count and declared total to 22.
Collection Metadata and Minter Provenance
Collection metadata groups items descriptively, while a minter's decentralized identifier, or DID, supplies on-chain provenance. CHIP-0007 defines a JSON metadata format wallets and marketplaces can interpret consistently. Its optional collection object includes an identifier and a name. Collection names and attributes do not authenticate the creator by themselves. Copies can carry the same descriptive text, so provenance requires the relevant on-chain identity relationship.
Sage supports DID management alongside NFT minting and transfers. A creator DID associated with minting records a different relationship from the NFT's current owner DID. Ownership can change as the token moves. Keep creator provenance, current ownership, and the royalty payment destination distinct when interpreting an NFT's details. None of these fields replaces the media or metadata hash.
How Do Editions Differ From a Series?
Editions describe distinct NFTs sharing identical media and metadata, while a series describes different items grouped within a collection. NFT1 stores edition numbering and the declared edition total on chain. CHIP-0007 supplies optional series numbering and totals within the off-chain metadata file. Each edition still has its own NFT identity. Sharing files does not merge the tokens into a single asset, and an edition label does not prevent another mint referencing those files.
If the media or metadata differs across items, series information describes that distinction.
Questions and answers about Sage
Which Fields Does CHIP-0007 Require in Custom NFT Metadata?
CHIP-0007 requires format, name, and description fields in a JSON metadata object. The format value is CHIP-0007. Attributes and collection information are optional. If you include a collection object, it needs both a name and an identifier in UUID format. Following the schema helps compatible applications interpret the descriptive fields.
Can an NFT Royalty Reach Multiple Recipients?
The standard NFT1 royalty structure contains one recipient address, which can point to a smart coin distributing payments onward. Multiple final recipients therefore require distribution logic behind that address. Entering an ordinary address does not create a split, and Sage's royalty address field alone does not configure those distribution rules.
Does Repeating a Mint Correct an Existing NFT?
A new mint creates a separate token and leaves the existing NFT unchanged. Repeating the same mint inputs can produce separate NFT identities referencing identical files. A pending submission does not establish confirmed issuance, so its transaction state matters before you create a replacement token.
Does a Larger Media File Automatically Increase the Blockchain Minting Fee?
A larger off-chain media file does not automatically increase the blockchain minting fee. The NFT's on-chain puzzle contains its references and hashes; the media bytes stay off chain. Transaction execution and competing network demand affect fee requirements. Hosting or upload costs can change separately, and larger on-chain data can change execution requirements.
Will Minting With Sage Automatically Put the NFT Up for Sale?
Minting creates the NFT without automatically creating a sale offer. Sage supports offer files as a separate trading function. A later offer specifies the assets exchanged and applicable royalty payments. The metadata's description, a configured royalty percentage, or possession of the NFT does not establish an active sale offer.