Arc 7 Catch-Up: Building NFTs from First Principles

Arc 7 of 100 Days of Solana was about building NFTs from first principles.

Instead of starting with marketplaces, profile pictures, or NFT culture, the arc stripped the model back to the underlying token mechanics: supply, decimals, mint authority, metadata, collections, and provenance.

After Arc 6, we already knew that Token-2022 can turn tokens into programmable objects with rules: interest, fees, frozen accounts, credentials, revocation, and metadata.

Arc 7 took that model into NFTs.

But the useful surprise was that NFTs are not a completely separate world.

The whole arc hangs off one idea:

A Solana NFT is built from the same token primitives you already know.

For Web2 developers, that is the shift worth noticing.

An NFT is not magic. It is not “a JPEG on the blockchain.” It is not a special category of database record maintained by some mysterious NFT system.

At its simplest, an NFT is a token mint with:

• supply locked at one
• zero decimals
• mint authority disabled
• metadata attached
• optional collection membership

That is the foundation Arc 7 built up, one layer at a time.

NFTs are not separate from tokens

Arc 7 started by stripping the NFT model down to its smallest useful form.

Before metadata, images, attributes, marketplaces, or collections, an NFT is just a token that cannot be split and cannot be duplicated.

That means two choices matter immediately:

decimals = 0
supply = 1

Zero decimals means the token cannot be divided into fractions. You cannot own 0.5 of it.

Supply of one means there is only one unit.

But supply of one is not enough by itself. If the mint authority still exists, someone could mint another unit later.

So the final step is to disable the mint authority.

That is the moment the token becomes meaningfully non-fungible. The network can see that the supply is one, the decimals are zero, and no authority remains that can create a second copy.

For Web2 developers, a useful comparison is a unique database row with a primary key.

But the analogy only goes so far.

In a normal database, the application owner can usually edit the row, clone it, delete it, or change the surrounding rules. On Solana, once the mint authority is disabled, the supply constraint is enforced by the token program.

The uniqueness is not a UI convention. It is not a marketplace promise. It is part of the token state.

Metadata turns a token into something recognizable

The first NFT in Arc 7 was intentionally plain.

It had no name, no image, no creator story, no attributes, and no collection. It was non-fungible, but not especially meaningful to a human.

That is where metadata comes in.

Arc 7 used Token-2022 metadata to give the NFT a name, symbol, and URI. The URI pointed to an off-chain JSON file containing richer information such as the description, image, and attributes.

That gives us a two-layer model:

On-chain:
mint, supply, decimals, authority, name, symbol, URI

Off-chain:
image, description, attributes, richer display data

That split matters.

The expensive, consensus-critical parts live on-chain. The heavier display information usually lives off-chain. Wallets and explorers follow the pointer: read the mint, get the URI, fetch the JSON, render the asset.

For Web2 developers, this is familiar once you stop treating the NFT as mysterious.

The on-chain metadata is like the core record. The URI is like a foreign key or external reference. The JSON is like the richer document the UI uses to render the page.

The important difference is that the ownership, supply, and core metadata live on a shared network rather than inside one application database.

Arc 7 also made an important historical point. In older Solana NFT workflows, metadata often lived in a separate Metaplex Token Metadata account next to the mint. In this arc, Token Extensions put metadata directly on the mint account itself.

That is why the exercise was useful. It showed the foundation before introducing convenience tooling.

An NFT collection is an on-chain relationship

Once the arc had created a single NFT, the next step was collections.

In Web2 terms, this is easy to understand.

A product belongs to a catalog.
A ticket belongs to an event.
A badge belongs to an award program.
A collectible belongs to a set.

In a database, you might model that with a foreign key:

nft.collection_id = collection.id

Arc 7 built the Solana equivalent using Token-2022 group and member extensions.

Strictly speaking, there are four related pieces:

• GroupPointer, which points a collection mint at the account that stores group data
• TokenGroup, which stores the group data itself
• GroupMemberPointer, which points an NFT mint at the account that stores member data
• TokenGroupMember, which stores the member’s group address and member number

