Documentation Index
Fetch the complete documentation index at: https://na-36-handover-docs-v2-into-docs-v2-dev-20260518.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
The three contributor paths
There is no single “Livepeer developer” role. Different parts of the system have different skill profiles and different review processes. Choosing the right path makes the contribution loop short. A contribution to a contract requires a LIP. A contribution to the node binary requires a code review. A new BYOC pipeline does not require either - it ships when an orchestrator decides to run it.The repositories
Four repositories cover almost everything a contributor needs to read or touch. Two more repositories are useful but secondary: livepeer/wiki for community documentation, and livepeer/explorer-2 for the on-chain explorer UI.Building go-livepeer from source
The reference node implementation is Go-based with significant native FFmpeg and CUDA dependencies for video and AI workloads. A local build is the foundation of any node-software contribution.How a code change reaches production
The flow depends on which repository the change touches.Node software (go-livepeer)
A node-software change is reviewed through GitHub. The path is short: open an issue or post on the forum if the change is non-trivial, submit a pull request, address review feedback, and wait for merge. Significant changes are tagged into a release that orchestrators and gateways then upgrade to. There is no on-chain step, because the node software is run by individual operators - upgrades are voluntary unless the change is required by a protocol upgrade.Protocol contracts (livepeer/protocol)
A contract change requires a Livepeer Improvement Proposal. The reason is structural: the contracts are upgraded by the Governor contract on a successful on-chain vote, so any change must travel through the LIP process. The path is longer: discuss on the forum, draft a LIP with a full specification, submit through the LIPs repository for editorial review, complete the 10-day Last Call period, submit on-chain to the Governor with the 100 LPT submission stake, win the 30-round vote at 33% quorum and majority approval, and then execute. The implementation PR can be reviewed in parallel; what cannot be skipped is the governance signal.Pipelines and BYOC
A new pipeline or BYOC container ships independently. The orchestrator runs it; the gateway selects it; the protocol settles payment as it would for any built-in pipeline. There is no LIP required, no node-software upgrade required, and no governance vote required. New workload classes can be added without touching the protocol.What to read before contributing
A contributor with deep context produces a contribution that gets merged. A contributor without context produces noise that maintainers have to triage.Where to participate beyond code
Code is one contribution. Several others matter as much.- Forum participation. Almost every LIP starts as a forum thread. Engaged commenters shape proposals before they ever reach the chain.
- Vote. Bonded LPT carries a vote. Voting on proposals is a form of contribution.
- Run an orchestrator or gateway. The network needs operators who care about quality. Operating a node is the most direct way to learn the system.
- Author a LIP. Even without writing code, drafting a LIP that the community adopts is a high-leverage contribution.
- Publish research. Mechanism design, performance benchmarks, public analysis - all directly useful to the protocol’s evolution.
Where to go next
The reference node implementation. Build, test, and contribute.
Solidity contracts deployed on Arbitrum One.
The full record of protocol proposals - draft, accepted, and final.
Where every non-trivial change starts. Read, post, and engage.