RFC: 90-Day Treasury Diversification & Volume-Weighted Governance Framework

Hi everyone,

I am opening this thread to propose a concrete framework for our treasury strategy and governance structure. After attempting to discuss this in Discord, the conversation was unfortunately shut down under the assumption of “AI automated posting” simply because the arguments were highly structured. I am a long-term, human LPT holder and delegator who has taken significant market losses, and I care deeply about the commercial survival of this protocol.

Let’s move past chat distractions and look at a clean business case to make the treasury transition sustainable under our tight deadlines. We need an immediate execution framework rather than a long-term academic plan:

1. Yield-Bearing Stables Buffer (Capital Protection)

Divert 15-20% of current treasury holdings into yield-bearing stablecoins (e.g., sDAI, USDe) to build an immediate operational cushion. This protects the protocol runway from macro drawdowns and secures an emergency fund for essential development.

2. High-Utility Products with Real LPT Yield

Shift future funding focus away from vague R&D toward specific, revenue-generating products where network utilization drives fees, directly supplementing LPT staking yield in stables/ETH to create organic cash flow.

3. Aggressive Organic SEO & B2B/B2C Marketing

Dominate search and builder acquisition immediately. Build hyper-targeted B2B pipelines to capture AI teams looking for affordable compute, alongside clear B2C funnels for consumer-facing video applications.

4. Verifiable KPI Data Dashboards

Implement transparent, real-time dashboards mapping milestone deliveries against treasury outflows and actual fee generation to eliminate speculation and build community trust.

5. Volume-Weighted Governance & Veto Power

Restructure the governance model so that token owners hold binding voting power directly proportional to their staked volume and commitment duration. LPT holders carry 100% of the underlying financial risk; we must explore smart-contract frameworks where holders have actual veto power over Foundation treasury spend to prevent centralized capital allocation.


Immediate 90-Day Execution Roadmap

  • Days 1–30: Stabilization & Diversification

    • Submit formal governance proposal to diversify 15-20% of active treasury into stables.
    • Deploy initial data dashboard tracking net capital outflows versus order-book depth.
    • Draft an RFC on volume-weighted governance and token-holder veto rights.
  • Days 31–60: Commercial Pivot & Campaign Launch

    • Launch targeted B2B and B2C marketing campaigns for AI compute buyers.
    • Implement programmatic hedging: convert a fixed portion of upcoming SPE milestone allocations into stables automatically during market strength to avoid forced dumping.
  • Days 61–90: The Yield Loop Trigger

    • Tie future SPE funding tiers strictly to verifiable user acquisition and fee-generation metrics.
    • Activate the direct routing of generated protocol fees back to active LPT delegators.

This foundational proposal is designed for immediate execution. Maturing our treasury and commercial strategy cannot wait, and I look forward to constructive feedback from the community and the Foundation.

2 Likes

Hi. Thanks for the thoughtful proposal. There are some good suggestions in here for the community to weigh in and consider action on: particularly the treasury diversification theme, and suggestions for milestone based payouts and transparency on funding initiatives. The KPI dashboards and verifications of work are certainly intended to be in place through the monthly accountability updates and dashboards that already exist, but could always be more visible or improved in their execution.

I did want to provide some context around a few points in the post though in case you want to take that into account or update the proposals a bit:

Volume Weighted Governance and Veto Power

Just to clarify, this already exists and is how treasury funding is executed. All funding is allocated via stake weighted voting by token holders (who have veto power over the votes of their delegate orchestrators). The foundation does not have any ability to direct allocations of funds out of the treasury.

Shift future funding focus away from vague R&D toward specific, revenue-generating products where network utilization drives fees

On one hand, there’s an argument that public goods funding should fund the core common goods components of the network that no revenue generating businesses are incentivized to build and maintain themselves. But if we ignore that for a second and assume the purpose of the treasury is to fund things that generate demand…your point is fair but is easier said than done.

All the demand gen bets funded so far have tried their hardest to find fit and generate revenue at significant scale on the network. That would be a win for everyone. There are hundreds of initial prototype applications with grand visions that have used the network through the Studio gateway, but you can’t just manifest them into a scale that makes an impact by routing some LPT funding towards them. So while the intention here is noted…I’m not sure suggesting it as a key focus is as actionable as one might think unless its accompanied by a specific strategy for accomplishing it. That would be welcome!

