Skip to main content
Livepeer uses both its native token - LPT, and Ethereum (ETH) to power its network and compensate actors for their contributions. The Livepeer protocol uses a dynamic inflation rate and stake-for-access model to ensure the network’s security and functionality. We’ll cover the LPT tokenomics and why delegating to orchestrators remains important even as inflation tapers off.

​
Money Flow: LPT Token Economics

​
1. Staking Flow (Delegators → Orchestrators)

Step 1: Token Approval Before bonding, delegators must approve the BondingManager to transfer their LPT tokens. Step 2: Bonding Delegators call Bond(amount, orchestratorAddress) which:
  • Transfers LPT from delegator to BondingManager
  • Updates orchestrator’s delegated stake
  • Calculates pool position hints for gas optimization
  • Updates the transcoder pool sorted by stake
Step 3: Orchestrator Registration To become an orchestrator, a node must:
  • First bond LPT to itself
  • Call Transcoder(rewardCut, feeShare) with commission parameters
  • Register service URI via SetServiceURI()
The transcoder pool maintains orchestrators sorted by delegated stake as a linked list, with hints optimizing insertions.

​
2. Reward Flow (Minter → Orchestrators → Delegators)

Each round, active orchestrators can call Reward() to mint inflationary tokens: Reward Calculation Process:
  1. Orchestrator calls Reward() on BondingManager
  2. BondingManager queries CurrentMintableTokens() from Minter
  3. Minter calculates: mintable = inflation * totalSupply / bonded
  4. Reward distributed proportionally to orchestrator’s stake
  5. Orchestrator keeps their commission (rewardCut)
  6. Remaining rewards distributed to delegators proportionally
Claiming Earnings: Delegators must call ClaimEarnings(endRound) to realize their accumulated rewards and fees from past rounds.

​
3. Payment Flow (Broadcasters → Orchestrators)

The payment system uses probabilistic micropayments to minimize on-chain transactions: Step 1: Broadcaster Deposits Broadcasters fund their account via FundDepositAndReserve():
  • Deposit: Locked collateral (can’t be used immediately)
  • Reserve: Available pool for ticket redemptions 14
Step 2: Off-Chain Ticket Creation For each video segment processed:
  • Broadcaster creates a signed ticket with faceValue and winProb
  • Ticket sent off-chain to orchestrator via HTTP headers
  • Most tickets don’t win (e.g., 1% win probability)
Step 3: Ticket Validation & Queuing Orchestrator validates ticket:
  • Checks signature and expiration
  • Calculates if ticket wins using recipientRand
  • Winning tickets queued in local database
  • Tracks sender’s MaxFloat (reserve - pending redemptions)
Step 4: On-Chain Redemption When sufficient funds available:
  • Orchestrator calls RedeemWinningTicket(ticket, sig, recipientRand)
  • TicketBroker validates ticket against on-chain state
  • Transfers faceValue from broadcaster’s reserve to orchestrator
  • Updates claimedReserve in BondingManager
This achieves ~99% cost reduction vs. per-segment on-chain payments while maintaining fair compensation through probabilistic expected value.

​
4. Fee Flow (Broadcasters → Orchestrators → Delegators)

Orchestrators earn fees from ticket redemptions:
  • Fees accumulate in orchestrator’s earnings pool
  • Orchestrator keeps their commission (feeShare)
  • Remaining fees distributed to delegators
  • Delegators claim via ClaimEarnings()

​
5. Withdrawal Flows

Unstaking (Delegators):
  1. Call Unbond(amount) - creates unbonding lock
  2. Wait UnbondingPeriod rounds (typically 7 rounds)
  3. Call WithdrawStake(unbondingLockId) - receive LPT back
Payment Withdrawal (Broadcasters):
  1. Call Unlock() on TicketBroker
  2. Wait unlock period
  3. Call Withdraw() - receive remaining deposit + reserve

​
Client Integration

The go-livepeer client abstracts all contract interactions through the LivepeerEthClient interface: 15 Contract Address Resolution: All contract addresses are dynamically discovered through the Controller registry using Keccak256 hashes of contract names. This enables contract upgrades without changing client code. 16

​
Gas Optimization Strategies

​
1. Pool Hints

When bonding or calling reward, the client calculates “hints” (previous/next positions in the sorted transcoder pool) to enable O(1) insertions instead of O(n) searches on-chain. 17

​
2. Batch Operations

Multiple tickets can be created off-chain in batches, with only winning tickets requiring on-chain transactions.

​
3. Dynamic Gas Pricing

The client implements sophisticated gas price management, using 2x base fee with user-specified ceilings to balance confirmation speed and cost. 18

​
Summary: Complete Money Flow

  1. Token holders approve and bond LPT → BondingManager (staking)
  2. Minter mints new LPT → BondingManager → Orchestrators (inflation rewards)
  3. Orchestrators distribute rewards → Delegators (minus commission)
  4. Broadcasters deposit LPT → TicketBroker (payment reserves)
  5. Orchestrators redeem tickets → receive LPT from TicketBroker (fees)
  6. Orchestrators distribute fees → Delegators (minus commission)
  7. Delegators claim earnings from BondingManager (accumulated rewards + fees)
This creates a circular economy where:
  • Staking secures the network and earns inflation rewards
  • Active orchestrators earn fees from broadcasters
  • Delegators participate in rewards without running infrastructure
  • Probabilistic payments enable cost-efficient micropayments
  • All flows tracked on-chain with minimal gas overhead

​
Notes

  • The contracts are deployed on Ethereum mainnet (and Arbitrum for L2)
  • Contract addresses are stored in the Controller registry for upgradeability
  • All token operations use standard ERC20 approval patterns
  • The system supports both L1 and L2 deployments with backward compatibility
  • Round-based operations ensure coordinated protocol upgrades and state transitions
  • The probabilistic payment system reduces on-chain transactions by ~99% while maintaining fair expected value for all parties
Last modified on February 18, 2026