GWID SPE Pre-Proposal: Gateway Wizard Phase 1

[Eneche-gwid.io]

Authors :Eneche and Joel -GWID Team

Abstract

This proposal introduces the GWID SPE, a fully managed devOp tool that makes it easier for anyone in the Livepeer ecosystem to run , manage their own gateway and infra. It provides developers, teams, and stakeholders with the tools they need to experiment, own their infrastructure, and monetize their gateway offering.

The goal of this SPE is to:

• Make Livepeer more gateway-agnostic.

• Empower those who can generate demand to actually do it.

• Provide an open-source fully managed DevOps platform for running gateways.

• Support early-stage builders and lightweight experimentation with free credits.

• Build a public referral engine that turns free credits into a viral growth loop.

• Demystify the Livepeer-in-a-box (Catalyst) experience by making it easier to understand and use for everyone.

Mission

The Livepeer network is facing some key challenges when it comes to attracting demand and driving growth. Right now, there’s too much reliance on centralized gateways, and a lack of diversity in the types of gateways running on the network. This limits our ability to scale, and it leaves projects dependent on a handful of initiatives — like hackathons, bootcamps, dev challenges,incentivized credits and product showcases etc. — to drive demand.
Another challenge is the technical expertise required to run and manage gateways. Many smaller developers and startups don’t have the DevOps skills needed, making it expensive and difficult to create custom solutions for different needs.
Additionally, services are not currently monetized. This leads to sustainability issues and prevents stakeholders from truly measuring the value of the services they provide. Right now, there’s no easy way for early-stage developers to get credits and experiment with the Livepeer network, which limits innovation and growth.

Without more diverse demand-generation strategies — like referral systems, free credits systems or listing APIs on external marketplace/platforms like RapidAPI — we’re still depending too much on the same old paths to create growth. Meanwhile, we’re missing out on opportunities for those who can bring new ideas and new demand to the table.

The current pricing models for AI jobs are still early and often leave room for improvement. They lack granularity and often result in overpayment or inefficient resource allocation. Without better data, it’s hard to optimize pricing and make the market more fair for everyone.

Finally, the Livepeer-in-a-box (Catalyst), a self-hostable decentralized media server that replicates the “Inc Studio” framework, has recently seen a decline in visibility within the community and ecosystem. The original effort to make it easier for people to own, test, and develop on this framework has lost momentum, as its steward has moved on to other commitments. Currently, only a few experts are using the stack, which defeats the purpose of making it accessible to everyone. This lack of broader usage is partly due to the stack’s “black-box” nature and gaps in its documentation, making it harder for new users to set up and fully understand how to use it.

The GWID SPE addresses these problems by giving users the tools to easily run and monetize their own gateways. It will also take a step towards improving the Catalyst experience by making it simpler to use by finishing its documentation , and bringing the framework back to a wider group of developers. This will help create a more diverse and sustainable ecosystem for everyone.

Rationale

We’re building tools to make it dead simple for anyone to run their own Livepeer Gateway — without needing to be a DevOps expert or worrying about complex infrastructure. This will be a turnkey solution for projects who just want to focus on building their product or service while still having a sense of ownership, and want to experiment at a small scale while having control on their costs.

The proof of concept for this initiative began with an ecosystem grant from Inc. All components of this work will be fully open-source and released under the MIT license.

What We’re Building –Phase 1:

A fully managed devOp platform — think of it like Elestio, but specifically for Livepeer Gateways.

This platform will offer:

• One-click deployment of Gateways across different cloud machines (AWS, Digital Ocean, Azure etc) –Host on Gwid or Bring your own VM.

• Standard scripts (Terraform, Kubernetes) for flexible infrastructure setup.

• Optionally sideload add-ons/stack like Proxy server,load balancers, CDNs, media servers, payment systems, analytics etc.

• Gateway will default to using gwid’s SSL and domain (e.g., mygateway.gwid.io) until users decide to configure their own custom domain and SSL certificate

• Tools to customize and extend their Gateway however they want.

This turns a simple Gateway into something that can power many different types of projects.

Monetization:

Running a Gateway should be a business.
So we’re adding built-in ways for Gateway operators to charge for their services:

• Paywalls for APIs

• Custom payment integrations

• Usage-based pricing

Every gateway launched through GWID, comes with a self-service customizable page (mygateway.gwid.io) for operators to manage and sell their service using an API key. The page will have simple features like[see attachment at the bottom]:

• Billing: Add credits to your API key so you can start using the service.