Aggressive SEO marketing

Would you market to the apps built on the network? Frameworks, Blueclaw, Studio, Daydream, etc? Or would you market towards the network itself? If the latter, I think there’s some key product work to be done first to ensure the network’s raw capabilities are easily accessible and well explained. (I know multiple network development SPEs and foundation team are working hard on this!)

1 Like

Hi dob,

Thank you for the thoughtful and constructive response. I appreciate you taking the time to engage with the proposal and for adding useful context around the current governance process, funding initiatives, and marketing challenges.

Based on your feedback, I think it makes sense to narrow the scope of the proposal rather than trying to address treasury strategy, governance, marketing, product strategy, and token economics all at once.

However, after looking at the current Explorer data, I also think the urgency needs to be stated more clearly.

Recent usage trends suggest that Livepeer may be facing a demand replacement problem, not just a marketing or governance problem.

If a major legacy live-streaming demand source such as Trovo winds down or stops contributing meaningful usage, then the network cannot rely on the old livevideo/transcoding demand base to carry the protocol economy.

This creates a much more urgent question:

What new products can realistically replace that demand, generate recurring usage, grow fees, and create value for the network and its delegators within the next 3 to 6 months?

That is why I think this proposal needs two tracks:

  1. A focused pilot/RFC for treasury discipline, milestone-based funding, SEO, community activation, delegator alignment, and performance-based growth.
  2. A separate emergency stabilization plan focused on replacing lost demand through the new product lines closest to revenue.

The strongest near-term area of alignment seems to be treasury risk management, milestone-based accountability, and urgent product-led demand generation.

1. Treasury Stable Buffer

I still believe it is worth exploring whether part of the active treasury should be diversified into stable assets to reduce exposure to market drawdowns and improve operational predictability.

To be clear, I am not suggesting an immediate aggressive treasury move or a sudden large conversion that could negatively impact the market.

A better approach would be risk-managed treasury diversification over time, using predefined limits and execution safeguards.

A possible first step could be to explore a 15 to 20% stable asset buffer, implemented gradually and transparently, with clear limits, reporting, and community oversight.

2. Clearer Milestone-Based Funding

I agree that generating real demand is easier said than done, and I do not want to imply that funded teams are not trying. My concern is more about the structure of funding and how strongly it is tied to verified traction.

A possible improvement would be to separate baseline operational funding from performance-based funding.

Baseline funding could support necessary public goods, infrastructure, maintenance, and core development work. Larger follow-on tranches could unlock only when predefined milestones are met, such as verified network usage, integrations, recurring demand, user acquisition, fee generation, or other measurable outcomes.

The goal should not be to stop funding experimentation. The goal should be to reduce open-ended funding risk and make the path from funding to measurable network value more transparent.

3. Governance and Delegator Participation

Thank you for clarifying the existing governance structure. I understand that stake-weighted governance and delegator override rights already exist today.

My concern is not that the mechanism does not exist. My concern is the practical gap between having governance rights and actively using them.

Most delegators are unlikely to follow every proposal closely, review every funding decision in detail, or actively override their orchestrator’s vote. As a result, governance may technically be available to token holders, but in practice many delegators remain passive.

So rather than proposing a full replacement of the current governance model, I think it would be useful to explore better visibility, alerts, summaries, and UX around major treasury decisions.

This could make existing governance more effective without requiring a radical redesign.

4. Product-Led Demand Generation

On the marketing point, I agree that the raw protocol layer may not be the right thing to market broadly to end users.

A more practical approach would be to market the new product layer, gateways, APIs, developer tools, and specific AI/media use cases that make Livepeer’s capabilities easier to access.

The focus should not be on trying to revive old livevideo demand as the main growth path. The focus should be on new products that can create fresh demand, including AI-driven media, creative tools, real-time media workflows, and other productized use cases built on top of the network.

Developers, startups, creators, and AI/media teams are not looking for node infrastructure. They are looking for reliable, affordable, easy-to-integrate solutions for specific problems.

That is where problem-first content and SEO can become very valuable.

