The problem The Explorer now sits on a stable, maintainable foundation following recent RFP work. However, it remains visually and functionally disconnected from the Foundation’s surfaces and limited in what it surfaces to operators and delegators. It was built for an earlier era of the network and has not yet been fully realigned with current needs. Delegators making stake decisions today have less information than they should. Operators don't have the observability they need. The surface does not reflect the current state of the network or the direction the Foundation is moving. For the largest cohort of existing Livepeer participants — the people who stake, delegate, and operate — the Explorer is the Foundation's front door. Leaving it in its current state is a visibility liability that undercuts the trust the rest of the quarter's work is trying to build. Operators with better observability can demonstrate performance; delegators with better data can reward it. Both sides of that loop are currently underserved. The direction Restore the Explorer as the permissionless participation portal. The canonical Foundation-owned surface for operators and delegators, aligned with the Foundation's design system and current network reality. Q2 scope: Tailwind restyle aligned with the Foundation's design system and the Developer Portal surface. Improved default network stats — the data delegators and operators actually need to make decisions, drawing on the subgraph upgrades and metrics framework developed through the NAAP metrics/SLA process. An AI-native interface for stakeholders to query network data, surface custom dashboards, and get answers grounded in live on-chain state — not generic context (#584). LIP voting transparency — surfacing proposal status, voting history, and participation rates directly in the Explorer (#482). A native notification system for delegators and operators — reward events, proposal activity, stake changes (#319). This list is a starting point — community members are invited to propose additions during the scoping window. Work sequences after design system consistency between the Developer Portal and Explorer is specified. The two surfaces share design tokens; they do not share information architecture. Why now The Explorer is the most visible artifact of the network for the audience with the largest standing investment in it. Every week the Explorer remains in its current state is a week the Foundation signals that existing participants are not the priority. That is not the signal the quarter's strategy warrants. Funding this through the Network Engineering SPE provides a path to a retainer-based team that owns the repository and delivers against a clear participation-portal vision — rather than treating the Explorer as spot work between other priorities. What the community helps scope The problem statement is settled. The direction is settled. The scoping work ahead is: Which features matter most to delegators vs. operators. Current state assumes one surface serves both audiences equally; that assumption deserves testing. How AI
Opportunity Issued: 2026-04-17 (Q2) Roadmap State: Now Launch Target: 30 June 2026 Owner: Steph (Narrative) · Rick (Technical) Funding Mechanism: Foundation Canon source: Five-Minute API— PRFAQ 1. Purpose What specific problem does this solve? How does it align with and advance the vision? Why now? Livepeer has had GPU supply, network economics, and nine years of production architecture — but the path from "I heard about Livepeer" to "I'm running a job on it" still takes 15–30 minutes of stitching docs, orchestrator choice, and tooling. For the "edges" audience — technically fluent, friction-tolerant builders working in real-time AI video — that friction is the single biggest barrier to adoption. The Five-Minute API closes that gap: a single authenticated interface that takes any developer from the Livepeer docs to their first inference call in under five minutes, from any MCP-compatible tool. It is the measurable claim the Developer Dashboard makes on 30 June 2026 — the public proof that "the open network for real-time AI video" is something a developer can reach in minutes, not a positioning slogan. Why now: it is the Foundation's Q2 narrative anchor. Cost is already strong, reliability is a longer arc, and ease of use is the lever the Foundation can move on its own timeline this quarter. 2. Outcome What does overall success look like? What are the tangible key results? Overall success is when an independent developer — with no prior Foundation contact — can go from the docs to a first inference call in under five minutes (measured on a clock, single take, fresh environment), and a BYOC orchestrator can deploy a custom container and serve paid work without Foundation humans in the loop. Launch-day key results (30 June 2026): Five-minute path live — docs → discovery → authentication → first inference call, end-to-end through the Developer Dashboard. MCP integration working from at least Cursor and Claude. Three external builders (not currently in the ecosystem) publicly confirm the claim from their own workstations. Two independent GPU providers deploy custom containers via self-serve BYOC and serve paid jobs with zero Foundation intervention. Reference Python SDK, MCP server, and public decision log all shipped. Single unedited demo — one take, time on the clock. 3. Requirements Must Have Discovery, authentication, and payment plumbing — protocol-level path that reaches the network with no enterprise contract and no vendor lock-in. MCP server — published and demonstrated from Cursor and Claude on launch day. Reference Python SDK — first-call path documented and reproducible from a fresh environment. BYOC self-serve interface — independent GPU providers deploy custom containers without Foundation humans. Live unedited demo — single take, fresh environment, wall-clock measurement. External validation set — three external builder confirmations + two BYOC orchestrator deployments, captured and reviewed before 20 June, published on
Roadmap state: Now Opportunity Status: In progress Owned By: Qiang Han Funding Mechanisms: Livepeer Foundation, Livepeer Inc + Network engineering funding SPE 1. Purpose For the Agent to run at scale, the network has to be ready: orchestrator software, capability onboarding, quality of service, and payments clearing. This opportunity resources the five-milestone framework work that gets a cohort of community orchestrators live onchain on the new stack, opening future demand paths beyond the Agent. 2. Outcome Overview: A cohort of community orchestrators is live onchain running the new software, capabilities are adapted and standardised, performance is observable, and payments clearinghouse work is underway. Key Metrics To Measure The Outcome Against: Five to eight community orchestrators onboard capabilities end to end and report success Real traffic routed to onboarded orchestrators, with performance observable Payments clearinghouse work underway 3. Requirements Live Runner and Go SDK shipped as a production release No-code, config-based capability onboarding exposed to operators Real-world validation: real traffic and feedback from onboarded operators Quality-of-service monitoring with routing by measured performance Billing and metering that fits every pricing model, with the Daydream key requirement removed Community and in-house dashboards
Roadmap state: Now Opportunity Status: In progress Owned By: Doug Petkanics, Livepeer Inc Funding Mechanism: Funding from Livepeer Inc / Foundation 1. Purpose Livepeer 2.0 has presented a series of key protocol changes: Burn-Mint Equilibrium, the stake-elected validator set, fixed node bonds, and extended unbonding. These now must be specified, simulated, and supported by the community before any upgrade vote. This opportunity resources the design and governance process that gets us there, carrying forward only upgrades with demonstrated support. 2. Outcome Overview: The 2.0 design is specified, simulated, and supported. The litepaper has been public for a month, the community process has worked through the open questions, and an economic simulation is completem. The completion will open the door to core protocol development and an audit before an LIP package is proposed. Key Metrics To Measure The Outcome Against: Litepaper published and public for at least four weeks, with open questions worked through Economic simulation completed and observable by the community Only upgrades with demonstrated community support carried into an LIP package 3. Requirements Opinionated litepaper specifying recommended mechanisms and initial parameters Structured community feedback period that resolves the open questions Protocol prototype simulation using agents to play network roles, observable by the community Security hardening and audit path defined for candidate production code Clear governance route from supported design to an LIP package Migration plan outline for moving the network fully onto 2.0
Who Are You? Name: John Mull Your connection to this problem (Why did you spot it? Are you affected by it? Do you work in the area it touches?): Core NaaP engineer actively building with the SDK. Over the past three months, John and Josh have been the only developers using it — this is a direct blocker to wider adoption. What Is The Problem? One specific sentence. Not a theme — the actual friction or gap. There is no general-purpose payment, usage metering, or authentication layer that multiple independent apps can rely on, which means non-core developers cannot build or monetize products on the Livepeer Network today. Why Does It Matter To The Ecosystem? 2–3 sentences. Who is affected and how? What is the cost of leaving it unsolved? Is there a window or urgency? Without a payment clearinghouse or remote signer, every developer is forced to use the existing go-livepeer gateway and long-lived API keys — a model that is incompatible with desktop apps, agentic tools (VS Code, Claude Code, BlueClaw), and OAuth 2.0 + OIDC device flows. This blocks the entire community from building with the SDK and makes it impossible to ship strategic initiatives like x402 payment support and MCP server tooling. The window is urgent: the NaaP roadmap and agent ecosystem integrations are waiting on this foundation. Who Else Feels This? Name at least one other person, persona, or group who experiences this problem. All third-party app developers trying to build on Livepeer. Specifically: teams building desktop apps (e.g. Scope), agentic framework integrators (VS Code, Cursor, BlueClaw), and any developer who needs a billing or usage API for their product. What Have You Already Tried or Seen? Prior attempts, related Forum threads, GitHub issues, Discord conversations, or past Advisory Board recommendations. Josh Allmann scoped a payments clearinghouse design document and roadmap as part of the Transformation SPE workstream (remote signer prototype merged into go-livepeer via PR#3822 and PR#3791). A TurnKey USDC pre-auth integration has been prototyped as a potential third-party auth option. DayDream’s current auth model (long-lived API keys, single-domain redirect) has been identified as insufficient for multi-app or desktop use cases. What Does A Good Outcome Look Like? Concrete and observable. "X goes from Y to Z" or "teams can now do X without Y." At least 2 demand partners onboarded (1 web app + 1 desktop app) using the clearinghouse and SDK to access the Livepeer Network. A working OAuth 2.0 + OIDC login flow demonstrated in a desktop or third-party integration (e.g. VS Code, BlueClaw, or Cursor). A billing and usage API that lets apps show users their consumption, and lets developers view usage in the clearinghouse dashboard. HTTP 402-driven automatic top-up flows working on the remote signer proxy for at least one integration. What You Don't Know Yet 2–4 genuine unknowns you’d want the group to help answer. Where exactly is user prepay and ticket valuation measured — in the proxy, or in the value of the actual claimed ticket? This is critical for correct micropayment accounting on a shared remote signer. What is the right account model for metering and billing (e.g. per-user wallet addresses on the remote signer side)? Which third-party auth and signing providers (Turnkey, Privy, others) are viable, and what is the minimal interface needed if developers bring their o
(March → April) Output: An MVP of the NaaP platform to prove the Livepeer network can perform popular workflows, at low latency, with the needed scale, at market-best prices, without a large amount of technical overhead for app developers. To Ship: Shell App Foundation; ****dashboard overview; shared UI components; a staging and production infra that is open to community to build, test, and deploy Solutions to the NaaP; successful integration with design partner (Daydream). Enables: Live NaaP platform with Solutions Providers marketplace; community ability build and deploy custom solutions; hypothesis-driven development approach. Features & User Stories (1) Network Overview As a network user, I can see the network overall metrics using overview dashboard As a network user, I can get an overview of the pricing of different pipelines As a network user, I can track the usage of top pipelines As a network user, I can easily query network data to see more detailed performance metrics from the network (2) Developer API As an app developer, I can create an API key per billing provider. As an app developer, I can see my overall usage tracking from all signers As an app developer, I can see my usage tracking per signer (with breakdown of project, and api key) As an app developer, I can view and search list of models that supported by the network. As an app developer, I can see my usage tracking per model (with breakdown of signer, project, and api key) (3) Community Hub As a network user, I can get feedback on new community-built plugins or features As a network user, I can request new community-built features to the network product (4) Capacity Planner As a Service Provider or App Developer, I can request GPU capacity over an allotted time period at a given price. As an Orchestrator, I can soft commit and respond to a GPU capacity request.
Roadmap state: Now Opportunity Status: In progress Owned By: Steph Alinsug, Livepeer Foundation Funding Mechanism: Foundation & Inc funded + go-to-market funding proposal, informed by validation evidence 1. Purpose Livepeer Agent is a custom MCP connector for creators and marketers who need agents to generate, edit, and augment video affordably, across models, with high creative control. This opportunity validates it with real target users in public and drives it from closed alpha to open beta, so any go-to-market funding proposal is grounded in demand evidence rather than promises. 2. Outcome Overview: Target-user validation is explored in public and reflected in the product's core capabilities and user experience. Livepeer Agent is in open beta with its first weeks of real market data to inform the direction of the GTM. Key Metrics To Measure The Outcome Against: Successful install and repeated runs of the core loop: prompt → generate → output Closed beta cohort activated and converting into repeated use Open beta market data captured, or explicit launch gates defined 3. Requirements Demand-validation interviews with target creators and marketers, surfaced publicly One-click install paired with an automated onboarding funnel Closed beta launched at the in-person demo (NYC Creative AI Forum) Content and growth engine producing weekly market signal First weeks of open beta market data Go-to-market funding proposal informed by validation evidence
Proposed By: Adam Soffer, Steph Alinsug Staging URL: https://livepeer-website.vercel.app 1. What Is The Problem? Livepeer's website is out of date, falls short of professional standards, and the embedded Primer only tells the transcoding story — failing to communicate what Livepeer actually is today (a real-time AI video infrastructure network) and leaving developers, ecosystem partners, and community members without a credible entry point that reflects the project's current direction and ambition. 2. Why It Matters To the Livepeer Ecosystem Livepeer is at an inflection point: the real-time AI video opportunity is real, Daydream is live, and the gateway platform is taking shape — but the primary public-facing surfaces tell a years-old story and don't reflect the quality of the work being done. Every week they stay up, they undermine trust with developers evaluating the network, partners doing due diligence, and community members trying to articulate what Livepeer is. The window matters because the AI video market is forming now, and first impressions with the right builders will compound. 3. What Does Success Look Like? Developers landing on livepeer.org understand within 60 seconds what Livepeer is today — a real-time AI video infrastructure network — who it's for, and how to get started The Primer functions as a standalone, shareable explainer covering the full scope of Livepeer's evolution, not just transcoding The Foundation has a live, professionally presented surface to iterate copy and positioning
This roadmap item was discussed during the latest Water Cooler. The overlap Onchain Treasury Allocation Improvements should be recognised, but potentially works alongside it as a short-term solution. 1. What is the problem to solve? The current SPE model creates significant friction for smaller, community-driven engineering contributions: Writing a full proposal requires a major time investment before any work begins The onchain vote cycle adds weeks or months of delay for work that could start quickly For scoped initiatives in the $2k–$20k range, the overhead-to-value ratio is simply too poor — community contributors won't run a full SPE process at that scale This friction has become more acute as AI tools now allow contributors to build and test MVPs far faster than before The result: genuinely useful, well-supported work doesn't happen — not because the community doesn't want it, but because there's no efficient path to fund it. 2. Why is solving this problem key to the Livepeer ecosystem? Smaller experimental initiatives and quick engineering wins are often where early, high-signal progress happens. If the only funding path available requires months of process overhead, contributors either work for free, deprioritize the work, or move on entirely. Losing active contributors — and the compounding value of their momentum — is a real cost to the ecosystem. A more frictionless path to funding smaller initiatives would align disbursement with the natural cadence of community proposals and keep contributors engaged and productive. 3. What could success look like? A delegated, standing funding pool for small-to-medium engineering initiatives, validated through the existing community roadmap process, where: Contributors can apply for funding for quick wins and experiments without the full weight of a standalone SPE Decisions are made transparently and without unnecessary bureaucracy Funding speed matches the speed at which good ideas can now be executed The above is just a potential solution and it is all open for discussion. 4. What are the outstanding questions to discuss? Does this problem resonate — are there contributors who've shelved ideas because the SPE path felt too heavy? What's the right pool size on a quarterly basis to be meaningful without being wasteful? Should the funding mechanism be proactive, retroactive, or some mix depending on t
Understand the existing Livepeer system: map how decisions actually get made (vs. how stakeholders believe they're made), identify where power and narrative ownership currently sit, and surface the story across Foundation, Inc, Gateway and contributor touchpoints
Roadmap state: Now Opportunity Status: Completed Owned By: Josh Allman, Rick Staa (validation and merge) I Funding Mechanism: Livepeer Inc + Network Engineering funding SPE Primary artefact: doc/live-runner.md in go-livepeer 1. Purpose Before this work, adding a compute capability to the network meant one of two things: writing Livepeer-specific code into go-livepeer and the AI runner, which only the core team could do, or standing up a full gateway in front of the SDK. Roughly 170 capabilities were live and all were sourced centrally, with each new one adding to a core-team queue. Live Runner lets an orchestrator put an ordinary HTTP service behind the network. The service is registered, health-checked, discoverable, reverse-proxied and priced, and needs no Livepeer-specific code for basic passthrough. The paired SDK covers the client side: discover an orchestrator, reserve a session, call it, settle payment, no gateway required. This is Milestone 1 of the Livepeer Agent Framework. The other four milestones (capability onboarding, real-traffic validation, quality-of-service routing, billing and metering) all build on the same plumbing, so shipping it as one tagged release stopped them being built on branches that would keep moving. It also sat on the critical path for the Agent's closed beta and the orchestrator onboarding cohort. 2. Outcome Overview: One referenceable release of Live Runner and the paired SDK, consolidated from six to seven months of prototype work across the BYOC, stream diffusion and Scope PR stack, with operator-facing reference documentation. An operator can attach an existing HTTP, SSE, WebSocket or trickle application as a container alongside a running orchestrator and have it discovered, priced onchain and serving paid sessions. Complexity moves out of go-livepeer and ai-runner, and downstream milestones build against a fixed surface. Key Metrics To Measure The Outcome Against: Tagged release of Live Runner and the Go SDK merged to go-livepeer master, with reference documentation published. Met (Live Runner 2026-07-24, paired SDK 2026-07-27) Both registration models (static and dynamic) and both session modes (persistent and single-shot) available and documented. Met An off-the-shelf HTTP container can go behind the network with no Livepeer-specific application code for basic passthrough. Met Onchain discovery and payment working end to end, with USD-denominated pricing converted and settled through probabilistic micropayments and usage tracked per session. Met (LiveRunner 0.9.0 tracks billable seconds;
What Is The Problem? The Livepeer subgraph, the data layer that every Explorer view, governance surface, delegator tool, and tokenomics analysis depends on, has not had a structured audit in a long time, so we lack a current baseline of its performance, technical debt, and indexing gaps before building further on top of it. The concrete first gap: the subgraph cannot efficiently compute delegator or orchestrator stake and earnings per round, which holds back income and tax reporting and any time series view. Why Does It Matter To the Livepeer Ecosystem? The subgraph is shared infrastructure used by all downstream surfaces, so its performance and correctness affect every consumer. The work is two steps. First, audit the subgraph and add tooling to measure size and indexing performance, giving us a known baseline before adding more to it. Second, ship the per-round stake and earnings feature on that base. BuilderDAO already identified performance improvements while building two earlier features for us, so concrete issues already exist. Auditing first lets this feature and later additions be implemented and measured against a known baseline rather than added to an unmeasured one. Without it, we have no visibility into whether new features are implemented efficiently or are adding technical debt, since we cannot measure their impact. What Does Success Look Like? Repeatable tooling to measure subgraph size and indexing performance, runnable locally and in CI, with a baseline captured. The audit produces a named, prioritized list of indexing gaps, missing or mis-modelled events, and technical debt, so future work can build on a known foundation. Per-round delegator and orchestrator stake and earnings are indexed, accurate, and queryable, with a linked deployment and sample query. Explorer maintainers confirm the indexed data can power income and earnings views. Open Questions Does anyone see objections to doing the audit first to unlock quicker feature enablement on the subgraph, for the improvements listed above or others on the roadmap? Is BuilderDAO the right partner to do this work? Do people see value in per-round delegator stake and earnings tracking?
Purpose What is the specific business problem that this solves? How does this align with and advance the vision? And why should we be working on this now? Livepeer needs to define its core opportunity which can form the foundation of a GTM effort. Since its launch in 2017, Livepeer’s mission has been to offer the world’s open video infrastructure, building a respected and trusted brand rooted in decentralized video technology enabled by cryptoeconomic primitives. More recently, Livepeer has expanded into AI through multiple ecosystem initiatives, but without a dedicated GTM effort to unify them around a clear network value proposition. Defining the core opportunity now is necessary to align these efforts, focus resources, and prevent further fragmentation as the ecosystem grows. Outcome What does overall success look like in one paragraph? And what are some of the tangible key results that the submissions should focus on? Success means delivering a detailed market intelligence report which can be used for lead generation. Building on detailed interviews with prospective customers, the report should equip the Livepeer ecosystem with a clear overview of the market landscape and a breakdown of ideal customer profiles (ICPs) with clear value propositions for each. All of the work should tee up the core teams behind the Livepeer network’s GTM. For Network ProdEng, the report should provide direction for core requirements and competitor benchmarking. For Livepeer Marketing, it should give clear ICPs to target. For BD, it should provide a pipeline of potential customers and the basis for a sales deck. Key Metrics To Measure The Outcome Against: Engagement from content pieces published Number of new customer opportunities identified Total number of new customer interviews Leads generated by the report
Purpose What is the specific business problem that this solves? How does this align with and advance the vision? And why should we be working on this now? Livepeer has acute pain points around current capital. On chain liquidity is low, leaking value of LPT holders through high slippage. Inflation is high against external benchmarks, which acts as a barrier to new participants. The treasury is not accumulating new LPT and the current treasury is not actively deployed and so does not generate any yield. We need to address all of this in a holistic way now, as actions in one area can have unintended second-order consequences if not managed carefully. Outcome What does overall success look like in one paragraph? And what are some of the tangible key results that the submissions should focus on? Overview: Overall success is creating a working group that collaborates to assess the ecosystem holistically, enabling clear decision-making and actively managing ecosystem capital through more strategic deployment. Key Metrics To Measure The Outcome Against: Improvements in liquidity depth and market efficiency. Reduction of treasury concentration risk and clearer capital allocation strategy. Measurable progress toward sustainable inflation and data-driven utility models.
Purpose What is the specific business problem does this solve? How does this align with an advance the vision? And why should we be working on this now? Restore the Livepeer Explorer to a secure, maintainable, and high-performance state, as the current deprecated and unreliable Explorer limits visibility into the network, introduces security and stability risks, and prevents informed decision-making; recent outages, poor performance, and data quality issues make this work urgent to re-establish a trusted source of truth and enable future network and governance dashboards. Outcome What does overall success look like in one paragraph? And what are some of the tangible key results that the submissions should focus on? Overview: Overall success means the Explorer becomes a clean, secure, well-tested, high-performance codebase with no critical bugs, modern dependencies and a clear backlog. It delivers faster UX, a simplified data layer, and integrated voting transparency. It emerges as trusted infrastructure with a 6-month roadmap and an active maintainer team. Key Metrics To Measure The Outcome Against: Resolution of existing issues in the Explorer repository. Degree of improvement in voting transparency based on the new voting-transparency feature. Degree of improvement in data quality, performance, codebase health, and security compared to the initial state.
Purpose What is the specific business problem does this solve? How does this align with an advance the vision? And why should we be working on this now? Lack of trusted, network-wide performance and demand metrics makes it difficult to assess reliability, surface bottlenecks, or confidently onboard real-time AI workloads. Without clear visibility into latency, success rates, capacity, and workload behavior, Livepeer cannot demonstrate production readiness, establish meaningful Service Level Agreements (SLAs), or give builders confidence to deploy real workloads. To advance the real-time AI vision, Livepeer must first measure what matters by establishing unified, trustworthy network observability. A shared data foundation enables consistent SLA tracking, informs scaling and incentive decisions, and gives operators, gateways, and developers a clear, objective view of network performance as demand grows. Prior work: Builds on ecosystem research highlighting fragmented network data and the need for unified, network-wide observability. Outcome What does overall success look like in one paragraph? And what are some of the tangible key results that the submissions should focus on? Overall success is when Livepeer has a unified, trustworthy observability foundation for real-time AI and video workloads—defined by clear metric schemas and open data pipelines that aggregate network-wide performance and demand data into a single, queryable source. Orchestrators, gateways, and the community can access consistent real-time and historical views across key metrics, enabling analysis, insight, and action. This foundation directly enables SLA scoring, informed orchestrator selection, and continuous reliability improvements as demand grows. Key Metrics To Measure The Outcome Against: Unified Metrics Coverage: Number of core performance and demand metrics defined in a standardized schema and made available network-wide. Data Source Integration: Number of distinct network data sources integrated into a unified aggregation layer and exposed through documented access paths. Observability Completeness & Reliability: Defined indicators showing freshness, completeness, and consistency of network telemetry (e.g. data latency, missing dimensions, ingestion success rates). Reproducible Test Load Results: Availability of standardized test load execution producing repeatable, independently verifiable measurements for key SLA metrics.
Purpose Which specific business problem does this solve? How does this align with and advance the vision? And why should we be working on this now? Livepeer’s protocol secures meaningful on-chain value and increasingly supports real-time AI workloads that depend on reliability, safety, and predictable upgrades. Today, vulnerability response, protocol maintenance, and core development rely on limited shared resources, slowing iteration and making it harder to proactively evolve the protocol as the network grows. To strengthen Livepeer’s long-term foundations, the network needs a dedicated, always-available protocol development and security function with clear ownership, coordinated workflows, and the ability to respond quickly to issues, ship safe upgrades, and maintain essential infrastructure such as a public testnet. Establishing this structure now ensures the protocol remains secure, resilient, and scalable as demand increases. Outcome What does overall success look like in one paragraph? And what are some of the tangible key results that the submissions should focus on? Overall success is when Livepeer operates a clearly defined, continuously supported protocol development and security function. Immunefi response and upgrade workflows are formalized and resourced, a stable public testnet is launched for validation, and a lightweight triage and release pipeline is operating and used continuously ship prioritized backlog upgrades. This creates a predictable, accountable foundation for safe protocol evolution as the network scales into transcoding and real-time AI workloads. Key Metrics To Measure The Outcome Against: Immunefi Response Readiness: A defined and resourced workflow enabling timely triage and patch preparation. Public Testnet Preparedness: A stable testnet launched or fully scoped with a clear operational plan. Triage & Release Pipeline: A lightweight prioritization and release process established and in active use. Backlog Delivery Velocity: One or more prioritized backlog features or patches progressed through triage → testing → deployment per release cycle.
Output: A dashboard with an overview of core network data (aligned with Cloud SPE). To Ship: Gateway audit; automated network testing and visibility; metrics collector; network-wide orchestrator data dashboard. Enables: Dashboard overview with key network data; gateway manager dashboard with SLA configuration. Features & User Stories Network Data As a network user, I can see an overview of core metrics NaaP Platform As a network user, I can understand what the NaaP Platform is and how to get involved