As part of preparing for Livepeer’s upcoming Streamflow protocol upgrade, the project has undergone an external audit with security research firm Trail of Bits. The aim of the audit process was to focus on uncovering any security issues that may have been introduced since the initial audit was conducted pre-launch in early 2018. Over the course of three weeks, ToB reviewed the Streamflow upgrade, documented the potential issues they discovered, noted potential areas for code quality improvements, and recorded their findings in their official report, which you can view here.
Summary of Findings
The scope of the audit was on the Protocol smart contracts and new payments mechanism in Streamflow. It asked the following questions:
- Can round and protocol progression be halted, preventing the protocol from moving forward?
- Are there vulnerabilities in the upgrade mechanism that would allow a malicious user to take control of the contracts?
- Are user funds, in staked LPT or ETH, at risk?
- Can a malicious user force all payment tickets to win (or lose) without being detected by the user on the other end of the transaction?
The report highlights two medium severity issues, one low severity issue, and two undetermined severity issues. Livepeer addressed each point raised by ToB in the Response section of the audit report, and either provided a newly reviewed code change, or indicated how the reported issue was defended against by the various protocol actors.
Public Bug Bounty Program
In conjunction with private audits by security firms, Livepeer seeks public review from the open community of protocol participants and researchers. As such, Livepeer runs an ongoing bug bounty program, in which rewards are paid out in relation to the severity of the issues discovered — as long as they are disclosed responsibly.
- Note: Up to $50 USD
- Low: Up to $100 USD
- Medium: Up to $250 USD
- High: Up to $1000 USD
- Critical: Up to $2500 USD
See the bug bounty wiki page for a full description of the program and disclosure processes.
As per the published audit report for Streamflow, the following focus areas are considered high impact, and would be subject to larger bounty rewards:
- The Livepeer protocol progresses in rounds and each round needs to be initialized in order for other actions to take place (i.e., ticket redemption, staking, etc.). Can anything halt round progression and prevent round initialization from taking place?
- Streamflow is a protocol upgrade focused on scalability and still relies on a centralized upgrade mechanism controlled by the core team for the time being. It is crucial that the core team is able to retain ownership of contracts in the system as owners of these contracts are able to update economic parameter values, fix bugs, and deploy upgrades. Are there any vulnerabilities that would allow a malicious actor to take ownership of these contracts and access the aforementioned capabilities?
- Users stake Livepeer tokens via the deployed contracts. Users also escrow ETH with the deployed contracts which is used to pay for work on the network. Can anything put this user value at risk such that it could be locked up permanently in the contracts or stolen by malicious actors?
In addition to the above goals, there are a number of areas related to the upgrade from Tributary to Streamflow that would be reward eligible:
- Is state corruption possible for any of the upgraded contracts, e.g., due to state corruption risks inherent in the delegatecall proxy upgrade mechanism?
- Is there any possibility of unexpected behavior in the interaction between new/upgraded contracts compiled with solc 0.5.x and old contracts compiled with solc < 0.5.x?
- Are there any cases where the new state update logic in the updated BondingManager makes invalid assumptions during the transition from V1 to Streamflow?
- Is it possible for an attacker to force all probabilistic micropayment tickets sent from a broadcaster to always win despite the winning probability of the tickets being less than 100%?
- Is it possible for a malicious attacker to force all probabilistic micropayment tickets received by an orchestrator to always lose despite the winning probability of the tickets being greater than 0?
If you do dig into the Livepeer protocol code and have questions related to any of the above, please contact email@example.com. Thank you.