Livepeer could identify the exact pain points people are already searching for and build content around those problems. This type of content can work like a demand magnet: it attracts people who already have a problem, then routes them toward the Livepeer product layer when there is a clear fit.

This is not just content for awareness. It can become a market discovery engine.

If certain topics attract traffic, signups, product usage, leads, integrations, or builder interest, that gives the community real data on where product demand exists.

The initial SEO foundation does not need to take months to organize. The first 30 days could be used to build the core structure: topic clusters, keyword maps, content briefs, comparison-page opportunities, landing-page priorities, tracking requirements, and a publishing roadmap.

Execution can then be handled through specialized contributors, community bounties, or external partners with clear deliverables.

5. New Product Revenue and Delegator Alignment

One important point is that new products should not only create usage in a general sense. They should also be designed to generate measurable crypto-native revenue for the network where technically possible.

If Livepeer already has existing infrastructure where network usage can generate ETH-denominated fees or other crypto-native payments, then new products should try to use or extend those rails rather than creating isolated revenue streams that do not benefit the protocol economy.

This matters for delegators.

Delegators are currently exposed to inflation, market downside, and the loss of previous demand. If new products generate usage but that value does not flow back into the Livepeer network economy in some form, then delegators still carry the risk while product value may remain disconnected from tokenholder value.

So part of the product strategy should be:

  • create new product demand
  • route usage through Livepeer where technically possible
  • generate measurable fees in ETH, stables, or other crypto-native payments
  • make fee generation visible in dashboards
  • explore how those fees can supplement or support delegator yield over time

This does not need to require a complete redesign if existing fee infrastructure can already support part of this. The key is to make sure new products are not only useful products, but also value-accruing products for the network and its delegators.

6. Community Activation and Social Proof

Passive delegators are not only a governance issue. They can also weaken the strength, visibility, and social layer of the ecosystem.

If most delegators only stake passively and do not actively understand, discuss, share, or identify with the products being built on Livepeer, then the network loses a major potential advantage: its own community as a distribution and credibility layer.

This can be improved through better communication, social media, product storytelling, and community education.

Delegators should not only see themselves as passive token holders. They should understand what Livepeer products are solving, which markets they target, what progress is being made, and how network usage connects back to the long-term health of the protocol.

If delegators identify more strongly with the products and use cases, they are more likely to share updates, discuss progress, create content, give feedback, participate in governance, and help create social proof.

Marketing should therefore not only target external users. It should also activate the existing Livepeer community and help passive delegators become more informed, engaged, and product-aware participants.

7. Performance-Based Partner and Affiliate Growth

Another practical way to reduce upfront marketing risk would be to introduce a performance-based partner and affiliate model.

Instead of relying only on fixed marketing budgets, Livepeer could reward contributors, publishers, developers, creators, agencies, and community members when they generate measurable outcomes.

This could include rewards for qualified B2B leads, developer signups, first product usage, new applications built on Livepeer, tutorials that drive onboarding, or customers that create recurring network usage.

The benefit is that part of the growth budget becomes performance-based. Livepeer pays when there is a verified result, rather than paying large upfront retainers without knowing whether a channel will work.

To protect the treasury and avoid low-quality spam, this should be tied to clear tracking, attribution, quality standards, and milestone-based payouts.

Rewards should be based on verified outcomes, not just impressions or vague awareness.

8. Suggested Next Step

Since there appears to be some agreement around treasury diversification, milestone-based funding, and improving accountability, I think the most productive next step would be to turn this into a narrower RFC.

This should be framed as a practical pilot/RFC, not as a full protocol overhaul or a complete rescue plan.

A focused first proposal could cover:

  • risk-managed treasury diversification over time, using predefined limits and execution safeguards
  • a possible 15 to 20% stable asset buffer for treasury risk management
  • clearer reporting on treasury outflows versus measurable network demand
  • milestone-based funding tied to verified usage, integrations, leads, or fee generation
  • better visibility and UX for delegators around major governance and treasury decisions
  • a 30-day SEO and content-led demand generation foundation
  • a clear framework for how new products generate crypto-native fees and how that value connects back to the Livepeer network economy and delegators
  • community activation and social media to help passive delegators become more product-aware and engaged
  • a pilot program for performance-based community bounties, partner referrals, and affiliate-style growth

