FA2.1 as extension of the FA2 standard - DRAFT

Research and Development
1

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.

7 Likes
2

This is amazing work, I will look through it!

3 Likes
3

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"
}
3 Likes
4

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

1 Like
5

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.

1 Like
6

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

2 Likes
8

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

9

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

1 Like
10

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
11

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
12

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

1 Like
13

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.

1 Like
14

Whats the status on this right now?

1 Like
15

FA 2.1 work in progress - implementation in all three SC languages

Would be great to know some general update about the status

16

In the gitlab merge request there is no new update:

I love the idea to talk about current standards and future ones on Tezos on Blockchain Evolved show. Lets get this rolling @JarrodWoodard :slight_smile: Afaik @Jordan was interested to talk?

2 Likes
17

We have updated the draft trying to answer feedback. Here’s what’s changed:

  • Backward compatibility enforced, no more optional entrypoints
  • New views (from FA2 off chain views): get_all_tokens, is_operator, get_token_metadata and get_allowance
  • New event: token_metadata_update
  • New semantic of the Approve entrypoint to avoid known ERC20 vulnerabilities: one can only increase or decrease the allowance
  • Explicit error handling
  • Implementation warnings: reuse of the ticket type, priority between operator and spender, transfer of 0 amount from someone else without allowance, self-transfer, no fail in a view, …
4 Likes
18

The standard still says that the definition of an NFT means no more than 1 total supply of a given token_id. Again, this is incompatible with a great many NFT projects already. This is wrong and should not be enforced

3 Likes
19

This field is an anticipated response to potential regulations affecting fungible and non-fungible tokens differently. In this case, we need a way to distinguish the two unambiguously.

20

What happens to “semi-fungible” NFT’s in this setup? Semi fungible should not be classified as fungible tokens, they are far closer to NFTs in semantic meaning than fungible tokens

2 Likes
21

I’ve removed the metadata part, TZIP21 should be enough to distinguish between token types in regard to future regulation.

1 Like