This thread will contain a list of contract bug fixes that have been deployed as a part of the multi-phase Confluence launch process described in LIP-73 for ease of community review.
1 Like
2/17/2022
Re-posted from Discord
A contract bug that caused rewards on L2 to be lower than expected was recently brought to the core team’s attention (thank you to @vires-in-numeris and @deboot). At no point were user funds at risk, the bug was not exploitable, the only impact the bug had was to cause rewards to be lower than expected and a fix for the bug has been deployed. Starting from the next round (2470), the rewards on L2 should be calculated correctly.
The main problem was that the rewards that could be minted in a round were being calculated based on the L2 token supply when it should’ve been calculated based on the global token supply (includes both the L2 token supply and the L1 circulating token supply). The end result was that the calculated rewards were lower than what they should have been - the rewards on L1 were always calculated based on the global token supply (which was all on L1 at the time). The fix for the bug was to deploy an updated Minter contract [2] that calculated the rewards based on the global token supply.
The deployment of this bug fix is a part of the governance failsafes procedure described in [2]. While this bug did not cause user funds to be at risk of direct theft, it did represent a significant inadvertent change in the economics of the network relative to where things left off on L1 and reduced rewards for orchestrators and delegators in an unexpected way counter to expectations set in the LIP-73 specification [3]. With this in mind, the core team moved forward with a fix swiftly to resolve this issue for the community as soon as possible.
[1] Contract Address 0xc20DE37170B45774e6CD3d2304017fc962f27252 | Arbiscan
[2] Statement on the Governance Failsafes
[3] LIPs/LIP-73.md at master · livepeer/LIPs · GitHub
1 Like
2/23/2022
Re-posted from Discord
As Hunter mentioned in Discord, after deploying L2 stake claiming support for delegators in the explorer earlier today, the core team discovered a small bug with the contract stake claiming logic. The bug could cause delegators that claim their stake on L2 to incorrectly be credited with some extra LPT rewards and ETH fees. Based on an investigation, we observed a handful of delegators accounts with some extra LPT rewards and ETH fees affected by this bug after claiming their stake on L2, but the overall amount was relatively small. This bug was fixed by the addition of a few lines of code in the BondingManager to ensure that earnings are correctly credited to a delegator account during stake claiming. At no point were user funds at risk, protocol funds remained accessible (even though some extra LPT rewards and ETH fees were incorrectly credited to a few accounts the amount was small and the Minter contract which holds protocol funds had plenty to cover that amount due to having some excess funds from the past) and a fix for the bug has been deployed.
The deployment of this bug fix is a part of the governance failsafes procedure described in [1]. While this bug did not cause user funds to be at risk of direct theft, it did represent the potential incorrect crediting of LPT rewards and ETH fees to certain accounts (over the amount the account was actually entitled to based on protocol rules) which ran counter to the expectations set by the LIP-73 specification [3]. With this in mind, the core team moved forward with a fix swiftly to resolve this issue for the community as soon as possible.
[1] Statement on the Governance Failsafes
[2] LIPs/LIP-73.md at master · livepeer/LIPs · GitHub
1 Like
2/25/2022
A contract bug that could cause a delegator that claims its stake on L2 to be delegated to the null address and unable to move its stake was recently brought to the core team’s attention. A fix for the bug has been deployed and there should be no cases of stake being unmovable or inaccessible after a delegator claims its stake on L2.
The main problems were that:
- It was possible for a delegator that claimed its stake on L2 to become delegated to the null address such that:
- The delegator would not be able to move its stake away from the null address
- There was the possibility of accounting discrepancies upon further staking actions that could make some of a delegator’s stake inaccessible
The deployment of this bug fix is a part of the governance failsafes procedure described in [1]. The bug created the opportunity for a delegator that claims its stake on L2 to potentially lose access to some of its stake in the course of normal staking actions. With this in mind, the core team moved forward with a fix swiftly to resolve this issue for the community as soon as possible.
1 Like
3/3/2022
A contract bug that could allow an orchestrator to have two opportunities to win (i.e. receive the face value of the ticket) using a single ticket received from a broadcaster was recently reported to the core team. A fix for the bug has been deployed and going forward each ticket received by an orchestrator should only represent a single opportunity to win.
The main problem was that a broadcaster’s signature could be modified to give an orchestrator a second opportunity to win with the same ticket.
The deployment of this bug fix is a part of the governance failsafes procedure described in [1]. The bug created the opportunity for an orchestrator to receive an additional opportunity to win with a ticket received from a broadcaster which essentially means that an orchestrator could potentially extract extra value from a broadcaster over time by getting extra winning tickets during an extended time period which would be harmful to the broadcaster. With this in mind, the core team moved forward with a fix swiftly to resolve this issue for the community as soon as possible.
The core team will share a full technical post-mortem soon along with the report that brought this bug to the team’s attention separately.
EDIT: The technical post-mortem can be found here.
1 Like
3/16/2022
A contract bug that could allow a third party to forcibly change the delegate of a delegator was recently brought to the core team’s attention. A fix for the bug has been deployed and there should be no cases where a third party (outside of the L2Migrator contract which has special privileges specifically when a delegator is migrating from L1 to L2) can forcibly change the delegate of a delegator.
From a delegator harm POV, in the worst case, this exploit could prevent a delegator from earning rewards and fees if the new delegate does not earn any rewards or fees - since the delegator doesn’t lose its existing stake and since the attacker doesn’t benefit from this type of attack this can be considered a griefing attack that prevents the delegator from accessing yield that it would otherwise have access to. From an adversary benefit POV, in the worst case, this exploit could allow an adversary to boost its own rewards if it forces victim delegators to delegate to its own orchestrator with a reward cut set to 100% - the adversary’s orchestrator would see larger rewards per round thanks to the stake delegated by victim delegators and would keep all of the rewards since its reward cut is set to 100%. While fixing this bug, the core team also addressed another smaller issue where earnings would not be calculated correctly in the scenario where a third party changed the delegate of a delegator or staked additional LPT on behalf of the delegator.
The deployment of this bug fix is a part of the governance failsafes procedure described in [1]. The bug created the opportunity for an attacker to prevent a delegator from accessing yield and in certain circumstances even extract additional rewards/fees. With this in mind, the core team moved forward with a fix swiftly to resolve this issue for the community as soon as possible.
1 Like
8/25/2022
A smart contract bug in the Livepeer protocol was recently brought to the security committee’s attention by a whitehat hacker through Livepeer’s Immunefi Bug Bounty program. A fix has been deployed for this bug, and it is no longer exploitable.
The deployment of this bug fix is a part of the governance failsafe procedure described here [1].
Until this fix was deployed, user funds could be temporarily frozen but not withdrawn via a manipulation within the internal bonding functions of the protocol. The mitigation for the bug was to deploy a minor change to the BondingManager contract that corrects the internal logic of the bonding mechanisms to prevent delegators from manipulating their stake in an undesired manner.
In the interest of full transparency, a public report and retrospective on the bug will be published after completing a thorough internal investigation. It will cover the bug, potential attack vectors, the fix that has been deployed, and takeaways that can be used to improve processes in the future. Although funds were not at risk of theft, this was still a notable vulnerability and we are indebted to the work of the whitehat who reported the bug via Livepeer’s bounty program.
With the fix in place it is believed that no user funds are currently at risk of theft or freezing.
3 Likes