The NFT standards ICRC-7 and ICRC-37 are now considered ready by the WG for an NNS vote. ICRC-7 is the base NFT standard, while ICRC-37 defines the approve / transfer_from functionality.
Before initiating the vote, we would like to give the community and WG members the opportunity to have a final look at the proposal.
This seems very exciting. I am not very technical but from what I am grasping is that this will allow you to be able to see transfers of nfts as well as do batch tx of nfts such as transfers and listings.
If I am wrong I am sorry haha. But thank everyone who worked hard to get this done. Super exciting for ICP nfts moving forward.
Long awaited indeed! Glad the migration from EXT is covered, at least partially.
Quick question: Can ICRC-3 handle NFT transaction data as it does with fungible tokens, or do we need another standard? I ask because, without a unified standard, each new project tends to reinvent the wheel, bringing its own bugs and nuances. This has been a problem for memecoins, which can’t be added to explorers like 221bravo or nftgeek due to their unique, often buggy transaction storage methods.
ICRC-3 can handle it, both ICRC-7 and its extension ICRC-37 describe the ICRC-3 blocks that must be implemented for e.g. a transfer or transfer from.
As @sea-snake mentioned above, ICRC-3 can handle NFT transactions. To give you some more information: ICRC-3 is a rather generic standard for keeping any kind of log in the form of a chain of blocks. It defines the basic structure of an ICRC-3 block. A standard that wants to be use ICRC-3 can, like ICRC-7 and ICRC-37 did, define its own ICRC-3 extension schema that defines the concrete shape of the blocks (i.e., the fields to be stored and the structure) for the kinds of transactions to be handled with ICRC-3. For example, ICRC-3 can be used to store the history of actions that happened in any canister to keep an untamperable log of things.
I have a couple of points:
While the standard defines a metadata field icrc7:atomic_batch_transfers which is of bool type, it doesn’t specify how to encode the bool and float type in the generic Value type. This makes it confusing to implement.
The namespace idea for the metadata seems nice, but it might be scary to have each marketplace have their own namespace for any additional stuff.
Good point! This specification does not fit well into ICRC-7 as it relates to the Value type and associated best practices / standards is useful for a much wider audience. Thus, we decided to defer this to best practices emerging in the ICRC-3 area. However, those are not there yet as you rightfully imply. We’ll discuss this in the upcoming WG meeting.
The idea here is to quickly come up with a standard that unifies the approach on how the core metadata related to marketplaces is handled. This is currently being actively discussed on Discord: ICP Developer Community
Sorry for the late comment as I’ve been implementing ICRC-3… but I’m satisfied with ICRC-7.
I think the WG agreed back then that batch transfers should always be atomic.
but regarding Bool value, cant we do it to be multiple optional types?
such as 1: Nat, "true": Text, [1]: Blob to represent true…
and 0: Nat, "false": Text, [0]: Blob (or anything that is not true) to represent false?
so the devs can implement like a utility function to check for boolean Value like this
(i prefer to store it as Blob as u can make it to be only 1 byte)
Great to hear you are working on ICRC-3 and are happy with ICRC-7. 
Just as a note: Batch transfers are not atomic, i.e., each transfer in a batch is an individual transfer and can fail or succeed independently of other transfers.
Yes, this works, I think the main problem is that it would be great to have a standard or at least a best practice on how to encode types not native to Value. We should evolve some best practices or standards in the context of ICRC-3 for this purpose. What do you think!
Oh I see, thanks for the correction. I should re-read the ICRC-7 standard again.
Yes I think we should, as more devs will have this kind of issue later on.
after re-reading the draft, I’m happy with everything, but may I know why “from” on the Mint block schema and “to” on the Burn block schema are “MUST” instead of “MAY”? I’m asking because icrc1’s Mint block schema dont have “from” and Burn block schema dont have “to”.
also, on “37_appr” and “37_appr_coll”, perhaps we can rename these to “37approve” and “37approve_coll” to appear standardized to the current “2approve”, “37revoke” and “37revoke_coll”. Sorry for this extremely late comment.
Excellent!
The from in the mint schema in ICRC-7 has a MAY, and the to in the burn schema has a MAY as well. Therefore it is aligned with ICRC-1 unless I overlooked something.
Did you look at the right version? The current version is in the branch icrc_7_and_37 in the following link: ICRC/ICRCs/ICRC-7/ICRC-7.md at icrc_7_and_37 · dfinity/ICRC · GitHub
That’s a good point in the light of consistency.
For reference, here is the ICRC-3 spec for icrc2_approve.
I am fine with changing this in order to make it more consistent, however, we need the main contributors to agree to this.
@kayicp, @sea-snake, @skilesare, @benji
Please let me know as soon as possible whether you agree, than I change it. The draft is close to be submitted to the NNS.
No, you’re the right one. I’m sorry, my mistake. 
@kayicp Uhm I think this has already been fixed in the branch @dieter.sommer mentioned.
Though apparently even I was looking at the wrong branch 