FA2.1 / FA3 - It's time

Hello guys,
I’m joining the discussion late. There are some interesting points raised here.

A point that has not been addressed yet is the deprecation of FA1.2?. A quick look over the standard leads to believe that FA1.2 is for FT and FA2 is for NFT, leading dev to create new FA1.2 token which I think is bad. People should use exclusively FA2. However some people prefer the FA1.2 due to the possibility to delegate only part of their stack to an operator while in FA2, we always delegate all of our stacks.

To avoid people using FA1.2 we may want to add this in a future FA2.1.

The other point is that the callback entrypoint should be replaced with views. Interacting with “Michelson view entrypoints” or “callback entrypoint” leads to potential vulnerability due to reentrance issues and exposure of an entrypont for the callback, that could be call by an implicit account.
For this reason, I believe that we want to upgrade FA2 quickly before any other discussion about a new standard. Just for people to stop using this.
This would be FA2.1. There may be some compatibility issues between FA2.1 and FA2 due to this last change. Then we may want to call it FA3 to signal this.

However, I want this change to be integrated quickly and I belive everybody would agree that using views instead of callback is a better design. And I also agree that we want a new standard with the other mentioned functionalty. Thus if we call this token FA3, I believe views won’t be integrated quickly because the community will discuss about the integration on these new functionality.

To sum up, I lack experience to have a clear opinion on weither such token should be FA2.1 or FA3, as their is pros and cons with both naming. Your opinion on this would be appreciated.

2 Likes

Major issue for wallets at the minute is lack of standardisation around metadata. Wallet users want to do all kinds of searching, sorting, grouping, filtering etc of tokens and NFT’s. But to this day the main indexers still don’t have a means of even saying if a token is an NFT or not. Wallets have to relying on hacky code and exception lists, while indexers are putting hardcoded data into their databases to manually “fix” such issues. This is not sustainable and causes a lot of delays in certain projects becoming fully supported.

With multiple “types” of tokens now possible, we need a standardised way to denote what they are (e.g. “token”, “liquidity token”, “nft”).

We need standardised ways to name different things. Have a look at any ETH wallet, you will see NFT’s grouped into sections like “Rarible” with a raribale company logo next to it, that users can expand. These are all hardcoded in tezos apps because theres no easy way to fetch these things. Sometimes you will get lucky and find a project that does expose these things, but it can’t be relied on unless everyone does it.

When discussing standards, the top priority needs to be talking to the major indexers and the major wallets to see what they and their users need. Making a new standard/features is meaningless unless it can be integrated in the way users want to use it

4 Likes

You right @simonmcl . The goal of standardization is to make it easy for wallet and dex to access any token and get metadata on them. We should have it accessible on the contract. I am thinking we need a place for constant on a Michelson contract. To identify data easily but also have the guarantee that they won’t be overwritten

1 Like

I upvote it. It’s great. When will we submit a new FA standard? I think it’s time to do it. The fake on-chain view on FA2 is not acceptable. We need improve it now.

1 Like

I dont know the current status about a new Token standard. If it is actually work in progress or nothing yet just talk on Agora? @veqtor started this thread maybe he knows more

Please don’t ruin FAs with all this bloat. You all are not looking for new “FA” standards but for new NFT-supporting TZIPs. Which is fine. Put them in TZIPs, another “FA” will be a huge pain in the ass for current and future Tezos developers.

Having to support both FA1.2 and FA2 is already a pain. Adding another or even FA2.1 will be worse. FA2 is fine for simple tokens as it is, FA1.2 is essentially rekt imo and shouldn’t be used, but new apps still choose it because of loose and unclear messaging from top devs.

What you really want is new TZIP standards. Look at Uniswap for example, they still exclusively deal with simple ERC-20s. As a DEX developer, I agree and will likely never support any “financial assets” past FA2 unless I really have to. Financial assets should be as simple as possible to allow for more complex interaction in base layer protocols.

We should be pushing modular TZIPs that can be optionally implemented to extend FA2. Not FA2.1, not FA3, not FA++, or God-FA.

And reaaally what yall are looking for is field-level standardization for token_metadata. That’s what everyone is already set up to read, and how the wallet or exchange knows to load the token image, name, symbol, etc. We have first-class support for it. So why not just make what we have better via TZIP? Tezos needs a core, base-layer FA that doesn’t get remade every 2 years.

Tokens do not need to do everything, developers should be shrewd enough to actually design their tokens well and choose what TZIPs to implement instead of relying on copying whatever boilerplate FA is posted in OpenMinter’s github. Heavy amounts of hand-holding will lead to this conversation happening again and again whenever a new protocol-level feature comes out.

As I see it, FA2s do everything necessary to allow simple token transfers, exchanges, management, and metadata storing. My request is that we keep standards clear of optional features.

This has been stated multiple times in this very thread, and folks need to accept it to move this conversation forward.

3 Likes

I can agree to most things but like @KStasi wrote in the Madfish Blogpost, support of views should be introduced. I dont know if possible but keep current issued FA1.2 and FA2 tokens but introduce a FA3 standard and with the introduction mark the others or at least FA1.2 as deprecated to use?

Is there actually some development ongoing for FA3 besides this discussion here?

Hello!

There’s not much I’d really want from an FA2.1/3. Here’s a short list:

  • allowances (for fungible multi-tokens)
  • relaxing the constraints on storage layouts (to allow for some more storage efficient token contracts)
  • clearly defined onchain views, ideally compatible with the FA2 offchain views so no one who just went that route gets retconned.
1 Like

Unfortunately there is no standard way to separate nfts from fungible tokens right now when I make api calls to get all token. The only way to distinguish them is to use some heuristics, but they won’t be 100% accurate. I think something on token standard level to clearly separate this two would help many