FA2.1 / FA3 - It's time

[mpsp]

Yeah, I was thinking there would be a ticket wrapper deployed by the owner of the token contract. The main difference is that you could use the token without worrying about the tickets at all, and if there is a ticket related problem it (hopefully) only affects ticket users.

[Britcoin]

Please lets dont start messing around with a ticket wrapper, the proposed solution is perfectly fine

The ticket holds the address of the contract that created it so it’s easy to check if the ticket is valid or not.

[tom]

I agree. It’s not clear why the costs and risks associated with the ticket design should be inflicted on all “FA2.1” contracts, when essentially equivalent functionality can be obtained using separate ticket bridge contracts. (Right?)

Edit: I just realised that this:

@Britcoin

The ticket holds the address of the contract that created it so it’s easy to check if the ticket is valid or not.

is an argument for the ticket design?

(I won’t say whether I am convinced or not, but at least there is something there.)

[Charles_Dehlinger]

The use of a bridge contract has the effect of significantly increasing the size of tickets and consequently increasing their size on the chain as well as the cost of storing the smart-contracts which are intended to store these tickets.
For this reason, we thought it more appropriate to implement it directly in the standard.

[Jordan]

I’ve added remarks on the FA2.1 proposal and originated 2 contracts for you to interact with:

FA2.1 as extension of the FA2 standard - DRAFT

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 ap…

[rafoo]

The main advantage of ticket wrapping is that it does not require a standard change; we can wrap FA1.2 and FA2 tokens as tickets today and this is what Tzportal already does. You could become compatible with ticket wrapping without adding much data by changing ticket (pair nat (option bytes)) into ticket (pair (option address) nat (option bytes)) where the option address defaults to the ticketer (so it is light when the token contract does it’s own ticket wrapping because it can put None and it is heavier for generic ticket wrappers like Tzportal but they need to store the token contract address somewhere anyway).

[Charles_Dehlinger]

The standard change was required anyway because of other features that can not be wrapped, such as the replacement of callback views by on-chain views (notably for reasons of gas cost reduction).

You will notice that we are already compatible with wrapping, just put the address in the serialized data in the (option bytes).
It is also possible to not need the address by doing dedicated wrapping.

[rafoo]

Or, yet another solution avoiding the introduction of option addresses: keep a generic wrapper contract and let it manage a mapping between (token contract addresses + ids) and its own ids. Such a wrapper contract could even follow the FA2.1 standard (extended by wrapping and unwrapping entrypoints).