What is an SPE?
A Special Purpose Entity (SPE) is an organisation funded by the Livepeer treasury through a governance proposal. SPEs are purpose-built: each one has a defined mandate, a requested budget, and milestones it is accountable to deliver. The treasury is funded by LPT inflation. Token holders vote on SPE proposals. Approved SPEs receive LPT (or equivalent), which they use to fund operations - including running infrastructure like gateways.SPE grants are not grants to individual developers. They fund organisations with a defined public benefit mandate. If you are an individual developer looking to experiment, the AI Video Startup Programme is the more appropriate route.
SPEs operating gateways today
What the SPE model enables for gateway operators
Running a gateway as an SPE differs from commercial gateway operation in one key way: your revenue comes from the treasury, not from customers. This makes it viable to:- Run public gateways at no cost to developers - lowering the barrier for new builders to try Livepeer
- Operate specialised gateways (LLM-only, BYOC, specific model sets) that serve an ecosystem gap instead of a mass market
- Build gateway infrastructure (tooling, dashboards, clearinghouse components) that the whole ecosystem benefits from, where a commercial return is indirect or long-term
What makes a fundable SPE proposal
Successful SPE proposals in the gateway space share a few characteristics:Clear public benefit, beyond business benefit
Clear public benefit, beyond business benefit
The treasury funds work that benefits the network as a whole. A proposal to run a private gateway for your own product will not receive funding. A proposal to run a free public gateway that lowers barriers for ecosystem adoption - like Cloud SPE - is fundable.The question to answer in a proposal: “If this SPE did not exist, what would the Livepeer ecosystem lose?”
Defined, verifiable milestones
Defined, verifiable milestones
Proposals include specific deliverables with timelines. For gateway SPEs this typically means: uptime commitments for public gateways, volume metrics (requests served, new developers onboarded), or specific infrastructure shipped (tooling, dashboards, documentation).Vague commitments (“we will grow the ecosystem”) do not pass scrutiny. Specific ones (“we will maintain 99.5% uptime on a public AI inference gateway for 6 months and serve N developers”) do.
Realistic budget tied to operational costs
Realistic budget tied to operational costs
Budgets are scrutinised against infrastructure costs. A proposal requesting 18 months of server costs for a public gateway, with engineering time for tooling built on top, is reasonable. A proposal with no cost breakdown will not build confidence.
A team with demonstrated capability
A team with demonstrated capability
The most successful SPEs come from teams that have already shipped something: a working gateway, a community tool, or documented contributions to the ecosystem. A first proposal from a team with no Livepeer track record faces a higher bar.
How to propose an SPE
Engage the community first
Before writing a formal proposal, discuss your idea in the
#governance Discord channel and on the Livepeer Forum. Temperature-checking with the community before spending time on a full proposal saves everyone time. Foundation BD is also a useful first contact for alignment.Look at existing approved SPE proposals on the Forum to understand the expected format and level of detail.Write the proposal
A gateway SPE proposal typically includes:
- Problem statement: What gap in the ecosystem does this address?
- Mandate: What will the SPE do? What will it explicitly not do?
- Deliverables and milestones: Specific, measurable, time-bound
- Budget: Broken down by category (infrastructure, engineering, operations). Requested in LPT or USD-equivalent.
- Team: Who is running this? What have they built before?
- Success metrics: How will token holders know if this worked?
- Reporting cadence: How often will the SPE report progress?
Post to the Forum
Proposals are posted as threads on the Livepeer Forum for community discussion. Allow at least two weeks for community feedback before moving to an on-chain vote. Respond to questions and revise based on feedback - this is expected.
On-chain governance vote
Once the Forum discussion has reached rough consensus, the proposal moves to an on-chain vote through the Livepeer governance contract on Arbitrum. LPT holders (and their delegates) vote. Threshold and quorum requirements apply.
SPE vs AI Video Startup Programme
These are two different things serving different purposes:| SPE grant | AI Video Startup Programme | |
|---|---|---|
| For | Organisations building public-benefit gateway infrastructure | Individual developers or startups building AI-powered products on Livepeer |
| Funding source | LPT treasury | Foundation budget |
| Accountability | On-chain governance + milestone reporting | Foundation programme management |
| Timeline | Multi-month proposals with defined terms | Programme cohort |
| Suitable for | Public gateways, ecosystem tooling, clearinghouse infrastructure | App development, using (not necessarily running) Livepeer |
Further reading
- Livepeer Forum (proposals and discussion): forum.livepeer.org
- Livepeer governance overview: see the Community and Governance tab in these docs
- Cloud SPE gateway and tutorials: livepeer.cloud
- NaaP dashboard reference implementation: github.com/livepeer/naap
Next steps
Opportunities Overview
Commercial business models for gateway operators who do not need treasury funding.
Community & Ecosystem
Production projects and tools built by SPE-funded and independent gateway operators.
NaaP & Multi-Tenancy
The NaaP SPE reference implementation - multi-tenant gateway with auth and billing.