A common pattern for a contract is to hold some tickets, and when it receives more tickets of the same kind, to join them with the ticket in its storage.
Unfortunately, the contract can typically not be originated with a ticket already in its storage, which means an option type must be used, and the option value pattern matched every time it’s used.
To simplify this pattern, we could use a “null ticket” with the following properties:
- a null ticket can be specified in a smart-contract’s initial storage during an origination
- a null ticket can be created using a Michelson instruction
NULL_TICKET : 'a -> 'a ticket
- a null ticket’s ticketer is the null address (
tz1Ke2h7sDdakHJQh8WX4Z372du1KChsksyU
), its amount is always 0 - a null ticket can be joined with any other kind of ticket so long as the value matches (the ticketer is ignored)
This makes a lot of code patterns much easier, but it also means being a bit more careful with invariants around tickets. I don’t think it breaks invariants we deeply care about, but it’s important to be careful about such things.