# Tickets

The following provides a detailed high level overview about tickets and how their attributes impact orchestrators including but not limited to:

- What are tickets and how do they work
- How adjusting orchestrator attributes affecting tickets impact orchestator payouts
- How orchestrator behavior changes with incoming tickets

** Related documentation** Earnings and Payments.

## What is a Ticket?

Broadcasters using the Livepeer network attach a “ticket” to each segment of a video they want transcoded. A ticket can be thought of as a form of work completed for a given video stream a broadcaster is emitting to the Livepeer network. The number of tickets associated with a given stream is a product of both the fees proposed by the orchestrator for doing the work and the total length of the video processed.

A ticket is comprised of the following attributes:

(these attributes makeup core-components of the ticket data-structure in the Livepeer protocol)

**recipient**: ETH address of orchestrator completing transcoding work**faceValue**: The ETH value of the ticket payable to the orchestrator if the ticket wins**winProb**: The probability of the ticket winning (2^256 - 1)**recipientRandHash**: Hashed commitment to a random number recipientRand generated by the orchestrator**senderNonce**: Random nonce generated by the broadcaster indicating the ticket is unique.**auxData**: Additional data associated with the ticket

Upon transmission from broadcaster to orchestrator, each ticket is treated as a “micropayment” worth the expected value of the ticket (calculated as: face value multiplied by the win probability of the ticket).

## Picking Winning Tickets

Picking tickets is an implementation based on probabilistic micropayments (Also See Payments). This can be thought of in the same way as a "lottery" ticket of sorts but with much more complexity whereby an Orchestrator can set a configuration value ticket expected value, or EV. By default, the `EV' is set to 1000 gwei. Based on the pixel pricing configuration, this translates to an orchestrator willing to complete 1000 gwei worth of transcoding before requiring a ticket.

Winning tickets are selected based on a ticket’s win probability (winProb) and a random value produced by hashing the broadcaster’s random number with a random number from the orchestrator linked to the commitment included in the ticket (`recipientRandHash`

). This process is completed at the end of each “round” on the Livepeer network.

## After Receiving a Winning Ticket

If an orchestrator receives a winning ticket, they can submit the ticket along with their recipientRandomHash to a smart contract which will then verify and attest that the ticket indeed won.

Given a broadcaster/ orchestrator pair (payor and payee), neither party can rig the system. Since the payee is forced to commit its random value prior to seeing the payer’s random number, the random value used to select a winning ticket can only be seen by one party during the process of generating the ticket.

## How Often *Should* I win

Although each 'win' is awarded randomly, the probabilistic (in 'probabilistic micropayments`) ensures that even with adverse impact from factors like gas prices or fluctuation in network activity, payments follow a linear distribution trend:

## Creating and Redeeming Tickets

Assuming that the orchestrator and broadcaster have connected prior and completed the initial handshake.

**Every new ticket T (emanating from a broadcaster) will result in the following steps completed by the broadcaster:**

- Append recipientRandHash to T.
- Append corresponding recipient, winProb and faceValue to T.
- Generate senderNonce and append to T.
- Send the ticket, associated signature and recipientSeed to the orchestrator.

**The orchestrator will receive each of these tickets and then complete the following steps:**

- Compute the recipientRandHash by hashing recipientSecret AND recipientSeed
- check the recipientRandHash
- if this fails, the ticket is rejected

- Check that the recipientAddress matches the current orchestrator addresss
- Check that the ticket has a valid signature and corresponds to the broadcaster address
- Assert that the random identifier assigned to the ticket is truly random

The above process is loosely how the orchestrator keeps track of tickets flowing from various broadcasters and associated metrics are derived by counting these processes.

**If an orchestrator wins a ticket the following process begins:**

- Submit the transaction (depending on orchestrator config this may be automatic) to the TicketBroker smart contract (arbitrum) with the below attributes included.
- Ticket T
- recipientRand
- Broadcaster Signature

- Assert that T has not already been identified or redeemed.
- Assert that hashing recipientRand is equal to recipientRandHash
- Recover the broadcaster payer address
- Assert that the broadcaster has penalty collateral in escrow.
- Hash the transaction against recipientRand and compare against winProb to see if the ticket actually indeed won
- If the broadcaster’s deposit is less than faceValue of T, consume the broadcaster’s collateral escrow funds (proportionally relative to faceValue of T) to the orchestrator. Otherwise, just transfer the faceValue of T.
- Mark ticket as identified AND redeemed.