LibraryStorage and networks2017Design paperCorpus record
Livepeer: a decentralised live video streaming network
Livepeer. Doug Petkanics and Eric Tang.
Petkanics and Tang's design for live video transcoding as a protocol job. Broadcasters send a stream. Transcoders stake and compete to encode the renditions viewers actually need. It is a specific media market, which is why it is more concrete than a general 'decentralised compute' essay.
Livepeer's paper specifies a market for video transcoding: broadcasters pay, orchestrators coordinate GPU nodes, and staking plus verification are supposed to keep the output honest.
The five-minute read
Transcoding is a specific job
A video stream must be re-encoded into many bitrates. The work is heavy, parallel and checkable in ways an arbitrary program is not. The paper picks this job on purpose.
Orchestrators and delegates split the role
Someone runs the GPU node. Someone else may stake toward them and share fees. The paper's token is how that delegation is expressed.
Verification is probabilistic
Not every frame is re-encoded by a referee. The paper uses checks that make cheating likely to be caught across many segments, rather than a proof of every pixel.
Broadcasters are the paying user
They want a cheaper encoder than a single cloud account. The protocol is a wholesale market for that encoding, not a consumer video site.
Liveness matters more than in batch compute
A late frame is a failed frame. The paper's market has to price latency, not only correctness. A correct transcode that arrives after the viewer left is worthless.
One action, walked through
- A broadcaster publishes a stream and a price they will pay for transcoded renditions.
- An orchestrator with staked backing accepts the job and sends segments to the GPUs they run.
- Transcoded segments are returned to the broadcaster's playback path.
- Verification jobs, assigned under the paper's rules, re-check a sample. A mismatch can slash the orchestrator's stake.
- Fees flow to the orchestrator and their delegators. A broadcaster who is not served simply stops paying that orchestrator.
The argument, unpacked
Probabilistic checks need volume
A cheater who will only ever transcode one segment can hope not to be sampled. The security argument is about a stream of segments and a stake large enough that being caught sometimes is still a loss. Small jobs with huge stakes do not fit the math, and huge jobs with tiny stakes do not either.
Delegation recreates a platform
If most stake sits with a few orchestrators, the market is a few encoding shops with a token wrapper. The paper allows wide participation. It does not guarantee it. Concentration should be reported, not assumed away.
The hard product problem is the first mile of video
Ingest, codecs, and playback are a messy industry. A clean staking diagram does not integrate itself into a broadcaster's stack. The paper is the market. Adoption is an integration story around it.
What has to be true
- Verification can detect a materially bad transcode with the sampling rate the protocol uses.
- Orchestrators have enough GPU capacity in the regions broadcasters care about.
- Stake at risk exceeds the gain from serving cheap garbage for the jobs an orchestrator wins.
- Segments arrive inside the latency the broadcast can tolerate.
What happened after the paper
Livepeer ran a public network for transcoding and adjusted its economics and verification over time. It is a real example of a DePIN-style specific-work market, which is why it belongs next to file storage and wireless rather than next to a general smart-contract chain. The paper's scope is the transcoding market. It is not a general compute protocol.
What to check before you use the idea
- How often is a segment re-checked, and what error can slip through?
- How concentrated is orchestrator stake?
- What latency does a broadcaster actually get, as opposed to the price they pay?
- Is this deployment still doing transcoding, or has the scope been widened without a new verification story?
Terms
- Transcoding
- Re-encoding a video stream into the set of renditions a player needs.
- Orchestrator
- The operator who takes encoding jobs, runs GPUs, and posts stake.
- Delegator
- A token holder who backs an orchestrator and shares fees without running the GPU.
- Probabilistic verification
- Checking a sample of outputs so cheating is likely to be caught across a stream, without redoing every frame.
The problem the paper names
Live video becomes expensive when every publisher must run enough encoders for every bitrate and every viewer. A single vendor solves it by owning the encoders. Livepeer asks whether idle GPUs can take the transcode, under a stake, without the publisher shipping their audience to that vendor.
What the design proposes
- Broadcasters and transcoders are different roles.
- Stake influences how much work a transcoder is assigned, and is the bond against bad work.
- Payment follows useful transcoding, in the paper's incentive section, rather than a fixed rental of a box.
How the mechanism is specified
- Verification of a transcode is the hard part. The paper discusses checking work rather than assuming the encoder was honest.
- The protocol does not store the video forever. It is a live pipeline. Permanence is a different product. See Arweave or Filecoin for storage.
- Later Livepeer versions change the orchestration. The role split remains the idea to cite.
What this page does not treat as proven
- A design for live transcode is not a CDN design and not a storage design.
- Stake-weighted assignment can concentrate work. The paper does not claim otherwise by magic.
- We do not describe fee revenue.
Why a venture studio still reads it
A good template for DePIN pitches because the job is narrow enough to verify: bits in, renditions out, on a clock. If a venture cannot describe the job that narrowly, it is not ready to cite this paper as a peer.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.