This would keep the scope realistic and allow the community to evaluate concrete improvements instead of debating the entire long-term strategy at once.

To be clear, I am not suggesting that Livepeer should stop funding public goods or core infrastructure. Those are essential.

My point is that treasury-funded growth initiatives should become more measurable, more performance-based, and more directly connected to real demand and value accrual for the new product layer.

Thanks again for engaging constructively. I am happy to help refine this into a more concrete RFC if there is interest from the community.

Emergency Stabilization Plan: 0 to 180 Days

The proposal above is intentionally framed as a focused pilot/RFC. But if the recent Explorer data reflects a structural demand shock rather than a temporary fluctuation, then Livepeer also needs an emergency stabilization track.

This should not be framed as panic. It should be framed as treasury discipline, product focus, demand recovery, and delegator alignment.

The goal is simple:

Protect runway, reduce waste, identify the fastest paths to real usage, and rebuild demand around new products that can generate measurable network activity and crypto-native fees.

Phase 1: 0 to 30 Days, Triage and Focus

1. Lost Demand Replacement Analysis

Before discussing long-term growth, the community needs a clear view of what demand has been lost.

If a major customer or usage source has stopped or is winding down, the key questions are:

  • How much usage did that source represent?
  • Which product line did it use?
  • Which gateways or SPEs were exposed?
  • How much fee generation disappeared with it?
  • Was this usage profitable, subsidized, strategic, or low-margin?
  • Can similar demand be replaced, or is that market no longer a priority?

Without this analysis, the community is guessing.

If Livepeer is moving away from relying on legacy livevideo/transcoding demand and toward new AI/media products, then the strategy needs to be explicit: which new products are expected to replace the lost usage, on what timeline, with what revenue targets, and with what go-to-market support?

2. Treasury Spend Review

Temporarily review all non-critical treasury-funded initiatives.

This does not mean stopping essential infrastructure, security, protocol maintenance, or critical public goods. But every non-essential or speculative initiative should be reviewed against current urgency.

During a demand shock, treasury spend should prioritize survival, usage, product-market validation, and products that can create measurable network fees.

3. Milestone Gate Freeze for New Large Allocations

No large new treasury allocations should be approved without:

  • clear deliverables
  • measurable usage targets
  • reporting requirements
  • timeline
  • success/failure criteria
  • expected path to fee generation
  • pause or milestone-gating logic where possible

The community should not continue open-ended funding while demand is falling.

4. Concentration-Risk and Fee Dashboard

Add a dashboard or monthly report showing:

  • top demand sources by percentage of network usage
  • product-level usage trends
  • recurring versus one-off usage
  • fees generated per product path
  • ETH, stable, or other crypto-native revenue where applicable
  • treasury spend versus demand generated
  • how new product revenue connects back to network value and delegators

If one customer or product line can materially change network usage, the community needs to see that concentration risk clearly.

Phase 2: 30 to 90 Days, Product-Led Demand Recovery

5. Prioritize New Products Closest to Revenue

Livepeer should focus resources on the new product paths most likely to create measurable demand within 90 days.

Priority should go to products that can create real usage and generate measurable crypto-native fees through Livepeer’s existing or easily extendable fee infrastructure, so new product traction is connected back to network value and delegator alignment.

This is not the time to spread resources evenly across every idea. The community needs focus.

The priority should be the product lines closest to real usage, real customers, recurring fee generation, and value accrual for the network.

6. 30-Day SEO and Demand Foundation

Build the demand foundation immediately:

  • keyword maps
  • topic clusters
  • pain-point landing pages
  • comparison pages
  • product onboarding content
  • use-case pages
  • tracking and attribution setup
  • conversion paths from content to signup, usage, or contact

The goal is not just rankings. The goal is to identify which pain points create real interest, leads, product usage, and customer conversations.

7. Outbound and Partner Sprint

Run a focused outreach sprint toward the users and companies most likely to need the new product layer.

This should be tied to specific product offers, not vague ecosystem messaging.

8. Performance-Based Bounties and Affiliate Pilot

Open a small pilot for community and external contributors.

Pay for verified outcomes, such as:

  • qualified B2B leads
  • developer signups
  • first product usage
  • published tutorials that drive onboarding
  • comparison pages that bring qualified traffic
  • social content that increases product awareness
  • integrations that create measurable usage
  • customer acquisition that generates measurable network fees

