
By Lin Oshitani
After the Lima protocol update, you will notice a new Ticket updates field is added to the transaction receipt.
In this post, we will go over what it means and why it is important for the future of Tezos.
What are tickets?
First, a quick recap on tickets.
Tickets are first-class tokens in Tezos. Contracts can mint tickets, store tickets, and transfer tickets to other contracts. Every ticket is classified by the following three elements:
- Ticketer:
・The address of the contract that minted this ticket.
- Content type:
・The type of the ticket’s content.
- Content:
・An arbitrary value set when the ticket was minted.
For example, a ticket minted by KT1Wu... with a content type string and content "blue" can be classified by:
You can read more about tickets in this blog post.
Why tickets matter
Two upcoming changes will increase the importance of tickets:
- Layer 2 solutions.
- Direct ticket ownership by implicit accounts.
Layer 2 solutions
Tezos rollups (TORU/SCORU) and sidechains (Deku) utilize tickets to transfer assets between layer 1 and layer 2. By using tickets, Tezos layer 2 solutions can bridge not only tez (by wrapping them in ctez, etc.) but also arbitrary fungible/non-fungible tokens.
To improve the experience of moving assets to and from layer 2, the upcoming FA 2.1 proposal includes a standard for exporting and importing tokens as tickets. This means that users can seamlessly transfer FA 2.1 tokens between layer 1 and layer 2 by:
- Exporting tokens as tickets from FA 2.1 contracts and depositing them to layer 2.
- Withdrawing tickets from layer 2 and importing them into FA 2.1 contracts.
Direct ticket ownership by implicit accounts
Currently, only originated contracts can own tickets, so implicit accounts must rely on some “ticket holder contract” for ticket ownership. We plan to include a change to remove this restriction in an upcoming proposal. Once this proposal is accepted, implicit accounts can own tickets without relying on external contracts.
We believe that enabling implicit accounts to own tickets directly would open up new and exciting use cases for tickets.
Problem: Tickets lack transparency
One problem with tickets has been the lack of transparency of ownership. Namely, Tezos nodes do not provide information such as:
- How ticket ownership changed after a given transaction.
- List of tickets owned by a given address.
This hinders the usage of tickets as the lack of transparency makes it hard for:
- Indexers to provide helpful information about ticket ownership.
- Wallets to display the list of tickets owned by the wallet owner.
- Wallets to display ticket ownership changes after executing a transaction.
Solution: Tickets ownership updates in receipts
To overcome this problem, we made ticket ownership updates part of the transaction receipt, similar to tez balance updates.
Example
Let’s think of the following ticket, which we will call blue ticket in this post.
Now let us think of the following scenario:
1. Contract KT_A initially has one blue ticket in storage.
2. An implicit account tz_a calls KT_A.
3. KT_A reads a blue ticket from storage and sends it to another contract, KT_B.
4. KT_B stores the received blue ticket.
As a result:
- A blue ticket is removed from KT_A’s storage by the initial transaction.
- An internal transaction adds a blue ticket to KT_B’s storage.
This will be reflected in the receipt as the following:
You can find more examples in the original design document.
How will it be used?
The newly added ticket balance update information will enable:
- Indexers to scan the receipts and construct and maintain a “global ticket balance table” that keeps track of all ticket ownerships.
- Wallets to list tickets owned by the wallet owner by querying the indexer.
- Wallets to display ticket ownership changes after executing a transaction by reading the receipt.
What’s next
We plan to propose further changes to improve the transparency of ticket ownership, such as:
- Implement RPCs to fetch ticket balance information.
- Add ticket balance updates in receipts of all combinations of transactions — between implicit accounts, originated contracts, and rollups.
(Refer to the design document for more information.)
We would also like to continue communicating with users and ecosystem developers to further improve ticket UX. If you have any feedback, let us know!
If you want to know more about Marigold, please follow us on social media (Twitter, Reddit, Linkedin)!