The Livepeer protocol is the product of specific engineering decisions made against a set of goals: permissionless access, economic security, censorship resistance, and the ability to coordinate a global GPU network without a central operator. Each mechanism in the protocol reflects a deliberate trade-off between these goals. This page explains the reasoning behind the five most significant design choices. It is written for researchers, protocol contributors, and founders doing technical due diligence. It assumes familiarity with the protocol mechanisms covered in , , , and .
Why stake-as-security instead of permissioned membership
The protocol uses LPT staking as the primary security mechanism. Any participant who bonds LPT above a threshold becomes eligible to enter the active orchestrator set. There is no allowlist, no identity verification, and no operator controlled by a single entity. The alternative - a permissioned membership list - would allow the network to launch faster and would simplify selection logic. The cost is permanent dependency on a trusted gatekeeper. Permissioned membership introduces a censorship surface: the entity controlling the list can exclude participants, change admission criteria, or be compelled to do so. For a network that aims to be open to any jurisdiction and any use case, this dependency is disqualifying. Stake-as-security trades simplicity for permissionlessness. It is economically aligned: orchestrators who stake LPT have a direct financial stake in the network’s success and reputation. Stake loss - through slashing or market depreciation - is a real cost for misbehaviour, which is the mechanism that replaces trust in a named operator. The cost of this design is that security scales with the value of bonded LPT, not with a fixed guarantee. When LPT price falls sharply, the cost of attacking the active set falls proportionally. The protocol acknowledges this coupling and addresses it partly through inflation: keeping a large fraction of LPT bonded increases the cost of acquiring enough stake to disrupt the active set.Why dynamic inflation exists
The protocol mints new LPT each round according to acurrentInflation rate that adjusts automatically toward a targetBondingRate. When the fraction of LPT bonded across the network falls below the target, the inflation rate rises to make delegation more attractive. When it exceeds the target, the rate falls.
The design goal is to keep a large, stable fraction of LPT bonded without a fixed schedule. A fixed issuance schedule would require the protocol designers to forecast demand accurately at launch - an impossible requirement for a network whose fee revenue and participation levels are unknown in advance. Dynamic inflation delegates that calibration to the market.
The cost is that inflation rewards are the dominant income stream for orchestrators and delegators at current network scale. Fee revenue from video and AI usage is growing, but the inflation-to-fees ratio remains large. This means the protocol currently pays participants primarily through dilution of non-participating holders, not through usage revenue. LIP-107 (reducing targetBondingRate from 50% to 46% with accelerated inflationChange), LIP-100 (adding ceiling and floor bounds to the inflation rate), and LIP-101 (treasury restart) are the first governance actions aimed at bringing inflation and fee revenue into better balance. Current parameter values are governance-controlled - verify against explorer.livepeer.org for live figures.
The long-run design assumption is that as AI and video fee revenue grows, the protocol can reduce inflation without losing network security. Dynamic inflation is the mechanism that keeps the network alive until that threshold is crossed.
Why probabilistic micropayments instead of per-job on-chain settlement
The protocol pays orchestrators through a probabilistic ticket system rather than a direct on-chain payment per video segment or AI inference call. A gateway attaches a signed ticket to each job. Each ticket has a face value and a win probability. Most tickets do not win. Winning tickets are redeemed on-chain for ETH from the gateway’s reserve in the TicketBroker contract. Direct per-segment settlement is unworkable at the network’s operating scale. A 30-minute video stream at one-second segments generates 1,800 payment transactions. At Arbitrum gas costs, this would add meaningful per-stream overhead and would make competitive pricing for low-margin transcoding impossible. AI inference workloads, which can involve sub-second pipeline calls, are even less compatible with per-call on-chain settlement. Probabilistic micropayments amortise settlement cost across many tickets. An orchestrator processing many jobs from many gateways will win approximatelywinProbability * faceValue per ticket in expectation. The expected value matches what a per-segment payment would deliver, at a fraction of the on-chain cost.
The cost of this design is variance: orchestrators receive payment in occasional large winning-ticket redemptions rather than predictable per-job receipts. High-volume orchestrators with many concurrent sessions smooth this variance through the law of large numbers. Low-volume or new orchestrators experience more cash-flow variability. The reserve mechanism in TicketBroker - which holds a larger float of gateway ETH than expected redemptions require - limits the risk of a gateway becoming insolvent mid-stream.
Why the protocol and network stay separate
The protocol does not route jobs, manage compute sessions, or verify individual segment outputs. The network does not issue tokens, update inflation rates, or manage governance. This separation is a hard architectural boundary. The alternative is a tightly coupled design where the chain participates in job routing and verification. Ethereum-based systems that attempted per-job verification on-chain in earlier designs encountered two problems: latency and cost. Waiting for block confirmation before delivering a transcoded segment makes real-time video impossible. Verifying every segment output on-chain at scale makes the economics uncompetitive with centralised alternatives. Keeping the protocol lightweight and on-chain preserves censorship resistance. The protocol’s rules are immutable except through governance, are transparent, and cannot be changed by any single operator. Keeping the network off-chain preserves performance. Job routing, session management, and compute execution happen at the speed of the internet, not the speed of block production. The boundary means that the protocol cannot enforce every network behaviour directly. The protocol uses economic incentives instead: orchestrators who behave correctly earn fees and inflation rewards; orchestrators who behave incorrectly lose fee revenue through client-side selection (gateways stop routing to poorly performing nodes) and face future slashing mechanisms. Trust is replaced by economic alignment.Why Arbitrum
The protocol contracts are deployed on Arbitrum One, an Optimistic Rollup L2 that settles to Ethereum mainnet. The LPT token itself lives on Ethereum mainnet and is bridged to Arbitrum via the Livepeer L1-L2 bridge. The migration from mainnet to Arbitrum (completed in 2022) was driven by gas cost reality. Protocol operations - callingReward(), redeeming winning tickets, bonding and unbonding LPT - were priced off the network for smaller participants at Ethereum mainnet gas prices. Arbitrum reduces transaction costs by approximately two orders of magnitude while inheriting Ethereum’s security model through fraud proof settlement.
The Optimistic Rollup design carries a specific trade-off: withdrawals from Arbitrum to Ethereum mainnet require a seven-day challenge period during which the transaction can be disputed. This affects LPT holders who bridge tokens in and out of the protocol. It does not affect in-protocol operations, which run entirely on Arbitrum.
The choice of Arbitrum over alternative L2 designs (ZK-rollups, alternative L1s) reflects the state of the ecosystem at the time of migration and the importance of Ethereum’s established validator set as a security foundation. The protocol’s Controller architecture enables contract upgrades, so future chain migration is possible through governance if a better settlement layer becomes available.
Related pages
Core mechanisms
How staking, delegation, probabilistic payments, and slashing work in detail.
Protocol economics
ETH fee flows and LPT inflation rewards: who earns each and how they are distributed.
Governance model
Stake-weighted voting, LIPs, the Governor contract, and the treasury.
Blockchain contracts
The on-chain contract architecture: Controller, BondingManager, TicketBroker, Minter, and more.