FA2.1 / FA3 - It's time

I think it’s time we have an open thread, collecting everything from developers in terms of needs and gripes regarding the current FA2 standard to devise a FA2.1 or FA3 token standard for Tezos because:

  • Views open up a lot of possibilities
  • There are many platforms that have need for royalties
  • We need to expand on allowances enabling flash-loans, subscription models
  • How can we best standardise integration with tickets?
  • State-channel / ZK-rollups / Optimistic Rollups - anything needed to be taken into account
  • Upgradeability / Forking / Upgrade paths
  • Global Table Of Constants - let’s find a way to maximize the space-saving enabled by this

Thoughts, ideas, requests are all welcome


Might also be a an occasion to:

  1. Integrate tzip-17 into it (and fix it, tzip-17 is currently not very useful because it requires all transactions to lock on a global counter for the contract).

  2. Clean up this all operator affair. FWIW I still don’t understand it.

  3. Maybe reintroduce finite allowances? Ctez uses FA1.2 because it needs a type of functionality that requires finite allowances (or maybe it could use operators, but I don’t know because I still don’t understand them :man_shrugging:).

  4. Standardize use of tickets attached to an FA contract.


Hi ,

Can Non-Transferable Token functionality be added to the new standard as it is not supported by the current FA2 standard natively?


Should the privacy features also require integration in the standard ? (I am no dev, could be a non relevant comment)

Supply metrics are also a mess in current tokens and thats because here is no spec for it so every contract does it differently. This should be standardized imo

1 Like

Maybe a Token Governance standard for Upgradeability / Forking / Upgrade paths…

It is time to add a transfer_and_call mecanism.

It would simplify things by a lot, open new possibilities and remove security problems encountered with operators.

I agree with @murbard that we should consider moving back to finite allowance or even remove allowance mechanism thanks to transfer_and_call.

On January 7, I made a proposal about using tickets as bank check for FA tokens.

The idea is that you can emit a ticket that can be cashed anytime on the target FA contract.

It differs from the idea of tickets representing the token. It’s only a right to cash it.

A typical transaction scenario is:

  1. Alice crafts one fa3 check with fa3_dest dest = KT1…, amount = 20, to = B. token_id = 0.

  2. Alice sends the tickets to contract B.

  3. Contract B. performs the corresponding logic

  4. Contract B. transfers the ticket to the corresponding token contract (KT1…)

  5. Token contract validates the transfer

This would add one entry point: transfer_tickets.


(list %transfer_tickets
      (string tag)
      (address %fa3_target)
      (list %txs
          (nat %amount)
          (address %to_)
          (nat %token_id)

tag is always equals to fa3_check.

Each transfer in the batch is specified between one source: the ticket’s forger and a list of destination.

Each fa3_target specifies the address of the FA3 and the same info as in the regular transfer.

This adds a new possible error: FA3_WRONG_TARGET if the %fa3_target is not the same as the current FA3 address.

The %qty of tickets simply multiply the amount transferred.

Like in standard bank check we could add a %timeout LEVEL that indicates when the check cannot be cashed anymore.

1 Like

What are the security problems with operators and how does this mechanism mitigate them? I don’t have historical context on this problem and couldn’t find any discussion in the forum. Thanks!

It would be great to have something similar to EIP-2981.

1 Like

Yeah that would be great, if so it would be nice if it has support for multiple royalty receivers, ie, split royalties.

We need a token standard for token issuance on sidechains and layer2 protocols that are to be introduced.

Since most of the derivatives contracts have maturity periods, it would be great if we have a token standard for tokens with an expiry. ( So the burn will happen automatically on the expiry date/block thus preventing the accidental burning of tokens)

Wrangling metadata on-chain can be awkward with present standards and Michelson language features. Many NFT projects default to putting metadata on IPFS - makes sense if the NFT is signing a large JPEG that you’re storing on IPFS anyway, but makes less sense for things that can live on-chain like procedurally generated works (cf artblocks.io on Eth) - where introducing an IPFS dependency is undesirable.

One thing that I have struggled with building my contract, for example, is how to assemble JSON on chain. Currently I am basically preparing fragments of JSON off-chain and assembled a JSON string in the view from fragments with roll-your-own nat to string / address to string code.

This part of an NFT standard needs to be fully generatable in a view IMO - that means improved language support from Michelson for building JSON strings (see my post in Research and Development), or a move away from (nested) JSON structures as the metadata format.


Hi, there also needs to be a clear way to identify the kind of Token the contract is dealing with (Fungible, Not fungible, Hybrid, …).

We have had the issue in a recent project where an exchange contract needs to decide on which (fungible) side of the offer fees are taken. Since now everything is FA2 it is hard to decide.

It could be solved with a kind of “magic number” a bit similar to IEP165

1 Like

I have two suggestions:

1 - token standards on Tezos should be approached in a more modular fashion. FA is a beast right now, and if each iteration leads to more features, then FA4 or FA5 will be massive and impossible to maintain. Rather, these ideas should be built out in a modular fashion. For example: let’s say royalties is important, that should be a single focus, and it should not require a whole new FA version, but instead a set of functions that can be optionally attached to the base FA standard if the developer chooses. This is something I’ve been enjoying about ETH/Solidity.

2 - I feel royalties specifically are important, as Tezos has been a chain that is primarily NFT and art/creator centric compared to others that might be more about DeFi/games/etc. So I think it’s worth putting energy into solving royalties specifically, rather than trying to solve all the problems at once.

To solve royalties in a way that covers a wide range of uses, I would propose something similar to EIP2981, but providing multiple beneficiaries/splits. For example, royalties on each resale could be distributed to 5 different charities, each weighted differently. This should be on-chain, to facilitate on-chain splitting, rather than in metadata/JSON.

An example of how it could look, but in Sol:

And like rognierbenoit suggests, there should be a simple way for contracts to detect whether a token supports this interface.

I think a good first step would be to define a simple example of how this would look in a token, and show how a marketplace (like alternative to HEN Marketplace contract) could take advantage of it, rather than relying on their own royalty stores.