Avoid paying for vanity metrics. No rewards for empty impressions, spam traffic, or low-quality content.

Phase 3: 90 to 180 Days, Decide What Survives

9. Kill, Pause, or Scale Based on Data

After 90 days, every growth initiative should be reviewed.

Scale what produces:

  • real usage
  • qualified leads
  • recurring demand
  • developer adoption
  • fee generation
  • product integrations
  • community activation
  • measurable value accrual for the network

Pause or stop what does not.

10. Treasury Reallocation Based on Demand and Fees

Future treasury funding should increasingly follow evidence.

If a team, product, or campaign creates measurable network demand and fee generation, it earns more support.

If it only produces narratives, roadmaps, or vague ecosystem value without measurable usage or fee potential, it should not receive large follow-on funding during a demand crisis.

11. Delegator Communication Reset

Delegators need a clearer monthly view of:

  • what products are growing
  • what demand was lost
  • what treasury funded
  • what milestones were met
  • what usage was generated
  • what fees were generated
  • how product revenue connects to the network economy
  • what risks remain
  • what decisions are coming to governance

Passive delegators become more active when the information is clear, relevant, and connected to their economic exposure.

12. Six-Month Success Criteria

The emergency plan should define concrete six-month targets.

For example:

  • stabilize or reverse the decline in network usage
  • reduce demand concentration risk
  • increase qualified product leads
  • increase product onboarding
  • increase fee-generating usage
  • improve treasury reporting
  • make all major growth funding milestone-based
  • create a clear connection between new product revenue and delegator alignment
  • activate delegators through clearer product and governance communication

If these targets are not met, then the community should be honest that the current structure is not working and deeper changes are required.

Summary

The current situation should be treated as a demand and concentration-risk warning.

Livepeer does not only need better marketing. It needs product-led demand recovery, treasury discipline, milestone accountability, crypto-native fee generation, and a stronger community distribution layer.

The immediate priority should be:

  • protect runway
  • stop vague spending
  • focus on new products closest to revenue
  • make sure new products create measurable network fees where technically possible
  • rebuild demand through SEO, outreach, partnerships, and bounties
  • show delegators how new product revenue connects back to the network economy
  • measure everything
  • scale only what works

Hi @Dude Thanks for the depth here. I run narrative and marketing for the Foundation. I’ll respond to the marketing side of the proposal (points 4, 6, and 7).

First, you’re correct here: Livepeer needs a clear marketing strategy in service of demand generation, and it doesn’t fully have one today. The community should see that strategy stated plainly, and part of my job over the coming months is making it legible. With that, here’s where your proposal could use more of Livepeer’s context:

On SEO as a 30-day demand lever: Yes, we can build keyword maps, topic clusters, and content briefs in 30 days, but rankings, domain authority, and conversion paths that produce qualified developers take six to nine months to turn over in practice. That’s not just specific to Livepeer, it’s how SEO works. I’d rather be honest about the timeline than launch an urgent SEO sprint that gets judged a failure right when it would start working.

On B2B pipelines for enterprise compute buyers: Enterprise buyers need SLAs, uptime guarantees, support contracts, compliance review and other guarantees that are beyond the scope of a permissionless network today. So a pipeline that delivers enterprise leads into a network that can’t sign an SLA generates churn and a credibility problem. Our focus at the moment is close the usability gap and then drive demand into it.

For example: our Developer Dashboard (what we internally call the 5-Minute Developer Experience) is the first step at closing the gap between real-time AI application developers and Livepeer compute. Alongside, the PymtHouse payment tooling in development lets any application or platform on Livepeer define its own trial credit rules, plug in non-standard payment flows like Stripe, and control exactly how and when a user keeps signing jobs. Free trials, fiat onramps, rate limiting are the types of “unglamorous” capabilities that make a network ready for top of funnel demand. The Developer Dashboard is where we can showcase the PaymtHouse capability.

Some context: we ended our agency relationship earlier this year and brought content production in-house. That agency ran a high-growth social strategy that produced significant impressions and reach but the content itself cost us credibility. This insight is baked into our narrative strategy as we’re rebuilding Livepeer’s content engine to be a credible voice in real-time AI and open compute. The logic here is: activate the lower part of the funnel now and prepare the network for top-of-funnel readiness.

