I knew NFT stood for non-fungible token, meaning a unique token that isn't interchangeable like a currency. Beyond that, I mostly associated NFTs with digital images and ownership.
After spending a week creating NFTs, attaching metadata, organizing them into collections, auditing them on-chain, and updating them live on devnet, I came away with a different mental model. What changed wasn't my understanding of ownership.
It was my understanding of structure.
An NFT is still a token
The first thing I learned is that NFTs are not a separate asset type on Solana.
Under the hood, the NFT I created used the same SPL token model I had been working with throughout the Token-2022 challenges.
There was still:
- a mint account
- a token account
- an owner wallet
The difference was entirely in the configuration. The NFT mint was created with:
- a supply of 1
- 0 decimals
- the mint authority removed after minting
Once the mint authority was disabled, no additional tokens could ever be created. That permanently locked the supply at one.
What appears to be a completely different asset category is actually the same token architecture configured with different rules.
spl-token create-token --decimals 0
spl-token mint <NFT_MINT_ADDRESS> 1
spl-token authorize <NFT_MINT_ADDRESS> mint --disable
Metadata gives the asset context
A token with a supply of one is unique, but uniqueness alone does not explain what the asset represents. To make the NFT meaningful, I attached metadata using the Metadata Extension which included a name, a symbol and URI.
The URI points to a JSON file containing additional information such as the image, description, and custom attributes.
One detail I hadn't considered before is why the URI exists in the first place. Storing images and large metadata files directly on-chain would increase account size significantly, making storage more expensive. Instead, the NFT stores a reference to the metadata through a URI, while the larger files remain off-chain.
When a wallet displays an NFT, it reads the metadata stored on-chain, follows the URI, retrieves the JSON file, and then renders the asset. In other words, the NFT stores the reference, not the image itself.
Collections introduce relationships
Creating a collection introduced another layer of structure. Using the Group and Member extensions, I created a collection NFT and linked multiple NFTs to it.
The simplest way I can describe it from a Web2 perspective is as a parent-child relationship.
The collection acts as the parent, the individual NFTs act as members that reference that parent. This reminded me of how related records are connected in a database. The relationship is not implied by naming conventions or application logic. It is stored directly on-chain. That means anyone can independently verify whether an NFT belongs to a collection.
# Create a collection mint
spl-token create-token --enable-group
# Create an NFT and attach it to the collection
spl-token create-token --group <COLLECTION_MINT>
Verifying the relationship on-chain
After creating the collection, I wanted to see how that relationship was actually represented. Using spl-token display and Solana Explorer, I inspected both the collection mint and the NFT mints.
The important detail was that each NFT contained a Group reference pointing back to the collection mint. That meant collection membership wasn't just something maintained by a marketplace or wallet interface. It was part of the NFT's on-chain configuration and could be verified by anyone reading the account data.
This was one of the more useful exercises of the week because it reinforced a recurring theme in Solana development:
don't assume something exists—inspect the account and verify it.
Updating metadata after minting
One thing I tested next was modifying the NFT after it had already been created.
Using the Token-2022 metadata extension, I:
- changed the NFT name
- added and removed custom metadata fields
- updated the URI to point to a different metadata file
The updates appeared immediately on-chain.
The image, however, did not always update immediately. The reason is that these are two different layers of data.
The name, symbol, URI, and metadata fields live on-chain.
The image is stored off-chain and retrieved through the URI.
Many wallets cache metadata responses, which means visual updates can take longer to appear even though the on-chain change has already been confirmed. This was a useful reminder that an NFT is often a combination of on-chain state and off-chain content.
What changed in my understanding
I started the arc thinking of NFTs primarily in terms of uniqueness and ownership. I finished thinking about configuration, metadata, and relationships.
The NFT itself was not the most interesting part.
The more interesting discovery was that NFTs on Solana are built from the same foundations as every other asset I've worked with so far: mints, token accounts, metadata, and program-enforced rules. The image is what users see, the structure behind it is what defines the asset.
This post is part of #100DaysOfSolana. Follow along as I continue exploring how assets are built on Solana.
Top comments (0)