# Security Vulnerability Disclosure (Fixed): Transcoders Could Lose Out On Rewards/Fees Under Certain Conditions **URL:** \ **Category:** Uncategorized\ **Created:** [September 24, 2020, 9:22pm UTC](https://forum.livepeer.org/t/security-vulnerability-disclosure-fixed-transcoders-could-lose-out-on-rewards-fees-under-certain-conditions/1145 "2020-09-24T21:22:19Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![yondon](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.livepeer.org/yondon/32/192_2.png) [@yondon](https://forum.livepeer.org/u/yondon)\ **Post date:** [September 24, 2020, 9:22pm UTC](https://forum.livepeer.org/t/security-vulnerability-disclosure-fixed-transcoders-could-lose-out-on-rewards-fees-under-certain-conditions/1145/1 "2020-09-24T21:22:19Z")
Find below a description of a security vulnerability with the BondingManager contract that was surfaced after the LIP-36 security audit conducted by Quantstamp (thanks to Quantstamp for highlighting an issue during the LIP-36 security audit that allowed us to discover this vulnerability in the already deployed mainnet contracts!). This vulnerability has been fixed and users **do not** need to worry about the vulnerability impacting them. The technical details of the vulnerability are shared for informational purposes. ### Transcoders who miss a reward call and that do not receive stake updates in a given round may lose out on rewards/fees in the following round if delegation activity occurs prior to a reward call or receiving fees ### Impact _What kind of vulnerability is it? Who is impacted?_ **Description** This vulnerability can cause a transcoder and its delegators to miss out on new rewards and/or fees in the current round if the transcoder did not receive any stake updates in the previous round (either via delegation or by calling reward) and delegation activity for the transcoder occurs before the transcoder calls reward and/or receives fees in the current round. The root cause of this vulnerability is that when `rewardWithHint()` is called, the `setStake()` function is only called for the current round’s earnings pool if the transcoder’s [lastActiveStakeUpdateRound is in the past](https://github.com/livepeer/protocol/blob/streamflow/contracts/bonding/BondingManager.sol#L658). A transcoder’s `lastActiveStakeUpdateRound` is updated in the internal functions `increaseTotalStake()` and `decreaseTotalStake()` which are called whenever a transcoder receives stake updates either via delegation activity (i.e. calls to `bond()`, `unbond()`, `rebond()`) or calls to `rewardWithHint()`. If a transcoder receives stake updates in the current round, then its `lastActiveStakeUpdateRound` is set to current round + 1 to indicate that the transcoder’s active stake has been updated for current round + 1 (stake updates in the current round only impacts the active stake of a transcoder in current round + 1). If there is delegation activity for a transcoder _before_ `rewardWitHint()` is called, then when `rewardWithHint()` is called `lastActiveStakeUpdateRound` will be in the future. This is ok if the transcoder received stake updates in the previous round because at this point `setStake()` would have been called for the current round’s earnings pool when either `increaseTotalStake()` or `decreaseTotalStake()` were called in the previous round. However, in this situation, if the transcoder did not receive stake updates in the previous round then `setStake()` function was not called in the previous round and will never be called for the current round because the transcoder’s `lastActiveStakeUpdateRound` would’ve already been set to a round in the future. `setStake()` not being called for the current round’s earnings pool in `rewardWithHint()` has the following consequences: - The [Minter.createReward() call](https://github.com/livepeer/protocol/blob/streamflow/contracts/bonding/BondingManager.sol#L665) in `rewardWithHint()` will treat the transcoder’s active stake as 0 which results in 0 rewards minted for the transcoder - When a transcoder or its delegators claims earnings, the [fee pool share](https://github.com/livepeer/protocol/blob/streamflow/contracts/bonding/libraries/EarningsPool.sol#L212) will be 0 because the `claimableStake` field of the earnings pool will be set to 0 **Triggering/Reproducting** The pre-conditions that need to hold for this vulnerability to be triggered are: - The transcoder did not receive any stake updates in the previous round - There is delegation activity for a transcoder in the current round before reward is called or before fees are received **Exploit Scenarios** This vulnerability could be triggered over the course of normal day-to-day operations if a transcoder misses a reward call. It is normal for there to be no delegation activity in a day. So, if a transcoder misses a reward call in the prevous round and there happens to be delegation activity in the current round and a transcoder was too slow to call reward (possibly deliberately to wait for better gas prices) then this vulnerability could be triggered. This vulnerability could also be triggered by a malicious actor that is seeking to grief others. A malicious actor could watch for transcoders that miss reward calls in the previous round and that did not receive any staking updates in the previous round. Then, the actor could front-run any reward calls from the transcoder in the current round by staking 1 base unit LPT to the transcoder. With this example in mind, it is worth noting that there is little in-protocol economic benefit (excluding extra-protocol economic benefits out of this analysis) from doing this besides for the sake of griefing the transcoder and its delegators. The malicious actor doesn’t gain any additional value from triggering this vulnerability and in fact it actually potentially loses out on rewards/fees that it would otherwise earn if it did not trigger this vulnerability. ### Patches _Has the problem been patched? What versions should users upgrade to?_ The vulnerability has been patched with the following commit: > **Deployment** These were the steps taken for deployment: `gitCommitHash`: 0xcb5548cc1496607da341804d55fd4a90038d2687 - This is the Git commit hash with the fix `contractId("BondingManagerTarget")`: 0xfc6f6f33d2bb065ac61cbdd4dbe4b7adf6f3e7e6c6a3d1fe297cbf9a187092e4 1. Deploy a new `BondingManager` implementation contract at `bondingManagerAddr` 2. Register the new `BondingManager` implementation contract by calling the following on the `Controller`: - `setContractInfo(contractId("BondingManagerTarget"), bondingManagerAddr, gitCommitHash)` 3. Merge the PR associated with this advisory into the `streamflow` branch The relevant deployment transactions can be found below: 1. [Deployed a new BondingManager implementation contract](https://etherscan.io/tx/0x57832293976ca7ebeeca2fda9bceefb3f44d853c211931bc282a2ace8733f844) 2. [Registered the new BondingManager implementation contract with the Controller](https://etherscan.io/tx/0x99e01ce2a7bed0c5d39d24b46cf3e94505cf005b57082a34e31e24d26fb8f52d) ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ Transcoders no longer need to worry about this vulnerability. Transcoders could have avoided this vulnerability from being triggered by making sure to always call reward in each round that they are active because calling reward will always serve as a stake update that will trigger a `setStake()` call for the next round’s earnings pool. ### References _Are there any links users can visit to find out more?_ ### For more information If you have any questions or comments about this advisory: - Email us at [security@livepeer.org](mailto:security@livepeer.org)