ICRC-21+ (or 22)

Tokenization
1

Standarized metadata fields would be very useful in the ICRC-21 format probably as Front Matter fields or Markdown comments. Fields that can be processed by the wallet to obtain information that is important from its point of view. Or a completly new format ICRC-22 for example with xml or json, but why 2 requests.

Why do we need it?

I would like to add NFT to my Grind Wallet and have it registered there immediately. So i need to fetch collection ID and NFT ID somehow.
DAB registry is a great idea but people just don’t use it, I never bought an NFT registered in DAB in my life.
I want to make a mobile version of my wallet which (I hope) in the future will be used for ordinary payments. I think we all see a world in 5 years where the parking fee is paid in ICP and as confirmation we get the NFT. How long would it take to register such NFT in DAB, and why? and who will pay for maintaining these databases? and how fast will the search take, perhaps among hundreds of trilions of records?

What kind of fields are necessary?

  • link to images: ICRC-21 format states that there should be no links to images - I think that from the user experience point of view they are very necessary, we can present the product we are buying
  • NFT collection canisterID
  • NFT ID
  • a detailed breakdown of the basic price, what fees each organization charges
  • category: when I buy a parking ticket or get a receipt at a store, I want them to automatically go to their folder and not be mixed with expensive NFTs bought as an investment
  • and more…

Example of casual transaction with price list not as free text but as standardized fields:

┌─────────────────────────────────┐
│  Approve the following action?  │
│  ┌───────────────────────────┐  │
│  │         Buy Lambo         │  │
│  │ ┌───────────────────────┐ │  │
│  │ |                       | │  │
│  │ |   Picture of Lambo    | │  │
│  │ |                       | │  │
│  │ |                       | │  │
│  │ └───────────────────────┘ │  │
│  │  Descrtipion of equipment │  │
│  │  Descrtipion of equipment │  │
│  │  Descrtipion of equipment │  │
│  └───────────────────────────┘  │
|   Price: 36,460.00 ICP.      │  │
|   Dealer Fee: 1000.00 ICP.   │  │
|   IC Fee: 0.0001 ICP.        │  │
|   Wallet Fee: 0.0001 ICP.    │  │
|   TOTAL : 37460.0002         │  │
│  ┌───────────┐   ┌───────────┐  │
│  │  Reject   │   │  Approve  │  │
│  └───────────┘   └───────────┘  │
└─────────────────────────────────┘
2

A similar idea was raised in the Identity & Wallet Standards WG previously: [Draft] [ICRC X] Content type for consent message by baolongt · Pull Request #215 · dfinity/wg-identity-authentication · GitHub

I’d suggest to read this thread first for some context around ICRC-21.

As I mentioned there, the purpose of ICRC-21 is to return a human readable representation of a canister call. The main purpose of the standard is to avoid the need for the wallet to have any required knowledge to interpret the data before it’s able to display it to the user.

So in practice the standard is specifically uses for displaying a consent message to a user in case the canister call is not standardized. For example, some wallets will not use the ICRC-21 standard when the canister call is a ICRC-1 transfer since it instead has implemented a custom UI for token transfer confirmations.

As for the image restriction, this is to avoid two issue if I remember correctly:

  • image cannot be loaded since air gapped wallet does not have an internet connection.
  • image could technically change after a consent message was created.

This doesn’t mean images aren’t allowed, you could still put a non external image in the markdown like e.g. a base64 data URI.

As for enabling wallets to detect NFT purchases and display a custom UI instead of markdown, maybe standardizing the purchase canister call itself in an ICRC standard could be a viable approach?

Also as a marketplace in this particular example, I’d either:

  • use allowances and delegations to avoid the need for a wallet prompt (show confirm UI within marketplace itself)
  • show a detailed purchase screen within the marketplace and a less detailed confirmation ICRC-21 message in the wallet.

As for the other topic, I read between the lines, metadata that the wallet can use to categorize, show, details etc NFTs seems like separate issues:

1 Like
3

Thank you for your answer, I will read these docs and think about next step.

4

canister methods in the NFT canister to get collection metadata → see ICRC-7 and ICRC-97, for non ICRC tokens you’d have to implement something custom

But marketplace canister could follow the ICRC standards - wallet should fetch info from them, it doesn’t matter whether they sell EXT or DIP.

5

Ideally marketplaces should also be able to fetch collection details from the NFT canister.

Storing collection metadata in the marketplaces instead of NFT canisters would unnecessarily put the trust and maintenance of this data with the marketplace. You’d expect a marketplace to instead focus on keeping track of listings, prices, offers etc.

6

In general I’m considering this metadata as call-agnostic. Not as separate canister call like icrc_21_fetch_metadata() but attachable to anything. Well, maybe not anything, but:

Can be fetched in many scenarios:

  1. during purchase (as described above) so its outgoing request
  2. during push message - so it’s incoming message, I’m planning to make own web2/WebSockets messaging system about receiving something from my ecosystem “Hey someone just sent you something”
  3. scrapped from current users site, as static info emedded in the html, without any middleman marketplace for self-selling NFT’s. People can just make post on Facebook “hey who wants to buy this NFT?”. Wallet will scrap info about canister ID and NFT ID display info and will enable purchase.
  4. called as params from site javacript implementing wallet interface