In the arc, those pointers point back to the mint accounts themselves, so the group and member data live directly on the relevant mints.

That is why it is fair to talk about a collection mint and member mints, but the underlying model is a little more precise than “one group extension and one member extension.”

The collection mint represents the group. Each member NFT stores membership data that links it to that group.

The important part is that this relationship is not just a label in a marketplace database. It is data stored on-chain and readable by wallets, explorers, and programs.

The arc’s useful mental model was simple:

collection mint = the group
member mint = the individual NFT
member data = the link back to the group

That is the NFT version of a foreign key relationship.

But there is an extra trust step. A pointer by itself is not proof. A malicious mint can point at something it should not. So a client should not stop at “this member says it belongs to this collection.”

It needs to resolve the pointer and verify that the relationship is internally consistent.

That means checking that the member identifies the collection, and that the account being pointed to actually identifies the mint back.

And the creation step matters too. Initializing a group member is not just something any random token creator can do unilaterally. The collection’s authority has to authorize membership.

That is the stronger provenance claim: the collection relationship is not just stored on-chain; it is created through an authorized on-chain action.

As with Arc 6, the schema decisions matter. A mint must be created with the right extensions. You cannot casually retrofit yesterday’s NFT into a collection if it was not created with the member structure it needs.

That constraint can feel annoying, but it is also part of what makes the structure verifiable.

Provenance is something you can inspect

One of the most valuable Arc 7 exercises was not creating another asset.

It was auditing the collection.

That matters because NFT language often gets vague. Provenance, authenticity, ownership, rarity, official collections — these terms can become marketing fog very quickly.

Arc 7 made the idea concrete.

You inspect the collection mint.
You inspect the member NFT.
You check the member data.
You verify that the collection relationship resolves correctly.

That last step matters.

A one-way check is not enough. It is not sufficient to say:

This NFT points to collection C.

A safer check is closer to:

This NFT points to member data.
That member data names this NFT mint.
That member data names collection C.
The group data for collection C names collection C.
The membership was created under the collection’s authority.

That is what makes the relationship more than vibes.

The collection claim is not true merely because a website says so. It is not true merely because a field contains a familiar collection address. It is true when the on-chain relationship resolves correctly and the collection authority has authorized that membership.

For Web2 developers, this is like checking that a foreign key resolves correctly and that the row was created by a service with permission to write to that table.

The difference is that the database is public, shared, and inspectable by anyone.

That is a big part of the NFT value proposition when you remove the hype.

The asset can carry enough information for independent verification, but only if clients verify the relationship properly. Pointers are useful because they let accounts reference each other. They are dangerous if treated as proof on their own.

That is also why the CLI work matters.

It is tempting to think of NFTs through wallets, marketplaces, and images. But the more useful developer habit is to read the underlying state.

What is the supply?
What are the decimals?
Is the mint authority disabled?
Is metadata present?
What URI is stored?
Is there group member data?
Does it name the expected collection?
Does the pointed-to data name this mint back?
Was the membership authorized by the collection authority?

That is how NFTs stop feeling like magic.

Mutability is a design choice

Arc 7 then moved from creation to mutation.

Because the creator still held the metadata update authority, they could rename the NFT, add a custom field, remove that field, or point the URI at a new JSON file.

That is an important lesson because “on-chain” does not always mean “unchangeable.”

Some parts of the NFT were locked. The supply was one. The decimals were zero. The mint authority had been disabled.

But the metadata could still change while the update authority existed.

That is not automatically good or bad. It is a design choice.

A game asset might need metadata updates as it levels up.
A ticket might need status changes.
A credential might need expiry data.
A dynamic collectible might intentionally evolve over time.

But for other assets, mutability might undermine trust.

If someone buys an NFT because of its image, description, or attributes, they care about whether those things can change later. If a collection promises permanence, the update authority becomes part of the trust model.