On point 7, performance-based partner and affiliate growth: This sounds like risk-free growth (pay only for verified outcomes) but in practice it’s a significant LOE as the program itself is the cost. Tracking infra, attribution, quality enforcement, fraud filtering, payout admin and disputes is a standing ops workstream. Additionally, performance incentives attract contributors who optimize for the payout event (the signup, the first usage) not for what happens after. Broad affiliate programs rarely produce that quality of builder at a conversion rate that justifies the effort, especially against the other demand work that’s better calibrated to our current resourcing. Where verified-outcome funding does make sense (milestone-gated treasury allocations to funded teams) the community already has the mechanism, Doug pointed to where it can improve. I wouldn’t extend that logic to a marketing affiliate layer right now.

On point 6, community activation: This is a great point. Marketing should help passive delegators be informed, engaged, and product-aware participants. Educational content for delegators and orchestrators is on our radar as part of that recalibration. You can see the direction in our recent builder spotlight on Marco van Dijk and FrameWorks. Another builder spotlight is in production, and a delegator spotlight is a good idea I’m taking from this thread.

Hi Salinsug,

Thank you for the detailed response. I appreciate the context, especially around the Foundation’s current marketing direction, the agency relationship, the Developer Dashboard, the 5-Minute Developer Experience, and the payment tooling being developed.

This is helpful because it clarifies an important point: the issue is not simply “do more marketing.” The issue is sequencing.

If the lower funnel, onboarding, payments, trial credits, rate limits, and developer experience are not ready, then pushing broad top-of-funnel demand too early can create exactly the credibility problem you describe.

I agree with that.

On SEO, I also agree that rankings, authority, and qualified developer conversion do not fully mature in 30 days. My point was not that SEO would solve demand within 30 days. My point is that the strategic foundation can be built quickly: keyword maps, topic clusters, content briefs, comparison opportunities, landing-page priorities, tracking requirements, and a roadmap that aligns with product readiness.

That way, SEO is not judged as a short-term emergency lever, but it also does not start too late. If the Developer Dashboard and payment tooling are the lower-funnel foundation, then SEO and content should be prepared in parallel so demand can compound once the product experience is ready.

Some of this work does not need to sit entirely on the Foundation’s internal team. Once the strategy, positioning, and quality bar are clear, parts of the execution could be handled through scoped community bounties or contributor tasks.

For example:

  • keyword research
  • topic clustering
  • content briefs
  • comparison-page research
  • developer tutorial drafts
  • product explainers
  • use-case research
  • competitor and search-intent mapping
  • content refresh suggestions
  • distribution ideas for social and community channels

This would not replace the Foundation’s narrative control or quality review. The Foundation should still define the message, approve final content, and protect credibility.

But scoped bounties could help move faster on research and production without turning SEO into a rushed or low-quality content sprint.

The risk is not that SEO takes six to nine months. The risk is starting that six-to-nine-month clock too late.

On enterprise compute buyers, your point makes sense. If Livepeer cannot yet support SLAs, uptime guarantees, compliance review, and support contracts, then broad enterprise lead generation would be premature.

I would narrow the target for now. Rather than enterprise buyers, the first demand layer should probably focus on self-serve developers, AI/media builders, startups, indie teams, creative tooling companies, and technical users who can adopt before a full enterprise motion exists. That seems more aligned with the Developer Dashboard and product-led onboarding path.

I also think there is a B2C or prosumer angle that should not be lost in the discussion.

I agree that broad consumer marketing for the raw protocol would not make sense. But if the new product layer includes user-facing AI/media tools with strong UX and UI, then B2C or prosumer demand could be an important part of the growth strategy.

I also see B2C and prosumer products as an advantage for product development, not only for marketing.

Compared to enterprise infrastructure sales, user-facing products can often reach a larger market, have a lower adoption barrier, and create faster feedback loops. That matters because time is a real constraint now.

B2C and prosumer markets also often have broader keyword landscapes and higher search volume than narrow infrastructure categories. That can be useful not only for acquisition, but also for market filtering.

