Livepeer Protocol Economics

Learn how LPT, staking, inflation, rewards, fees, and payment flows shape the Livepeer protocol economy.

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 optimisation
• 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 optimising 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 minimise 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 Optimisation 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