Ticket updates in receipts

By Lin Oshitani

‍

After the Lima protocol update, you will notice a new Ticket updates field is added to the transaction receipt.

// ... fields omitted for clarity
Balance updates:
    KT1LPnsqkZnddGUWZWFE5GtGBFtq6bT6EB7Q ... -ꜩ0.027
    storage fees ........................... +ꜩ0.027
Ticket updates:
    Ticketer: KT1WuPpnvefGFqKMDHWHEXz7FpnTc5JfYCB7
    Content type: string
    Content: "blue"
    Account updates:
        KT1LPnsqkZnddGUWZWFE5GtGBFtq6bT6EB7Q ... +3
// ... fields omitted for clarity

‍

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:

Ticketer: KT1WuPpnvefGFqKMDHWHEXz7FpnTc5JfYCB7
Content type: string
Content: "blue"

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.

Ticketer: KT_T
Content type: string
Content: "blue"

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.

            blue ticket -> KT_B
           /              (store blue ticket)
tz_a -> KT_A 
        (read 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:

Manager signed operations:
    // ... fields omitted for clarity
    Transaction:
      From: tz_a
      To: KT_A
        Ticket updates: 
            Ticketer: KT_T
            Content: "blue"
            Content type: string
            Account updates:
                KT_A ... -1
        // ... fields omitted for clarity
    Internal Transaction:
        From: KT_A
        To: KT_B
        Parameter: (Pair T (Pair "blue" 1))
        Ticket updates: 
            Ticketer: KT_T
            Content: "blue"
            Content type: string
            Account updates:
               KT_B ... +1  
        // ... fields omitted for clarity

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)!