# FA2.1 / FA3 - It's time
**URL:** https://forum.tezosagora.org/t/fa2-1-fa3-its-time/3704
**Category:** TZIP
**Created:** [September 25, 2021, 3:15pm UTC](https://forum.tezosagora.org/t/fa2-1-fa3-its-time/3704 "2021-09-25T15:15:07Z")
**Posts on this page:** 8
**Page:** 3
### Author:  [@mpsp](https://forum.tezosagora.org/u/mpsp)
#### Post date: [November 4, 2022, 4:08pm UTC](https://forum.tezosagora.org/t/fa2-1-fa3-its-time/3704/41 "2022-11-04T16:08:37Z")
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.
---
### Author:  [@Britcoin](https://forum.tezosagora.org/u/Britcoin)
#### Post date: [November 8, 2022, 4:02pm UTC](https://forum.tezosagora.org/t/fa2-1-fa3-its-time/3704/42 "2022-11-08T16:02:57Z")
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._
---
### Author:  [@tom](https://forum.tezosagora.org/u/tom)
#### Post date: [November 15, 2022, 8:38pm UTC](https://forum.tezosagora.org/t/fa2-1-fa3-its-time/3704/43 "2022-11-15T20:38:32Z")
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.)
---
### Author:  [@Charles\_Dehlinger](https://forum.tezosagora.org/u/Charles_Dehlinger)
#### Post date: [November 17, 2022, 9:17pm UTC](https://forum.tezosagora.org/t/fa2-1-fa3-its-time/3704/44 "2022-11-17T21:17:02Z")
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.
---
### Author:  [@Jordan](https://forum.tezosagora.org/u/Jordan)
#### Post date: [November 18, 2022, 10:57am UTC](https://forum.tezosagora.org/t/fa2-1-fa3-its-time/3704/45 "2022-11-18T10:57:40Z")
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](https://forum.tezosagora.org/t/fa2-1-as-extension-of-the-fa2-standard-draft/4768/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](https://alt.smartpy.io/releases/20221118-06800c5a43fe31f6dedaf2870340c9ab5a122668/ide?template=FA21_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…
---
### Author:  [@rafoo](https://forum.tezosagora.org/u/rafoo)
#### Post date: [November 20, 2022, 8:44pm UTC](https://forum.tezosagora.org/t/fa2-1-fa3-its-time/3704/46 "2022-11-20T20:44:15Z")
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).
---
### Author:  [@Charles\_Dehlinger](https://forum.tezosagora.org/u/Charles_Dehlinger)
#### Post date: [November 22, 2022, 10:31pm UTC](https://forum.tezosagora.org/t/fa2-1-fa3-its-time/3704/47 "2022-11-22T22:31:23Z")
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.
---
### Author:  [@rafoo](https://forum.tezosagora.org/u/rafoo)
#### Post date: [November 24, 2022, 2:05pm UTC](https://forum.tezosagora.org/t/fa2-1-fa3-its-time/3704/48 "2022-11-24T14:05:59Z")
Or, yet another solution avoiding the introduction of `option address`es: 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).
[Previous page](https://forum.tezosagora.org/t/fa2-1-fa3-its-time/3704.md?page=2)