It’s an interesting point, and the comparison section could have been more detailed in that regard: not faxxx vs ticket but a combination of the two.
Quick answers:
- You can implement FAxxx with ticket, and therefore implement a token (using tickets) that will be able to interact with contract making assumptions based on the standard. But I’m not sure that’s what you meant, and to do that you keep everything very centralized, so you don’t need tickets. Maybe linearity can help in providing confidence on the quality of the code, the way it implements the invariants.
- There is a natural way to implement a token with tickets that is not compatible with FA2, I think, but it’be clunky right now. For example, you can’t necessarily implement
balance_ofif the tickets are stored client-side, but you can’t store in implicit address… I mean you can keep a ledger on hand but then you’re implementing FA2 ? Anyway, *there is an active discussion about FA evolution, and you can participate and develop your ideas here: FA2.1 / FA3 - It's time - #36 by tom * - I think some new stuff is coming that would simplify tickets even more. Transfers between implicit account for instance. With that we’ll have natural decentralized ownership of tickets.