• Documentation: Clear instructions on how to use the available API endpoints.

• Models: A list of available models you can use, similar to platforms like FAI.ai.

Gateway operators will also be able to track API usage through their API keys, which is useful for providing customers with stats like request counts and cost estimates.
This makes it easier to turn a gateway into a product, allowing those who can bring in demand to actually do so.

Better Discovery for Gateway:

Finally, we’ll encourage Gateway operators to list their APIs on external API marketplaces like RapidAPI, API Layer or other API directories.This improves discoverability,adoption and helps new projects get real traffic and users faster.

Pricing Transparency & Data

Gateways on GWID can optionally share anonymized pricing and usage data back to the network. This creates a growing dataset of real-world AI job costs across different models and use cases.

Over time, this enables:

• Pricing benchmarks across the network

• Recommendations for fair pricing

• Public dashboards to track pricing trends

This helps remove guesswork and creates a more transparent, competitive market.

Making Livepeer Catalyst Easier to Use

As part of our GWID initiative, we want to make Livepeer Catalyst easier to understand and use by:

• Finish Documenting the current state of Catalyst (installation/setup, operation, limitations etc).

• Simplifying the experience with better instructions and examples.

• Learning from Catalyst’s design to improve GWID modular, extendable gateway deployments .

• Providing clear materials to help the community choose between Catalyst and GWID based on their needs.

Why This Matters:

Some projects or stakeholders(Os) will always be able to drive their own demand — if they see a clear business reason to do so.
We want to give them the tools to do that:

• Easily customizable self-service Gateway site (e.g.,mygateway.gwid.io)

• The ability to market and monetize their Gateway however they want

• Earn a cut of traffic going through their Gateway

This approach not only encourages creativity, new business models, and experimentation across the network — it also gives us a real-world opportunity to test and debug Gateways across different use cases and environments.

Future phase (2) - Growth phase

After completion of phase 1 and to the satisfaction of the community, we will return to the treasury to get funding for our growth phase which include the below:

• Increase engineering capacity + Expand team with other talent

Referral & Credits Campaign

• Roll out referral program — list GWID deals on platforms like Kickbooster, Partnerstack , DappRadar etc. This list will grow as we continue to target different project types.

• Onboard developers, new projects, and new gateways

• Launch free credits system — reward new gateways based on usage and experimentation

SPE Governance Structure

The SPE will be managed by a core team, but decisions will also involve input from the community to ensure transparency and alignment with the broader network.

Key Responsibilities:

• Core Team: The core team will handle the daily operations, manage funds, and coordinate with the community on all matters related to the project.

• Community: The community will play an active role by:

  • Providing feedback on ongoing developments.

  • Voting on key proposals, such as changes to the platform, new feature integrations, and funding allocations.

  • Assisting with testing, marketing, and outreach to expand the platform’s reach and effectiveness.

The voting system will give community members a direct say in shaping the project, ensuring decisions reflect the needs and priorities of users. This democratic approach will help guide the development of the platform and foster a sense of ownership and collaboration.

Advisors:

1. Brad | ad-astra-video

2. En Canada

Who We Are

We’re a small team of engineers building an open-source tool. We’re not a company, just folks passionate about Livepeer and making it easier for others to build with it.

1. Eneche – Technical & Community Lead
   Software engineer who’s been active in the Livepeer community for over 2 years.

• Built and maintained open-source packages like livepeerjs-ima and livepeerjs-ar

• Proposed and contributed to the XMTP Messenger used in the Liver Pioneer app

• Received multiple grants from the Livepeer Grants team

• Helped other grantees ship their projects

• Completed the Farcaster x Livepeer bounty from AI SPE

2. Joel – Operations Lead
   DevOps and cloud engineer with a cybersecurity background (Consultant at Ernst & Young(Big 4))

• Spent 4 weeks with the Livepeer Inc team working on scraping metrics from gateways for real-time AI video pipelines

3. David – Software Engineer
   Builds software and micro-services that solve real problems.
   Recently worked as lead frontend engineer at Joystick, integrating Livepeer into their livestream stack

Milestones & Timeline

Project Duration: 4 months

Phase 1 (4 months)

1. Rebuild the Platform, fully-managed Devop web tool for Gateways

• Redesign and ship new UI

• One-click infrastructure setup — either hosted or BYOVM (Bring Your Own VM)

• Add/Side-load integrations/stack — load balancer,Proxy server, CDN, media servers(e.g Owncast), etc.

• Implement API paywall for monetizing services - Gateway APis