Through SEO research, keyword clustering, search-intent analysis, and content testing, the community can quickly identify which problems have the largest demand, which use cases are easiest for users to understand, and which product angles create the strongest pull from the market.

This kind of research can also be partly supported through scoped bounties, as long as the Foundation keeps ownership of positioning and quality control.

The value is not only that content may rank later. The value is that search data can help filter product priorities earlier. If certain B2C/prosumer pain points show much stronger demand, clearer intent, and easier conversion paths, then product positioning and even product development can be aligned more closely with that market signal.

That does not guarantee demand, but it reduces guesswork. It helps the ecosystem build toward problems people are already searching for, rather than only pushing products from the inside out.

If a product has strong UX/UI and solves a clear problem, users can test it, share it, react to it, and create visible usage much faster than an enterprise pipeline that requires SLAs, compliance review, procurement, and support contracts.

That does not mean Livepeer should abandon developers or infrastructure. It means that for the new product layer, B2C/prosumer use cases may help the ecosystem learn faster, validate demand faster, and create social proof faster.

This could be especially useful for AI/media products, creator tools, music-related tools, and other user-facing workflows where the product can be understood without deep protocol knowledge.

These users do not need to understand the underlying protocol, orchestrators, staking, or network infrastructure. They need a product that solves a clear problem, feels easy to use, and creates a reason to come back.

That matters for two reasons.

First, B2C and prosumer products can often create faster feedback loops, more social proof, and more shareable product moments than infrastructure-first marketing. If a product is useful and easy to understand, users can show it, share it, and create visible demand around it.

Second, it helps bridge the communication gap with delegators. Many delegators are not deep technical infrastructure users. If the narrative is only about compute, routing, dashboards, payment tooling, and developer infrastructure, it becomes hard for non-technical token holders to understand what is being built and why it matters.

A clearer product-level story around user-facing tools could help delegators identify with the ecosystem more strongly. That can improve community engagement, social proof, and confidence, as long as the product usage connects back to measurable network fees and value accrual.

So I would separate the strategy into two layers:

  1. Developer and builder demand, where the Developer Dashboard, payment tooling, onboarding, and lower-funnel readiness are essential.
  2. B2C/prosumer demand, where strong UX/UI, simple product storytelling, social sharing, and user-facing AI/media tools can help create faster visible adoption.

The key is that both layers should connect back to Livepeer network usage and fee generation where technically possible.

On affiliate and partner growth, I understand the concern. A broad affiliate program can become operationally expensive and attract the wrong incentives. I would not push for a large open-ended affiliate layer right now if the team believes it would create too much operational burden.

A better version may be smaller and more controlled: targeted bounties, contributor tasks, or a limited partner test tied to specific deliverables, such as high-quality tutorials, developer guides, comparison pages, product explainers, qualified feedback from relevant builders, or validated B2C creator/media usage.

One possible middle ground would be to test this through a trusted affiliate or partner platform such as Awin, rather than building all tracking, attribution, payout administration, and publisher management from scratch.

That would not remove all operational work, but it could reduce some of the issues you mentioned: attribution, payout handling, partner screening, tracking, and visibility into where the conversion happened in the funnel.

It would also allow Livepeer to focus on a specific type of partner, not broad low-quality affiliates. For example, strong content affiliates or niche publishers at the top of the funnel, where the value is not only the final signup but also educating a relevant audience, shaping demand, and showing which use cases attract qualified interest.

So I agree that a broad affiliate program is probably not the right move today. But a small, controlled test with selected content partners, clear attribution, strict quality rules, and funnel-level analysis may still be worth considering later, especially once the lower funnel is ready.

The most important point for me is that new product demand should connect back to the Livepeer network economy.

If the new product layer generates usage, then where technically possible that usage should generate measurable fees through existing or easily extendable crypto-native rails, whether ETH, stables, or another structure. Otherwise there is a risk that products create value, but delegators remain exposed to inflation, market downside, and lost demand without seeing how new product traction supports the network economy.

So I think the key questions are:

  • Which new product paths are closest to real usage?
  • Which of them can generate measurable fees?
  • How will that fee generation be surfaced publicly?
  • How does product traction connect back to the network and delegators?
  • What lower-funnel milestones need to be completed before top-of-funnel campaigns scale?
  • Where does B2C/prosumer demand make sense for user-facing products, and where should the focus stay on builders and developers?

