Can I add extra fields to NFT metadata while still adhering to NEP 171?

NFT
1

I’m involved in a project on the NEAR blockchain and I want to incorporate some additional fields in my NFT metadata. My primary worry is whether introducing custom attributes would violate the NEP 171 specifications.

I’ve considered a few solutions for this dilemma. One possibility I thought of is inserting my custom JSON data into the extra field within the NFT metadata. Is this a viable solution?

To illustrate, I aim to add custom fields like this:

let customMetadata = {
  name: "My Unique Token",
  description: "A description for the token",
  image: "https://example.com/my_image.png",
  extra: {
    rarity: "rare",
    power: 100,
    artist_details: {
      name: "Jane Smith",
      series: "Epic Collection"
    }
  }
};

What would be the best way to expand NFT metadata without losing NEP 171 compatibility?

2

hey @OwenGadget78! really interesting question - what kind of NFT collection are you working on that needs these custom fields?

NEP 171 is pretty flexible with metadata structure. The extra field approach sounds solid, but you’ve got other options too.

Why not add your custom fields directly to the root metadata object? Keep the required fields like title and description intact, then toss in your additional properties. Shouldn’t break compatibility.

When you say “losing NEP 171 compatibility” - worried about marketplace integration? Different platforms handle custom metadata differently even when it’s technically compliant.

Have you tested this yet or still planning? I’m curious about your specific use case for rarity and power fields - sounds gaming related?

3

Your extra field approach is spot on and won’t break NEP 171 compliance. I’ve used similar custom metadata in production contracts - works great. The spec explicitly allows additional fields beyond the core ones.

Just make sure your contract’s metadata methods properly serialize those extra fields when called. I hit issues early on where extra data wasn’t returning correctly from view functions.

Heads up - some indexing services won’t automatically parse nested custom fields. If you want to query by rarity or power later, you’ll probably need custom indexing. Your artist_details structure looks good, just keep field naming consistent across your collection for easier queries.

For marketplace compatibility, most major NEAR marketplaces display standard fields and ignore custom ones - which is usually what you want anyway.

4

totally agree! the extra field works great for custom data. nep 171 allows it, so you’re good. just keep the core fields like title and description intact. i’ve used it before - wallets and marketplaces handle it fine.