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.
- Evidence
- Primary paper
- Re-measured
- No
- Assumptions
- 4
- Records linked
- 3
Code
Source, repository, and what is actually hosted
- Livepeer white paperhttps://github.com/livepeer/wiki/blob/master/WHITEPAPER.md
- livepeer/wikiRepository taken from the source URL. No other study cites this repository. This is not an audit.
- Full text is not mirrored. Public availability is not a licence to copy the file onto this site.
- Add to a reading list
01 Claim ledger
What the paper is allowed to say
Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.
Claim 01 · Paper model
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.
Claim 02 · Paper model
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.
Claim 03 · Paper model
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.
Claim 04 · Paper model
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.
Claim 05 · Paper model
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.
02 Three cuts
Observation, model, falsifier
A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.
01 Transcoding is a specific job
Observation
What the study says
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.
Model
What has to hold
Verification can detect a materially bad transcode with the sampling rate the protocol uses.
Falsifier
What would retire it
Is this deployment still doing transcoding, or has the scope been widened without a new verification story?
02 Orchestrators and delegates split the role
Observation
What the study says
Someone runs the GPU node. Someone else may stake toward them and share fees. The paper's token is how that delegation is expressed.
Model
What has to hold
Orchestrators have enough GPU capacity in the regions broadcasters care about.
Falsifier
What would retire it
How concentrated is orchestrator stake?
03 Verification is probabilistic
Observation
What the study says
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.
Model
What has to hold
Verification can detect a materially bad transcode with the sampling rate the protocol uses.
Falsifier
What would retire it
Is this deployment still doing transcoding, or has the scope been widened without a new verification story?
04 Broadcasters are the paying user
Observation
What the study says
They want a cheaper encoder than a single cloud account. The protocol is a wholesale market for that encoding, not a consumer video site.
Model
What has to hold
Verification can detect a materially bad transcode with the sampling rate the protocol uses.
Falsifier
What would retire it
Is this deployment still doing transcoding, or has the scope been widened without a new verification story?
05 Liveness matters more than in batch compute
Observation
What the study says
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.
Model
What has to hold
Verification can detect a materially bad transcode with the sampling rate the protocol uses.
Falsifier
What would retire it
What latency does a broadcaster actually get, as opposed to the price they pay?
03 Sequence
One action, as an operating tape
- 01A broadcaster publishes a stream and a price they will pay for transcoded renditions.
- 02An orchestrator with staked backing accepts the job and sends segments to the GPUs they run.
- 03Transcoded segments are returned to the broadcaster's playback path.
- 04Verification jobs, assigned under the paper's rules, re-check a sample. A mismatch can slash the orchestrator's stake.
- 05Fees flow to the orchestrator and their delegators. A broadcaster who is not served simply stops paying that orchestrator.
04 Load-bearing
The argument, and where a pitch drops it
Probabilistic checks need volume
The cut
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.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
A design for live transcode is not a CDN design and not a storage design.
Delegation recreates a platform
The cut
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.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
Stake-weighted assignment can concentrate work. The paper does not claim otherwise by magic.
The hard product problem is the first mile of video
The cut
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.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
Stake-weighted assignment can concentrate work. The paper does not claim otherwise by magic.
05 Register
What has to be true
Model · Not re-measured
Verification can detect a materially bad transcode with the sampling rate the protocol uses.
Model · Not re-measured
Orchestrators have enough GPU capacity in the regions broadcasters care about.
Stake and threshold · Not re-measured
Stake at risk exceeds the gain from serving cheap garbage for the jobs an orchestrator wins.
Model · Not re-measured
Segments arrive inside the latency the broadcast can tolerate.
06 Divergence
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.
A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.
07 Pre-mortem
What to check before you use the idea
- 0 of 4 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.
08 Anatomy
The paper, in the order a builder needs
The problem it 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 the desk 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.
09 Lexicon
Terms, opened into the record
- 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.
10 Repository
Every linked record on this page
Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.
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.