Proposal to Extend NFT Metadata Standards in the Stacks Ecosystem

1

This is related to availability of dynamic NFT(for example a character with pfp and attributes for RPG game), onchain NFT

Yea, we saw you want to shrink down the size of the node, but… :smiley:

SIP-009 currently defines the basic NFT standard in Stacks and uses the get-token-uri function, which returns a metadata link limited to 256 characters. SIP-016 describes the JSON metadata structure, including attributes, but does not define a standard way to read dynamic NFT properties directly from a smart contract.

This creates a problem for fully autonomous dynamic NFTs. A developer can store mutable token properties on-chain, such as level, status, traits, progress, game parameters, and other data. However, each contract exposes this data in its own way through custom read-only functions. As a result, marketplaces, wallets, and indexers do not have a universal way to discover and display this data, so they continue to rely on external JSON files, IPFS, or server APIs.

SIP-019 already solves part of this issue: it allows contracts to notify indexers that a token’s metadata has changed. However, it does not define a standard way for an indexer to retrieve the updated on-chain attributes after such an update.

We propose adding an optional extension to the existing SIP-009/SIP-016/SIP-019 standards: a standard interface for reading on-chain attributes and, where necessary, an extended way to retrieve full on-chain metadata.

Such an interface would allow contracts to keep any internal data-storage logic they need, while providing external platforms with a unified way to query NFT properties directly from the blockchain. This would make dynamic NFTs in Stacks more compatible with marketplaces, wallets, and indexers without relying on external servers.

The goal is to move from NFTs as “links to JSON” toward NFTs as autonomous on-chain data objects whose properties can change and be read directly from the smart contract, while remaining compatible with the existing Stacks standards.

Related: SUI has built in architecture Kiosk system - it’s nice complex instrument but it’s hard to implement on Stacks( but imo it’s worth to check and think about it at least). But 30kb for get-token-uri at least would give a serious possibilities part of that thing.

2 Likes
2

The 256 character get-token-uri limit is one obvious part of the problem. Making that bigger would definitely open up more possibilities.

But I’ve been wondering if there is another way to think about it too: instead of trying to make the NFT contract return all of the rich metadata itself, maybe the contract should be able to point to a current on-chain manifest.

The contract would still do the important contract things: ownership, permissions, game logic, state changes, progression, etc.

But the richer descriptive layer could live in a canonical manifest inscription: traits, attributes, media, relationships, provenance, version history, display logic, current metadata, and so on.

That way the contract does not have to become enormous or expose everything through custom read-only functions. It just needs a standard way to anchor or reference the current recognised manifest.

Then wallets, marketplaces and indexers have something predictable to resolve.

SIP-019 can say “this token’s metadata changed”, but maybe the next piece is a standard way to say “this is the current manifest for this token/collection”.

I’ve been drafting some related Xtrata XIPs around this idea, particularly around the XIP process itself, canonical manifests, resolver/indexer behaviour, and manifest authority/current-version registries. So XIP-000, XIP-001, XIP-006 and XIP-009 are probably the most relevant ones here. They’re still drafts, but I think this manifest-based approach could be a useful companion to simply increasing the token URI limit.

3

To change the capacity of get-token-uri is the easiest way to get new possibilities as standard for everyone.

Standard is an important detail.

4

Yes, agreed. Standard is the key point.

Increasing get-token-uri capacity is by far the simplest direct improvement because every SIP-009 collection, wallet, marketplace and indexer already understands that surface.

I’m not suggesting manifests as a separate workaround instead of a standard. More that a standard could also define how a contract points to a current recognised on-chain manifest, especially for richer metadata, dynamic attributes, provenance, relationships and version history.

So maybe the path is both: improve the existing get-token-uri standard, and also explore a standard manifest/resolver pattern for cases where metadata needs more structure than a larger URI response alone can provide.