On community activation, I’m glad this is on your radar. Passive delegators are not only a governance issue. They are also an underused distribution and credibility layer.

Builder spotlights, delegator spotlights, product explainers, and clearer non-technical updates could help delegators understand what is being built, why it matters, and how product usage connects to the health of the network. That can create better discussion, more social proof, and more informed governance participation.

So I think we are mostly aligned on the sequence:

  1. Finish the lower-funnel product foundations.
  2. Make the marketing strategy legible to the community.
  3. Prepare SEO and content infrastructure in parallel.
  4. Use B2C/prosumer keyword research and search-intent analysis to identify the largest demand pools and strongest product angles.
  5. Focus early demand on self-serve builders, product-led adoption, and selected B2C/prosumer use cases where strong UX/UI can create faster feedback, social proof, and visible product usage.
  6. Avoid premature enterprise sales until the network can support the expectations that come with it.
  7. Avoid a broad affiliate program for now, but consider smaller controlled tests with trusted platforms or selected content partners later.
  8. Use community activation to make delegators more product-aware.
  9. Make sure new product revenue connects back to the network economy and delegator alignment.

Thanks again for the thoughtful response. The added context makes the direction clearer, and I look forward to seeing the Foundation’s marketing strategy stated more plainly as it develops.

Hi @dob & @salinsug, how do you wish to proceed, and within what timeframe? From my POV, we have tight deadline.

Hey @Dude , welcome to the Livepeer forum. Even though this reads like AI, I agree with you that whether this is AI-assisted, agent-operated or written manually, an idea should not be dismissed because of how it was drafted.

The issue is that this is framed like governance.

If “RFC” means request for comments, then it should be treated as a discussion. If it is intended as a treasury proposal, the normal path is to state what you are proposing, who is proposing it, who your team is, your experience, the deliverables and the resources you’re asking for. Then the community can evaluate it through the proper process.

This reads as a list of things Livepeer should do and tries to assign work to people who have not agreed to do it. That is not governance. This distinction matters even more if AI or agents are involved, because they can produce long lists of plausible workstreams like this one very quickly.

So if you want to make a proposal, please use the normal approach: say what you will do, what you need, and what decision you are asking the community to make.

If you want me to be part of a proposal, reach out by email and I’m happy to discuss it there. If this is not a proposal, I’m happy to respond to the broader strategic points as discussion, but it should probably be moved out of the Treasury section. Cheers.

Hi b3nnn,

Thanks for the clear feedback. That distinction makes sense.

My intention was to frame this as an RFC in the literal sense: a request for comments and discussion, not as a formal treasury proposal or a request for the community to approve funding.

I agree that if this becomes a proposal, it should follow the normal structure: who is proposing it, what the team is, what will be delivered, what resources are needed, and what decision the community is being asked to make.

I also take your point that the post should not read as assigning work to people or groups who have not agreed to it. That was not my intention. The goal was to surface strategic questions and possible workstreams around demand, product adoption, SEO, community activation, and how new product usage could connect back to Livepeer network fees and delegator alignment.

If Treasury is the wrong category for this stage, I’m fine with moving it to a more appropriate discussion section.

For now, I would prefer to treat it as a strategic discussion, not a proposal.

That said, I do think one smaller and more concrete idea may be worth exploring separately: a scoped SEO and market-demand research bounty.

The goal would not be to launch a broad marketing program or claim that SEO can solve demand quickly. The goal would be to identify where real external demand already exists, using keyword volume, search intent, competitor research, B2C/prosumer opportunity mapping, developer use-case research, and product-angle analysis.

This could help the community filter which product directions, landing pages, content topics, and user-facing use cases have the strongest market signals before larger product or marketing investments are made.

Because time is a real constraint, I think the workstreams that can run in parallel should run in parallel. SEO takes time to compound, but market research and opportunity mapping can start earlier and can help reduce guesswork.

So to clarify:

  • the current thread can be treated as strategic discussion
  • I am not asking the community to approve a treasury proposal here
  • I am not assigning work to anyone
  • if there is interest, I may later reframe one narrow piece into a proper proposal with scope, deliverables, timeline, budget, and decision points

Thanks again for clarifying the process.