Arc 7 also showed a practical split between on-chain and off-chain updates.

Changing the on-chain name or URI can happen quickly. Changing the image behind the URI depends on off-chain hosting and caching. Wallets and explorers may continue showing an old image for a while, even after the metadata has changed.

That is a useful reminder: NFTs are not purely on-chain objects.

They are hybrids.

The token, ownership, supply, and metadata pointer can live on-chain. The image and richer media often live somewhere else.

So the storage decision matters. A temporary GitHub Gist is fine for devnet learning. A serious project needs to think harder about durable storage: Arweave is designed for pay-once permanent storage, while IPFS content remains available only while someone continues to pin or serve it.

NFTs are records with ownership, display, and history

The practical Web2 bridge for Arc 7 was not “NFTs are images.”

A better bridge is:

NFTs are unique records with ownership, display metadata, and provenance.

That framing is much more useful.

A normal application might have unique records everywhere:

• event tickets
• certificates
• software licenses
• game items
• collectible cards
• access passes
• membership badges
• digital art editions
• proof-of-attendance records

In Web2, those records usually live inside one company’s database. Ownership and transfer rules are whatever that application says they are.

On Solana, the unique record can be represented as a token mint. Ownership can be held by a wallet. Supply can be locked. Metadata can be attached. Collection membership can be verified.

That does not mean every unique record should be an NFT.

It does mean the NFT model is easier to reason about once you stop starting with the JPEG.

Start with the record.

Then ask:

Should this record be unique?
Should ownership be visible?
Should it be transferable?
Should it belong to a collection?
Should its metadata be mutable?
Should the media be permanent?
Who should hold the update authority?

Those are product questions, not just blockchain questions.

That is the thread connecting Arc 7 back to Arc 6.

Token design is product design. NFT design is product design too.

Writing forces the model to become simple

Arc 7 ended, like the earlier arcs, by writing and sharing.

That matters because NFTs are surrounded by baggage. People bring assumptions from marketplaces, profile pictures, speculation, scams, and culture wars.

A useful developer write-up has to cut through that.

The best post from this arc would not start with “NFTs are back” or “NFTs are dead.” It would explain what was actually built:

I created a token with supply 1 and zero decimals.
I disabled the mint authority.
I added metadata.
I pointed the metadata at a JSON file.
I created a collection mint.
I linked member NFTs to the collection.
I inspected the on-chain relationship.

That is enough.

The point is not to defend NFTs as a category. The point is to understand the technical model.

A good write-up might focus on one concrete surprise:

• an NFT is just a token mint with specific constraints
• metadata can live directly on the mint with Token Extensions
• collection membership can be verified on-chain
• provenance is an authorized relationship, not just a marketplace claim
• metadata can be mutable if the update authority remains active
• off-chain media is only as durable as the place it is hosted

That kind of explanation is useful because it gives the next Web2 developer a handle on the system.

Not hype.

A model.

What Arc 7 sets up

Strip Arc 7 back to its core and the main ideas are clear:

A Solana NFT is built from token primitives. Non-fungibility comes from zero decimals, supply of one, and disabled mint authority. Metadata makes the asset recognizable. Off-chain JSON gives wallets and explorers richer display information. Collections are on-chain relationships between group and member data. Provenance is stronger than a pointer: the member relationship must be authorized by the collection authority and verified in both directions so pointer spoofing does not masquerade as legitimacy. Metadata mutability depends on who controls the update authority.

That is the real shift.

Arc 5 taught us to create and manage tokens.

Arc 6 taught us to design token behavior with extensions.

Arc 7 showed that NFTs are not a separate technology stack. They are the same token model, shaped into unique digital assets with metadata and provenance.

From here, the question becomes more practical:

How do these assets interact with real programs, wallets, apps, and users?

That is where the next arc can take the model beyond minting and inspection, and into more realistic application behavior.

Use this post as the map, revisit the Arc 7 challenges when you want the hands-on version, and carry the NFT mental model into what comes next.