Hi all. A low-severity griefing bug in TicketBroker, responsibly disclosed through the Livepeer Immunefi Bug Bounty program, was patched in the June 2026 release window. Sidestream led the analysis and patch, then coordinated final review and execution with the security committee. The bug, if exploited, would have allowed an attacker to burn a transcoder’s winning ticket while paying them only a dust amount (down to 1 wei) instead of the full face value. No user funds were lost, the issue was not exploited on the network to our knowledge, and the system is now fully patched. A bounty has been paid to the reporter, and we thank them for the responsible disclosure.
The issue
redeemWinningTicket in TicketBroker marked a ticket used without validating that the sender’s deposit + reserve covered the full ticket face value. Against a fully drained sender, an attacker could top up 1 wei (or any amount below faceValue) via fundDepositAndReserveFor just before redemption landed: the check passed, the ticket was permanently consumed, and the transcoder was paid only the top-up amount. The same underpayment could also occur naturally as a race condition between multiple transcoders redeeming against the same underfunded sender.
The fix
TicketBroker’s redemption guard was tightened: it now requires the sender’s deposit plus remaining reserve balance cover the ticket’s face value before marking it used. If the combined balance is insufficient, redemption reverts and the ticket remains valid for retry after the sender tops up. Per-recipient reserve allocation semantics per the spec are unchanged: partial payouts can still occur when a recipient’s per-round allocation cannot cover the face value. The patched logic shipped as a new implementation at 0x3B68fbF89D121278b216A55a4252cAc820D552B7, registered via the Controller by the L2 governance multisig (registration tx).
Behavioural change
None from a user perspective. Existing go-livepeer already handles the new revert (generic error, ticket stays valid), and the pre-patch outcome (dust + burned ticket) was strictly worse. The new path surfaces pre-existing minor edge cases (retry, RPC-churn, observability) we plan to fix, tracked in go-livepeer#4013.
No LIP required
The security committee deployed this patch under its existing upgrade authority to protect user funds. LIP-25 carves critical bug fixes and emergency pauses out of the LIP process, so no LIP is required. As with prior security patches, the public record is a forum disclosure like this one.
Thanks and pointers
Thanks again to the reporter for the responsible disclosure, and to Sidestream, our protocol security partner, for the triage, analysis, and patch development. The deployed contract and patch are linked below for anyone who wants to verify directly.
- Patched TicketBroker implementation (Arbitrum One):
0x3B68fbF89D121278b216A55a4252cAc820D552B7 - Registration transaction:
0x6c2daaa1…21bc9c32 - Patch PR: protocol#657
For questions, email security@livepeer.foundation or reply in this thread.