Metaplex Foundation
Token Metadata V1.3 Proposal #444
Replies: 8 comments 28 replies
-
|
As we discussed, I really like the approach of adding extra data on Collection NFTs to distinguish them from Regular or Item NFTs. It serves both as a flag and as a data storage for currently missing information. I have however some feedback/questions. TerminologyI have a concern regarding the terminology and the naming of variables though. I don’t think the latter helps represent the former. There are 4 different types of NFTs when it comes to the Collection standard.
In an ideal world, we would have Therefore, the new variable should reflect even more strongly what it represents. I personally quite like What is the reason behind using a struct enum for that field instead of an option? Is it that we might evolve that spec in the future and we want a versioning mechanism? If so, I think the naming should clearly reflect that. Based on that premise, the following makes a lot more sense to me. pub struct Metadata {
...
/// Collection
pub collection: Option<Collection>,
/// Uses
pub uses: Option<Uses>,
pub collection_details: CollectionDetails,
}
pub enum CollectionDetails {
None,
CollectionDetailsV1 { tradeable: bool, size: u64 },
}Candy Machine IDAs discussed, an idea I had was to add an optional field to the This would allow marketplaces to not only auto-discover collections but also future launches since they can get the live date amongst other useful information. Whilst collections and candy machines are not exactly equivalent because one collection can be composed of many drops (i.e. candy machines), this might actually be a great use case for nested collections. One disadvantage of this approach is that it couples the token metadata program with the candy machine program which is really not ideal. As you pointed out privately though, we could name this something more generic like Migration of existing CollectionsDid we figure out a plan on how to migrate existing collection to this standard? |
Beta Was this translation helpful? Give feedback.
-
|
I can see the benefit to this suggestion in using the Candy Machine ID to get information from the CM. However, working backwards to get that information if a project closes the CM, that data is lost going forward. It would be nice to have information about the mint always available. There are also a decent number of minting solutions not using the most up-to-date version of Candy Machine (if at all). I think this needs to be accounted for in the spec. I suggest the spec be built in such a way that the entire ecosystem adopts it whether they use CM or not. Maybe we use |
Beta Was this translation helpful? Give feedback.
-
When I read the initial post, I thought |
Beta Was this translation helpful? Give feedback.
-
That's the idea but I'm not sure if it's actually going to be useful or if it just confuses things so am still thinking about the naming. |
Beta Was this translation helpful? Give feedback.
-
I'm coming around to this position. I do think
and
However, I think we're stuck with the anti-pattern as it is so best not to make things more confusing if possible. |
Beta Was this translation helpful? Give feedback.
-
|
Okay I understand the initial goal with |
Beta Was this translation helpful? Give feedback.
-
|
@samuelvanderwaal Thanks for putting this in GitHub! Using the Collection NFT for storing additional information will make life a lot easier for the ecosystem. My initial feedback builds a bit on what @thlorenz said above:
Multiple StatesThe Collection NFT should have extended functionality to not only be used for setting whether it is I envision a project would mint a Collection NFT as soon as possible after announcement. The following values ( An Example A tool such as MoonRank that provides a live index of a mint could auto list it on the front page as the flag switches from EDIT NOTE This idea exhibits the Collection HomeIt would invaluable to use the Collection NFT as the home for everything related to the collection. Information such as their twitter, discord, and their website would allow for better discoverability across the ecosystem. In addition, different information could be set during state changes. Announced State A project would mint the Collection NFT as soon as it is announced and include details to follow the project:
Minting State
Tradable State
Additional Thoughts
NOTE: these ideas are preliminary and aren't fully flushed out. |
Beta Was this translation helpful? Give feedback.
-
|
I like the Collection Home concept a lot but think that probably fits better as a new JSON spec instead of on-chain data. Let me think more about it and the multiple states. I'm a bit worried that over-complicating it will lead to less adoption and marketplaces ignoring the field altogether. |
Beta Was this translation helpful? Give feedback.
-
It doesn't fit directly into this discussion. I took a shot at getting it out in front of the team. :) Where could I propose an update to the JSON spec? |
Beta Was this translation helpful? Give feedback.
-
|
I think discussing it here is fine, tbh, as we can roll out any updates to the JSON spec in v1.3 by updating docs, tweeting, etc. |
Beta Was this translation helpful? Give feedback.
-
|
I've been working on an initial implementation because I find coding up things helps me think through edge cases and discover things that work or don't work well together but it's not set in stone yet. I'll be working on it a bit this weekend and should have an update on Monday with some more thoughts. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for the delayed update. I have an initial implementation for v1.3 coded up now. Here's an overview of the changes in v1.3: Burn NFTThere's now a Burn NFT handler that allows the owner of the NFT to completely burn it:
This handler checks if the NFT is a member of a verified collection, and if it is, requires the collection metadata account be passed in so the size can be decremented. Concerns:
Verify, Unverify and SetAndVerify V2sThese three handlers now require the collection metadata account passed in mutably so they can modify the Concerns:
Create Metadata V3This handler needs a new version because it needs an additional argument Set Collection StatusThis handler allows the collection authority to set the status of the collection. Set Collection SizeThis one is tricky as allowing the collection authority to change the collection size can lead to them putting in incorrect size values, but we need some way of back-filling existing collections with the correct size. Currently, I wrote this handler to require a Metaplex signer key but will be changing it to use the delegated model that set_and_verify uses so that collections can delegate authority to a Mteaplex tool which will user an indexer to find and set the correct collection size. Concerns:
Set Token StandardThis handler allows an update authority to pass in a metadata account with an optional edition account and then it determines what the correct TokenStandard type is and writes it to the metadata. Concerns:
Metadata ChangesAs described in the original post a new field has been added to the Metadata struct. I've renamed it from the original Current Metadata struct: CollectionDetails enum: CollectionStatus enum: I implemented @statikdev's change to turn the
JSON StandardsI'd like to use v1.3 as an opportunity to clarify and modify the current JSON standards a bit. I really like @statikdev's suggestion for Collection Parent NFTs to have their own JSON standard to differentiate them from Collection Item NFTs. In addition, I want to remove as much redundancy from the normal NFT JSON spec as possible. I'll be exploring this later today and tomorrow and will update this post with some thoughts. |
Beta Was this translation helpful? Give feedback.
-
|
Only Collection Parent NFTs will have the |
Beta Was this translation helpful? Give feedback.
-
|
@kevinfaveri good points regarding complexity and adoption, thanks for weighing in. I'm thinking you're right about keeping it a simple |
Beta Was this translation helpful? Give feedback.
-
|
would it be useful to keep it as |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
It was always our goal to have explicit JSOn standards represented as JSON schema, in fact 2.0 is built on them at a core level |
Beta Was this translation helpful? Give feedback.
-
|
Identifying collection NFTs is definitely a problem for us. Glad to see it's being addressed!
|
Beta Was this translation helpful? Give feedback.
-
|
Disregard. I wasn't thinking through the whole workflow. |
Beta Was this translation helpful? Give feedback.
-
|
@montasaurus thanks for weighing in, I appreciate you engaging with this.
Do you mean out-of-sync on-chain or only with your indexer? I believe my design has covered all they ways it could get out-of-sync on-chain but if I'm missing something let me know.
This is a good point and as I've thought about it I've come to similar conclusions. It seems this should be either a simple bool
It seems to be a pretty big issue for the creators who projects get killed by it but I'm not sure if there's analogs on other chains. Given it's an on-chain signal and not enforced via the protocol, it seems to be a nice attribute for creators without much downside.
This is my biggest concern with this handler, agreed. Can you elaborate what you mean by "configurable on the collection level"?
All of these changes would be a lot, lot easier without supporting collection sizes but it's a pretty important thing to support DAO governance. |
Beta Was this translation helpful? Give feedback.
-
|
For the Burn handler, I'm wondering if maybe having it create a PDA record that the NFT existed would resolve the concerns about indexing and having an archive of former NFTs. It needs more thought, but a single account with limited data (NFT's mint account?) would still be a significant cost-saving over having four accounts representing an NFT.
Another thing to note here is that update authority of NFTs can, and do, already do this in some situations. While they can't delete the metadata account, they can erase all the metadata by setting it to default or blank values. This includes the link to the external image and traits. For the handler as it's written currently, only the actual owner of the NFT, the token account owner of the only token allocated to the specific mint, can burn it. |
Beta Was this translation helpful? Give feedback.
-
|
@montasaurus would love more clarification on your idea as per sams comment indeed my draft response to you wasn almost the exact same thing. |
Beta Was this translation helpful? Give feedback.
-
While I agree at a data level our current standard is too coupled to how the thing is sold, this is not something we can fix in a backward compatible way until 2.0 is available. |
Beta Was this translation helpful? Give feedback.
-
|
Hey Sam, thanks for documenting these changes! Here are my thoughts on them and on some of the responses.
|
Beta Was this translation helpful? Give feedback.
-
Once the burn handler is implemented and deployed we'll start losing access to the information as NFTs are burned so the optimal time to implement it will be at the same time, but it's probably too much to add to this version.
The first thing to note is that Rust functions don't actually allow optional parameters. The closest you can get without macros or maybe some fancy generic types, is using an This is doable but I'm not sure how much it actually simplifies the user experience over a v2 handler // Optional accounts logic
let mut using_delegated_collection_authority = false;
let mut using_mutable_collection_metadata = false;
// Both optional accounts present.
if accounts.len() == 9 {
using_delegated_collection_authority = true;
using_mutable_collection_metadata = true;
}
// Single optional account present.
if accounts.len() == 8 {
// If the account is mutable it's the collection account;
// otherwise it's the authority record.
// We're lucky here that one of the optional accounts is mutable and the other one
// isn't.
if accounts[7].is_writable {
using_mutable_collection_metadata = true;
} else {
using_delegated_collection_authority = true;
}
}
// Get the mutable optional account or use the current one.
let collection_info = if using_mutable_collection_metadata {
next_account_info(account_info_iter)?
} else {
collection_info
};
// We still have to check if the NFT is actually a parent collection or not and add more logic down here to increment the collection size only if it is, otherwise it should fail.Given this, I wonder if maybe keeping a second verify collection handler is better but naming it more descriptively, e.g.
Accepting a subset of Here's an excerpt from the data: MetadataInstruction::CreateMetadataAccountV2(CreateMetadataAccountArgsV2 {
data: DataV2 {
name,
symbol,
uri,
seller_fee_basis_points,
creators,
collection,
uses,
},
is_mutable,
})
.try_to_vec()
.unwrap(),It takes the pub fn process_instruction<'a>(
program_id: &'a Pubkey,
accounts: &'a [AccountInfo<'a>],
input: &[u8],
) -> ProgramResult {
let instruction = MetadataInstruction::try_from_slice(input)?;
. . .This deserializes the bytes into the specific /// Deserialize this instance from a slice of bytes.
fn try_from_slice(v: &[u8]) -> Result<Self> {
let mut v_mut = v;
let result = Self::deserialize(&mut v_mut)?;
if !v_mut.is_empty() {
return Err(Error::new(ErrorKind::InvalidData, ERROR_NOT_ALL_BYTES_READ));
}
Ok(result)
}so if we add an extra field to the DataV2 struct, the on-chain handler will change to expect these extra bytes and will fail all calls by users using the v1.2 version of There may be a way around this by writing a custom version of
You effectively can, but not automatically. You will have to find out the correct size externally, via an indexer, for example and then call this function with that number. |
Beta Was this translation helpful? Give feedback.
-
This is correct, but not just NFTs, any metadata account created prior to
This is a really clever idea and I think it will close this loophole, thanks!
Good call. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your reply! Lemme go through these points real quick.
|
Beta Was this translation helpful? Give feedback.
-
I do agree with the sentiment of @lorisleiva. As a disclaimer, maybe I'm missing the mechanics of how the handler will work, but in my opinion if you have a bool to tell you whether to populate another field you have essentially created your own For example Solana geyser plugin does something similar with ReplicaAccountInfoVersions used here. |
Beta Was this translation helpful? Give feedback.
-
|
I'm still writing some tests and crossing t's, etc. but the code is now up for review and final design discussions: #459. |
Beta Was this translation helpful? Give feedback.
-
Executive Summary
We are proposing a minor update to the Metaplex Token Metadata (v1.2 → v1.3) that adds a new field which allows:
tradeableflag that lets creators signal to exchanges whether or not the Collection is ready to be listedThis requires some minor updates to tooling but solves real problems in the community and makes the Metaplex Certified Collection standard more rigorous and useful.
Terminology
This is how the terms are used in this document. Names may change for the final specification.
Collection Item NFT
A NFT belonging to a Metaplex Certified Collection. This is an NFT with a Collection struct that has a key pointing to a Collection Parent NFT
Collection Parent NFT
The NFT that represents a collection. It is the parent of all the Collection Items and stores the collection name, cover art, collection description. Under this proposal it will have a
ItemDetailsenum populated to differentiate it from Collection Item NFTs or non-collection NFTs.Overview and Problem Statement
The current Metaplex Certified Collections (MCC) standard has several issues causing difficulties and confusion in the community and doesn’t support on-going DAO work. To rectify these issues we are proposing a minor update to the Metaplex Token Metadata Standard going from v1.2 → v1.3.
The first issue is that there’s no on-chain method for determining when a collection is complete and/or ready for listing. Collections that are in the process of being minted from a candy machine or other similar tool can have the project badly hurt if people list NFTs below mint price, collapsing the incentives for new people to mint from the candy machine. For this reason, and others, many creators wish to wait to list NFTs from their collection until the mint has been exhausted or closed down.
There is currently no standard that everyone in the community follows. Some marketplaces allow listing any Collection Item as long as it has a verified collection in its collection metadata. Others work closely with specific creators to determine when collection items should be listed. In order to propagate adoption of the MCC standard as widely as possible it has been suggested we add a
tradeableflag that allows Collection creators to signal to marketplaces/exchanges their desire for when to allow items to be listed.Related to this, there is no objective way to know if a NFT is a Collection Parent NFT, a Collection Item NFT, or a standard NFT without making some assumptions and performing queries. Given any specific NFT with no collection id, there’s no way to know if it is a Collection Parent NFT or just a standard NFT that is not affiliated with a collection in any way.
The second issue is there is no on-chain way to know the size of any given collection without performing expensive and complicated querying. This impacts on-going DAO work specifically, but is also a useful feature to have in general.
From Sebastian at Solana Labs:
DAOs use NFTs to control treasuries and over on-chain assets. In order to approve any transaction for DAO wallets a predefined approval quorum must be reached. In order to accurately calculate the quorum we need the exact collection size to know what percent of certified NFTs from the collection approved or disapproved a given transaction.
In our current workaround we store the collection size in DAO config. It works for fully minted collections but it’s problematic for partial collections. The config must be separately updated via proposal and makes the DAO susceptible to governance attacks when additional NFTs could be minted and could make it easier to reach approval quorum. With millions of dollars managed via DAO treasuries it’s serious issue which can lead to lost funds and/or rug pulls.
Proposed Solution
Both of these issues can be solved by adding an additional field to the end of the
Metadatastruct in thetoken-metadataprogram. The current structwhere
Collectionis another struct:where
verifiedrepresents if it is a legitimate item in a collection andkeypoints to the mint address of the NFT that is the Collection Parent NFT that the item belongs to.The proposed addition:
where a
Nonevariant indicates that item is not a Parent Collection NFT and theCollectionInfovariant indicates that it is. Thetradeableflag indicates whether the collection authority wishes for items within it to be listed (e.g. if the mint is not finished the authority can leave itfalseuntil all items have been minted or the mint is closed down), and thesizefield tracks the total amount of verified NFTs in the collection, excluding the collection root NFT. Making this an enum allows the possibility of adding additional variants in the future without having to add a new field.This change allows:
sizefield (nested collections will require reading each collection NFT’ssizefield and summing the values)This is not enforceable on-chain through Metaplex contracts in the same way that royalty fees through
seller_basis_fee_pointsand creatorsharesare not enforceable, but it can become a social norm just like these fields which are respected by virtually all current NFT marketplaces.At the same time, this does not prevent marketplaces from accepting listings, nor users from submitting them with the
tradeableflag for a collection set tofalse, so does not take any real control away from the actual owners of the NFTs. However, it starts propagating better social norms that should improve the standard and enhance the Creators’ experience with it.Implementation
To implement this update the following changes will need to be made:
Metadata
The
Metadatastruct will have theItemDetailsenum added at the end consuming some of the remaining 118 bytes of padding remaining on the struct. This will require updating our custommeta_deserfunction to handle this extra field. To allow setting this data in a backwards compatible manner, we can create a new handler that specifically allows setting thetradeableflag. To give exchanges more assurance about the stability of this signal it’s probably best to allow it to be flippedtrueonce and then is locked.Size Tracking
To track the number of verified NFTs in a collection we will need to add logic in three of our collection-related handlers:
verify_collection,set_and_verify_collection, andunverify_collection. The twoverifyhandlers will need to increment thesizefield every time they are successfully called on a given collection item and theunverifyhandler will decrement the number. In addition, the soon-to-be-implementedburnhandler, which allows closing a metadata account, will need to decrement thesizefield. This will require the user to pass in the collection NFT metadata account if the item is part of a collection. Any future handlers that close a Metadata account or verify or unverify a collection item will also needsizetracking logic.Since all of these handlers already receive the collection metadata account as part of their API it requires only a logic change in these functions to handle size tracking.
Beta Was this translation helpful? Give feedback.
All reactions