Introduction
In January 2026, the community approved the Protocol R&D SPE proposal, establishing a dedicated, continuously staffed function for protocol security and development. Sidestream took on the role of Protocol Engineering & Security Partner, working under the guidance of the Livepeer Foundation and the Security Committee.
The mission is simple to state but demanding to execute: Provide secure, resilient, and continuously improving protocol foundations for Livepeer. Over the six-month term, running from Q1 through the end of Q2 2026, we committed to three things: Providing continuous first-response security operations for the Immunefi bug bounty program, shipping protocol updates based on a yet-to-be-established release process while building a backlog of future release candidates, and delivering a testnet.
This retrospective reflects on what was delivered, what was not, and what we learned.
One general note applies throughout: Due to the sensitive nature of vulnerability work, many concrete artifacts (processed reports, assessments, mitigation proposals) were only shared with the Security Committee. However, where possible, we link the public traces of our work, like on-chain transactions and public announcements.
Commitments Delivered
1. Core Protocol Security Operations
We established a new Immunefi triage pipeline and operated it as first responder for the entire term, with continuous team-on-duty coverage, including weekends and outside office hours. Via this pipeline, a high volume of vulnerability reports was processed end-to-end, from initial assessment to in-depth report analysis, including concrete mitigation proposals where needed. All incoming reports were acknowledged promptly and processed consistently in accordance with the defined SLAs.
To shed some light on the process behind this pipeline: When a new report is received and acknowledged, the initial assessment takes priority over all other work. In this first pass, we independently evaluate the severity of the potential attack and check the submission against earlier reports to identify duplicates early, keeping the triage process fast and resources focused. If a report is deemed valid at this stage, we provide a preliminary severity indication, and the initial assessment is shared with the Livepeer Security Committee for alignment.
Every valid report then undergoes an in-depth report analysis. It contains a root cause analysis with the required context, technical details, and the individual root cause components, together with a step-by-step description of the vulnerability scenario. The analysis refines the severity classification based on the impact and likelihood of the vulnerability, examines similar exploits and related attack vectors, and lays out suitable mitigation options, weighing the pros and cons of each. It closes with a recommendation on how to proceed, which forms the baseline for further coordination and collaboration with the Livepeer Security Committee. Once there is an agreement on a mitigation, it becomes part of the release candidate backlog and, if prioritised accordingly, it’s developed as part of the structured release pipeline (see below).
Throughout the term, we did some adjustments to the pipeline itself based on learnings from previous reports, so the process we take into the next phase is better than the one we started with.
2. Structured Release Pipeline
We replaced ad-hoc protocol updates with a structured, repeatable process: A multi-stage update checklist, a retrospective after each update to improve the next one, and a prioritized backlog of update candidates.
This process carried four protocol updates and one out-of-schedule response action during the term:
- Release 2026-02-19:
First update executed under the new checklist procedure. It fixed a low-severity potential griefing attack in which orchestrators at the lower end of the stake spectrum could be griefed out of a round’s rewards if they didn’t call reward promptly (transaction, announcement) - Release 2026-03-19:
Second update, following a refined checklist based on learnings from the February release retrospective. It resolved a longstanding low-severity accounting issue in which delegator fees could be slightly reduced and rewards slightly inflated after one missed reward round (transaction, announcement) - Out-of-schedule response action 2026-04-09:
Coordinated pausing of the L1Migrator contract in direct response to a vulnerability report of critical severity (transaction, announcement) - Release 2026-06-01:
New L1Migrator contract on Ethereum Mainnet and the corresponding L2Migrator state update on Arbitrum, closing a reported critical-severity attack vector that had been mitigated by the temporary pause executed in April. We also removed unused one-time functionality and revoked the old contract’s rights to the BridgeMinter to reduce the potential attack surface further (enable new L1Migrator on L2, offboard old L1Migrator on L1, announcement) - Release 2026-06-25:
Updated TicketBroker implementation preventing a griefing scenario in which manipulated supply and reserve levels could cause valid tickets to be only partially paid while still being permanently redeemed (transaction, announcement)
A deliberate note on prioritization: The original proposal named candidate backlog features such as the Reward Call Delegate to be released via the new release pipeline. Given the volume of incoming vulnerability reports, we instead used the monthly release slots for security-related adjustments. We consider this the right call, since the release cycle exists precisely to ship what matters most at any given time and keep track of future release candidates via a dedicated backlog. Nevertheless we brought the delegation feature into a state that allowed us to release it in July (transaction, announcement).
Before introducing this process and enforcing it, the last protocol update involving a contract update was in August 2025, this was also the only update in 2025. Having a predictable update mechanism is not only good for security, but also provides a reliable way to land major protocol updates in the future.
3. Testnet Work
We delivered two iterations of the testnet proposal over the course of the term, refining scope based on continuous feedback from ecosystem stakeholders, the Security Committee, and the wider community.
The first iteration began at the end of January, shortly after the SPE was voted in, building on the SPE’s founding definitions and early input from the Livepeer Foundation. Through February, we gathered requirements from ecosystem stakeholders and shared the resulting proposal with the Security Committee for review in March. It was also brought before the wider community in a Watercooler Chat in March, where it received mixed feedback, prompting a further round of concrete use cases in April.
The feedback converged on one central concern: Maintaining a separate dedicated testnet, or a full protocol testnet, was too large a lift relative to the benefit it would bring. We used this input to draft a lighter-weight second iteration, scoped down to the features directly useful to us and the community. Work on this iteration began at the end of April but was repeatedly interrupted through May and June by an above-average volume of Immunefi vulnerability reports. The implementation itself is not done yet and will be delivered in the SPE’s next phase. However, the updated proposal was recently shared here.
Delivered Beyond Commitments
Proactive internal security reviews:
Especially in the first month, when the influx of vulnerability reports was still comparatively low, we additionally completed internal security reviews of several core protocol contracts. These reviews act as a defense layer that catches issues before they arrive as external bug bounty reports. This proactive measure is one building block of the next phase’s scope.
Immunefi program scope improvement:
We suggested extending the program with guidance on known issues to cut duplicate submissions, and supported the creation of the first known issue, which carries forward into the next phase’s program scope. We hope that this will reduce the amount of invalid and duplicative reports, thus also reducing the need for our work and the cost to the protocol.
Deferred Scope For Future Phases
The proposal and requirements work for the public testnet were completed, but implementation was repeatedly deprioritized in favor of vulnerability response, which is the core of the SPE’s mandate. April through June brought waves of reports, including the L1Migrator emergency, and response work consumed the capacity the testnet build needed. Rather than deliver a rushed testnet, we re-scoped the implementation into the next phase of the SPE, where the finalized proposal gives it a running start.
Impact
- Protocol security increased through a dedicated SPE that acts on reported vulnerabilities fast and invests in proactive security measures on top. Concretely, a reported attack vector was closed on mainnet before any funds were lost: The L1/L2 migrator address validation issue.
- The protocol’s emergency response path was exercised end-to-end from report to coordinated contract pause to permanent fix and public disclosure. This proved that the escalation chain works under real conditions.
- Protocol updates moved from ad-hoc events to a monthly release cycle backed by a battle-tested checklist-based process. Four updates were shipped through this process without incident.
- The Security Committee now has a dedicated first responder instead of carrying triage themselves, freeing their capacity. We suspect that core stakeholders of the Livepeer Protocol now have more time to focus on doing what they can do best for the protocol, instead of responding to vulnerabilities.
Key Learnings
- AI is raising report volume, so signal extraction matters as much as speed:
With AI tooling becoming more capable, the average number of submitted vulnerability reports has increased noticeably. Dedicated fast-response capacity proved its value, but it needs to be paired with measures that separate signal from noise, such as the known-issues guidance. - AI removes the assumption of confidentiality, raising the value of fast response:
If an AI can find a vulnerability, a reporter can no longer be assumed to keep it private until it is fixed. Every reported vulnerability should be treated as though it is already public. Fast triage and emergency response are the primary defense against the complex attack vectors AI can now surface, and future terms should keep the protocol ready for this shift. - Vulnerability response is unplannable and displaces roadmap work: It arrives in unpredictable waves, demands immediate attention, and takes priority by mandate. It should be treated as capacity that can crowd out scheduled deliverables.
- Process investment pays off fast: The checklist-based protocol update process and the vulnerability triage pipeline in combination with tightly coupled refinement retrospectives produce reliable results fast.
Budget
Sidestream received a total of 113,000 LPT tokens over the six-month term. At the end of each month, the portion attributable to the completed work was released and converted into USDC. In total, Sidestream received the equivalent of USD 296,800 over the six-month period. The high-level breakdown is as follows:
| Category | Amount |
|---|---|
| Security-related work | 258,216 USD |
| Other work (e.g. testnet and features) | 38,584 USD |
| Total | 296,800 USD |
Conclusion & What’s Next
The SPE set out to give Livepeer a professional, accountable security function, and that function now exists: A proven triage pipeline, a monthly release process, a prioritized backlog, and a team that has handled routine reports as well as an out-of-schedule contract pause. The community approved the continuation of the Protocol R&D SPE for a further six-month term, under which this work carries on.
The continuation draws direct consequences from the learnings above. With AI-assisted tooling raising both report volume and noise, reactive capacity alone is not a sustainable answer, so the new term deliberately shifts resources toward getting ahead of the curve. It is structured around three workstreams:
- Reactive security operations:
Continuous Immunefi first-response coverage under the established SLA targets and escalation procedures. - Proactive security:
Completing the self-audits of all in-scope protocol contracts, establishing a repeatable scanning pipeline to find vulnerabilities before external researchers do, and further tightening the Immunefi program scope and known-issues guidance to reduce duplicate and invalid reports. - Protocol releases:
Maintaining the monthly release cadence built this term using and extending the validation and release tooling already in place.
Transparency also carries forward: Monthly forum updates on status, open publication of non-sensitive work, and an end-of-term retrospective like this one.
Thank you to the Security Committee for the close and pragmatic collaboration on every update, to the Livepeer Foundation for coordination and support, and to the community for the trust placed in this SPE. We are glad to keep building on these foundations.