Pre-Proposal: Network Engineering SPE II

Operate Track Monthly Update

The Operate track of the Network Engineering SPE II is building shared tools to support the SPE Build track, the Livepeer Agent, and other ecosystem partners. These tools cover funding access, discovering capabilities, executing work, and accounting for network costs, while partners retain control of their applications, identity systems, and customer billing.

September’s work focused on three projects: Clearinghouse Batteries, Livepeer Node, and E2E Runner. This update covers their progress, including follow-up work through the first days of October.

Livepeer Node is a set of tools focused on current network needs: Live Runner support, remote signing, and protocol management. It gives us a place to rapidly evolve these functions without risking disruption of existing go-livepeer workloads supporting transcoding, Live AI video, batch AI, BYOC and Scope. The focus on the Live Runner allows us to remove most of the media-processing and legacy application dependencies makes this stack easier to build, maintain, and extend.

Livepeer Node Features Implemented
  • Node includes separate orchestrator, signer, and chain CLI executables.
  • The orchestrator handles runner registration, discovery, sessions, application traffic, payments, and ticket redemption.
  • The signer handles payment issuance, discovery, authorization, and optional accounting events.
  • The chain CLI supports account creation, staking, funding, rewards, governance, and other protocol operations without requiring a running go-livepeer node.

Clearinghouse Batteries is a tool for allocating and managing usage credits for developers. It is the accounting counterpart to the remote signer: the signer issues network payments, while the clearinghouse authorizes access and records spending against developer allocations.

Clearinghouse Features Implemented

*Grant and allocation management

  • API keys and revocation
  • exact USD/ETH accounting
  • HTTP management APIs
  • on-chain deposit/reserve and settlement reporting.
  • =SQLite storage
  • Embedded Kafka broker (optional)
  • Docker Compose example with a Livepeer Node signer, persistent storage, backups, and a restore drill.
  • All this helps reduce the number of services an operator needs to run in order to support payments on the Livepeer network.

E2E Runner tests interoperability using real processes and an on-chain devnet. Its matrix includes go-livepeer and Node signers and orchestrators, Python and Go runners, and Clearinghouse Batteries.

E2E Features Implemented
  • On-chain (paid) and off chain jobs
  • Matrix covering all four signer–orchestrator pairings across both runner SDKs: go-livepeer orchestrator, go-livepeer signer, node signer, node orchestrator, python runner, golang runner.
  • Exercises persistent and single-shot sessions, hourly and fixed pricing, and proxy modes: 64 combinations in total.
  • Additional tests cover authorization, accounting, revocation, media transport, restart behavior, and payment recovery.
  • Docker Compose support provides a reproducible, TLS-enabled environment with containers for each component and a fresh devnet.

Compatibility is built around the existing Live Runner registration, session, transport, and payment interfaces. This lets us exercise mixed Node/go-livepeer deployments and preserve SDK integrations, supporting gradual adoption. Testing has already identified issues and led to compatibility fixes; validation of the full matrix remains in progress.

Coming Up

In October, we plan to kick off the network resilience and reliability work. This includes collecting metrics, logs, and job events; building public performance dashboards and failure-diagnosis tools; developing capability validation and continuous network probing; and onboarding operators into the observability system.

We’re looking for an experienced engineer to help with this work on a short-term contract. See the Observability and Reliability job description.

5 Likes