Skip to main content
ETH earnings arrive in discrete redemption steps whenever a winning ticket is redeemed on-chain. A node that processed thousands of jobs often shows zero ETH balance changes for hours, then receives a larger deposit. This is expected behaviour and part of the PM design.
Gateways pay orchestrators using probabilistic micropayments (PM): a system where each job generates a signed ticket with a small probability of being worth a larger ETH payout. Most tickets are non-winners and are discarded. A fraction win and are redeemed on-chain via the Arbitrum TicketBroker contract. Over sufficient volume, the expected ETH received matches the per-segment total while avoiding the gas overhead of thousands of individual on-chain payments.

​
How tickets arrive

A gateway attaches one PM ticket to each job confirmation it sends after receiving the transcoded output or AI inference result. The ticket is received passively as part of the job confirmation flow. The flow is:
Payment receipt flow
Your node processes job (transcoding segment or AI inference)
       ↓
Your node sends the result to the gateway
       ↓
Gateway sends a signed PM ticket back to your node
       ↓
Your node evaluates the ticket: is it a winner?
       ↓
Non-winning tickets discarded immediately
Winning tickets queued for the Redeemer
       ↓
Redeemer submits winning tickets to Arbitrum TicketBroker
       ↓
ETH credited to your orchestrator wallet

​
Ticket structure

Each ticket contains the fields the Arbitrum contract uses to verify and pay: Your node verifies the signature and checks that the gateway has sufficient on-chain deposit to back the ticket before evaluating the win condition.

​
Win condition

The win evaluation uses a deterministic pseudorandom function seeded by the ticket contents. Each ticket carries a winProbability parameter (e.g. 1/1000). The evaluator generates a random number from the ticket data and the current block hash, then checks whether the output falls below the win threshold. The expected value of a single ticket equals the per-job fee:
Winning ticket expected value example
win probability = 1/1000
face value      = 1000 × per-job fee
expected value  = 1/1000 × 1000 × fee = fee per job
Over a large number of tickets, the ETH received converges to the equivalent per-job total. At low job volumes, the variance is high — a node processing 10 jobs per day might see zero redemptions some days and two on others. Variance decreases as volume increases.

​
The Redeemer

The Redeemer is the go-livepeer component that submits winning tickets to the Arbitrum TicketBroker contract. On a standard single-node orchestrator, it runs as part of the main process and requires no separate configuration.

​
Redemption cost

Redemption transactions run on Arbitrum One (L2). Gas costs are low: The Redeemer batches pending winners when possible. A busy orchestrator usually redeems ETH in a few batched submissions per day, keeping gas overhead negligible relative to earnings.

​
ETH balance requirement

Your orchestrator wallet on Arbitrum must hold ETH to pay redemption gas. Maintain a minimum of 0.01 ETH on Arbitrum. A depleted wallet means winning tickets expire unsubmitted — that ETH is permanently lost.
Winning tickets carry an expiry block number. A wallet that runs out of ETH before submission loses expired tickets permanently. The gateway’s deposit is unaffected; the loss falls entirely on your side.
Replenish when your balance falls below 0.005 ETH on Arbitrum. Bridge ETH from Ethereum L1 using the Arbitrum Bridge or a centralised exchange withdrawal.

​
Monitoring payment receipts

​
Expected payment rate

Your expected ETH per round is:
Expected ETH estimate
expected ETH = jobs_per_round × per_job_fee × (1 - gas_overhead)
At low job volumes, actual ETH received in a given round will diverge from this estimate. The convergence improves with volume. A node processing under 50 jobs per day should expect high variability between rounds.

​
Verifying redemption is working

Check your orchestrator wallet on Arbiscan for incoming transactions from the TicketBroker contract. Each successful redemption appears as an ETH credit. From your node logs, filter for redemption activity:
Watch redemption logs
# Watch for successful redemptions
journalctl -u livepeer -f | grep -i "ticket\|redeem\|winning"
Key log messages:

​
Zero earnings for a long period

Possible causes:
  • Low job volume — at fewer than ~20 jobs per day, zero-win rounds are statistically common.
  • ETH balance depleted — winning tickets fail to redeem silently when gas cannot be paid.
  • RPC connectivity issue — check your -ethUrl endpoint is reachable and within provider limits.
  • Node offline during job routing — verify your node is connected and registered in the active set.
  • Price above gateway caps — confirm your -pricePerUnit is within range of active gateways. See .

​
Overlapping scope with payments.mdx

Use this page for the receiver-side mechanics of PM tickets: how they arrive, how they win, and how redemption works. The page covers the broader payment flow concepts, including full PM architecture, ETH funding requirements across transaction types, video vs AI payment differences, and clearinghouses. Read both for the complete picture.

Payments

Full PM architecture, ETH funding, video vs AI payment differences, and clearinghouses.

Gateway Payment Guide

The sender-side view: how gateways fund deposits and sign tickets.

Pricing Strategy

Set prices within active gateway cap ranges to ensure tickets arrive.

Reward Mechanics

LPT inflation rewards — the second income stream alongside ETH fees.
Last modified on March 16, 2026