Implement a referral system with unique links and codes to reward users for bringing new projects to GWID.

• A public repo under gwid’s github with infrastructure tools and standardize scripts template to help gateway operators set up and scale their infrastructure.

2. Pricing Dashboard

• Build a simple pricing dashboard

• Compare pricing across gateways on Gwid

• Help projects benchmark costs and discover best pricing options.

3. Decluttering and rewriting documentation for Catalyst

Deliverables & KPIs

Success means more gateways running, more projects monetizing, and more useful pricing data feeding back into the ecosystem.

1. Adoption Metrics: Measure growth of the GWID ecosystem:

• Number of new gateways launched
• Number of projects onboarded.
• Total API requests served

2. Completion of Catalyst documentation

Transparency and Accountability

We’ll share a public report every 2-month covering how funds were used, what’s been built, and key progress metrics. Reports will be posted on the Livepeer Forum and GWID website.

These reports will include:

• Spend breakdown (dev compensation,infra cost)

• Multisig wallet for fund usage

• Progress on milestones

• KPIs like new gateways launched, new onboarded projects, API usage, and pricing data collected

We’ll also keep an open dashboard for basic metrics like gateway count, API requests, and pricing trends — so the community can track progress in real time.

Budget Breakdown - Phase 1

Total budget over 4 months: 6600 LPT ~ $40,000 USD at LPT @ $6.05

Allocation:

• $32,000 USD — Engineering

  • 4 Engineers @ $2000/month, working ~30 hrs/week
  • Additional Hire

• $5,000 USD — Infrastructure & Operations

  • Cloud services, compute costs, server scaling, and operational expenses (estimated for 4 months)

• $3,000 USD — Buffer against LPT price depreciation. After all allocations have been sold periodically, any remainings above the utilized $37,000 will be returned to the Treasury.

Video Demo : Deploying gateway with a button and testing playback stream

GWID Demo—Single Click: Deploying Livepeer Gateway with Playback Stream Test

[honestly_rich]

Hi @Eneche-gwid.io, very exciting to see this proposed. It has great potential to be a critical next step to diversifying gateway demand

I will leave other core contributors to follow up from a technical perspective. A couple of key questions from a product perspective:

(1) What are some of the core risks you envisage from developers actually adopting the product and launching their own gateway?
(2) What are your plans to test the gateway product from a developer perspective and then to integrate feedback?

Some context: without real consideration to creating a delightful developer experience, this could be a great tool that no one can access or follow along with. I would envision that this could be a critical SPE for the Demand Advisory Board, working closely with an Explorer SPE and Docs SPE to ensure that adoption is clear.

Looking forward to feedback

[Eneche-gwid.io]

hi @honestly_rich , really appreciate you raising these points .

For your first question. We’ve been thinking a lot about where things could go wrong, possible adoption blockers. The two major risks we foresee :

1. Developers may be hesitant to create and manage additional cloud accounts, and may also be reluctant to trust the GWID managed service to host their gateway. However, we do not consider this a significant blocker, as we are prioritizing security at every stage of our development.

2. Developers familiar with the Livepeer ecosystem might prefer using the advanced script we will be providing to set up BYOVM, rather than relying on the GWID managed service. The main reason we anticipate for this preference is trust. In response, we are actively promoting visibility, transparency, and security at every opportunity.

As far testing ,our plan is to start with a closed test group of 3–5 developers, ideally drawn from existing active contributors or grantees developers who are already familiar with the Livepeer stack. This group will test both gateway hosted-on-GWID and BYOVM (Bring Your Own VM) scenarios.

We aim to gather feedback by integrating identified friction points directly into our UX redesign and onboarding flows.We’ll ship small iterations quickly to maintain a tight feedback loop.
Additionally, we will form a small circle from this group to ensure future features are driven by real world needs not assumptions.
As for the other items mentioned, we are open to collaborating with any working group ,SPE or initiative to ensure adoption. We initially just wanted to collaborate with an already establish SPE but decided to go independently because “this SPEs collabo” is still work in progress for Govworks imo.

[hthillman]

Hi @Eneche-gwid.io -

I am excited to see this proposal and I believe it has the potential to add significant value to the Livepeer ecosystem.

I do have a couple of questions that I’m hoping you can answer:

1. Who will work on distribution, and what is their strategic plan? I’ve learned the hard way that building a great technical product is not sufficient to drive adoption. In my opinion, strong go-to-market operations are required for this SPE to have the desire impact. From the proposal above, it sounds like the strategy is to list APIs on external marketplaces. This has been attempted in the past by a few groups in the Livepeer ecosystem…so if this is the case, I have a few questions:
   a. Why do we believe that visibility will lead to success?
   b. What types of companies do we expect to use those APIs?
   c. Do you have team members with experience selling to startups, SMBs, or enterprises?

2. Is the technical focus on video, batch AI, BYOC, or realtime AI? If it is all four, in what order do you plan to tackle them?

3. Why is Catalyst the starting point here, rather than the realtime AI stack?

4. How will you ensure that gateway operators who use GWID receive adequate support when running gateways in production?

[Eneche-gwid.io]

@hthillman ,
1.Two of us on the team(including myself), have experience in the SaaS space, as founders or early engineers. We’ve taken products from idea to real users before, including platforms like Pepper and Swearit, so we understand the full cycle beyond just shipping code.
That said, we’re also being realistic. We’re bringing in a part-time GTM lead, someone with more experience in growth and adoption to help drive this from day one.
We see API marketplaces as the easiest first step to get visibility and feedback while still building. Speaking as a long-time dev, marketplaces are where I personally go to discover useful APIs quickly especially free or affordable ones. We actually checked recently and couldn’t find any Livepeer AI endpoints on most marketplaces. That alone is a gap worth filling.

One of our Phase 1 deliverables is a referral engine. This lets users create referral links and codes , and earn rewards like free credits or LPT when someone or new project signs up through them. It’s a simple, practical way to create a viral loop around GWID.

Also ,we’ll actively list our referral deals across multiple platforms where people already look for these kinds of offers. This includes: Kickbooster, Partnerstack ,DappRadar etc. This expands our reach beyond the existing Livepeer community and taps into affiliate and referral ecosystems already used by creators, influencers, and devs.

What makes GWID different, we lets users run gateways as their own product or service (“Gateway-as-a-Service.”) .Each operator gets a self-service page where they can offer their API, customize it, and even add new services/feature offering and diversity over time with Bring-Your-Own-Container (BYOC).
This means:

• We bring in operators
• Operators source and bring in their own app users ,for their own share of fees from traffic.
• Apps bring in end users who pay for services.
  So distribution becomes a shared effort , not just on us.

GWID ———>  GATEWAY-Operator(s) [Self-service page with API offers]  ———> APPs[Buy API credits]  ———>  Users [Pay for app service]   

2.Technical focus will cover all four areas, batch AI, BYOC, video, and real-time AI, but not all at once. To lay a solid foundation, we’re starting with batch AI, BYOC (to offer more flexibility and increase gateway diversity), and video (transcoding, Clipping APIs), in that order. These build on the most stable parts of the Livepeer stack and provide immediate use cases.
Plus the real-time AI stack is still under heavy development and not yet publicly accessible. Focusing on the other pipelines first, we allow time for the RTV AI to mature and become more open for Os. At the moment, it would be too expensive for us to support real-time AI, especially without incentivized compute for early experimentation.

3.We decided to extend effort to the Catalyst stack (Livepeer-in-a-box) because it has lost visibility over time, despite it works and has been battle-tested.Initial focus is on decluttering it, testing its current state, and filling documentation gaps. At the same time, this gives us a better understanding of how to design GWID to be modular, extensible, and offer a customizable “studio” experience for businesses. The idea is for a gateway to start simple, just the core node and then grow over time by adding other side-loadable stacks as needed.

4.In terms of support, the GWID UI will include built-in monitoring, logs, and alerts, along with a well-guided onboarding and setup flow with comprehensive documentation, in-app tooltips, and embedded videos to help users navigate the platform with ease. We’ll will also integrate CI/CD and automation to keep all components updated to their latest stable releases, with notifications included.In the early stages, we’re dedicating real-time human support via a Telegram/Discord group for fast responses and knitting rapport.We plan to offer a fully managed gateway tier, where we operate the infrastructure directly, allowing the user to focus entirely on API delivery or monetization.

[Jose_StableLab]

This proposal meets all the vote readiness criteria outlined in the Livepeer Governance Hub:

• It has been live in the forum for 7+ days.
• It follows the standard SPE pre-proposal template
• All feedback received during the discussion phase has been addressed.

It’s ready to proceed to a vote!

[Eneche-gwid.io]

The Budget allocation and breakdown have been readjusted to reflect that of the explorer.
The ask is low because we already got some of the components down from the Ecosystem grants and also to put more work down before coming to the community for a bigger ask.