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

12 Likes

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.

9 Likes

Hi ,

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

3 Likes

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.

transfer_tickets

(list %transfer_tickets
  (ticket
    (pair
      (string tag)
      (address %fa3_target)
      (list %txs
        (pair
          (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.