FA2.1 as extension of the FA2 standard - DRAFT

Hello everyone, @LucasF with Charles Dehlinger have drafted a first version of an update to the FA2 standard including views, tickets, events and approvals à la FA1.2 while remaining backward compatible:

Feel free to comment here or on HackMD if you have questions or feedback!

This is the previous community discussion about what a new standard should include:

Now that there is a first draft with spec I believe its good to keep the draft discussion in a separate thread to not mix it up.

5 Likes

This is amazing work, I will look through it!

2 Likes

Token metadata

Following the token metadata specification as described by the FA2 standard, a new field is reserved and predefined:

  • "type" : should be a UTF-8 string describing the type of the token (e.g. Fungible, Non-Fungible, …).

At a minimum i’d like to see 3 types “fungible”, “non-fungible”, and “liquidity”. A liquidity token has a vastly different meaning to a fungible token, and end-users expect to have additional functionality/details displayed about them


Contract metadata

Following the TZIP-16 about smart contract metadata, a new field is reserved but optional:

  • "NFT only" (optional, default: false): if the contract manages only NFTs, this flag SHOULD be set to true then the contract MUST NOT allow a total supply greater than 1 for any token_id .

Why should an NFT contract not be permitted to have more than 1 of a given <address>:<token-id>? Pixel Potus and Mooncakes are two examples of NFT projects where duplicates of each <address>:<token-id> are required. These projects have aspects of burning or combining duplicates to create higher rarities. Having more than 1 is critical for any type of NFT based game


The metadata standard in general also doesn’t reflect how projects are actually using it. Again for games, projects are attaching arrays of dictionaries to denote attributes of the NFT that are useful to the project, as oppose to denoting the version or license. Examples:

  • Trading card games attach lists of powers / abilities for each card
  • Mooncakes attaches attributes like color, rarity etc

Having these types of attributes in the metadata, means they can be indexed and searchable, instead of having to go to a specialist website to see what stats each one has. These types of attributes could do with some standardisation too, as there are several different formats being used to represent the same types of data. For example, recording an attribute of “color” with a value of “blue” can be seen in these formats across different projects

  • Key / value:
{
   "key": "color",
   "value": "blue"
}
  • Name / value:
{
   "name": "color",
   "value": "blue"
}
  • No defined keys:
{
    "color": "blue"
}
2 Likes

Its great to see a draft finally. I hope progress will be made to see it soon integrated

Blockquote
At a minimum i’d like to see 3 types “fungible”, “non-fungible”, and “liquidity”. A liquidity token has a vastly different meaning to a fungible token, and end-users expect to have additional functionality/details displayed about them

Should we impose a limited set of types or let the users be free to choose? Because I can see more types, like “governance token”, “fractionalized NFT”, “semi-fungible”, …

Blockquote
Why should an NFT contract not be permitted to have more than 1 of a given <address>:<token-id>?

To me that’s the definition of an NFT, to have only one copy. One of the purposes of this flag is to provide a clear distinction in case the regulation evolves resulting in a different regulation between fungible tokens and NFTs.

Should we impose a limited set of types or let the users be free to choose? Because I can see more types, like “governance token”, “fractionalized NFT”, “semi-fungible”, …

There should be a process to add more, but I wouldn’t make it free form. What would happen if it was free form, is project creators will just add dozens of different terminology that mean the same thing, forcing indexers to group them, e.g.

  • fractionalized NFT
  • sliced NFT
  • divided NFT
  • multipart NFT
  • etc

There should probably be a separate document that lists the types, so that it can be updated without having to release a new standard for every type of token.

To me that’s the definition of an NFT, to have only one copy. One of the purposes of this flag is to provide a clear distinction in case the regulation evolves resulting in a different regulation between fungible tokens and NFTs.

I wouldn’t agree with that at all. The point of NFT’s was to tokenise an artifact of some kind. In the real world we have unique things (e.g. an address, post code, car registration) that would require an NFT contract that ensures only 1 of each. But we also have real life things where the whole point of their existence is to have clones and duplicates (e.g. pokemon trading cards). Why would an NFT standard, which was defined in part to tokenise real world objects, be restricted to not allow objects that aren’t unique?

Having more than one of <address>:<token-id> is how trading card games already work on Tezos (Pixel Potus, Emergents, Mooncakes etc). Objkt.com is already built around the idea of having more than one of each. I would expect Ubisoft’s efforts to tokenise in-game weapons / cosmetics would be the same as well. I see no reason why such a restriction would need to be put in place. It would also cause lots of issues with existing projects

1 Like

This I agree with fully, semi-fungible “NFTs” is more common than 1/1s on Tezos, by FAR

Annoyingly, NFT has come to mean something else than non-fungible-token, it seems the definition has become: “Tokenized digital artwork”

1 Like

At SmartPy we’ve read the proposal and wrote a contract with some tests that implements it.

The contract is here: FA2_nft_minimal.py.

I encourage people to read it if they want to understand how the standard is supposed to work. Please tell us if there is any mistake.

Our remarks are:

  • Overall it’s a good and interesting proposal.
  • We are waiting for the merge of the TZIP proposal.
  • The approve entrypoint explanations need to be a bit more explicit:
    • Indicate that the transfer fails if the approve falls under zero.

    • Explicit the error message. We have 3 suggestions:

      1. Keep "FA2_NOT_OPERATOR" to be fully compatible with FA2
      2. "FA2_INSUFFICIENT_ALLOWANCE"
      3. Mix 1) and 2) and fails with a pair of "FA2_NOT_OPERATOR" and "FA2_INSUFFICIENT_ALLOWANCE". We can even give the allowance in the error message.
    • Clarify what to do if the allowance equals 0 with a transfer of 0 tokens?
      I suggest to pass because it permits to test the allowance system.
      To be clear, a transfer of 0 tokens with:

      1. no allowance => fail (so the system remains compatible with FA2)
      2. allowance of 0 => pass

      In this case the allowance should not be removed if a transfer, and export_ticket or anything that reduces the allowance to zero. It must be zero.
      We are open to alternatives.

1 Like

I originated two contract on Ghostnet to test this:

FA2.1: KT1XBN9g..Str6PC on ghostnet.tzkt.io
Ticket ledger: KT1FvAYt..RTCa85 on ghostnet.tzkt.io
The second one can be used to interact with the export_ticket and import_ticket.

1 Like

What does the FA1.2 standard dictates in this case?

Good question.

The answer is:

The transaction sender MUST be previously authorized to transfer at least the requested number of tokens from the "from" account using the approve entrypoint.

The way I understand it is it’s equivalent to what I propose:
no allowance => fail
allowance of 0 => pass
By the way that’s how the FA1.2.py template is written in SmartPy.

FA1.2 is mush more clear about how the allowance system affects the transfer entrypoint.