Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

MixinReserve.claimableReserve() mid-round accounting mismatch when transcoder pool size and current-round active set diverge

Open
  • Is something wrong?
#656 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Quiet
Tech stack
solidity
Domain
blockchain, security

Research direction

Start with contracts/pm/mixins/MixinReserve.sol, then trace MixinTicketBrokerCore.redeemWinningTicket() and BondingManager.resignTranscoder() or tryToJoinActiveSet(). The issue describes a documented, out-of-scope accounting mismatch and does not specify a code change or acceptance test, so no concrete completion condition is provided.

Written by the indexing model from the issue text.

Description

known-issue
Summary

MixinReserve.claimableReserve() reads two data structures that can fall out of sync within one round. Claimant eligibility is gated on bondingManager().isActiveTranscoder(_claimant) (a current-round snapshot), while the reserve allocation is divided by bondingManager().getTranscoderPoolSize() (the live pending transcoder pool counter). When the pending pool shrinks or grows mid-round (e.g. via resignTranscoder() or tryToJoinActiveSet()), the eligible active set and the divisor diverge, causing the per-claimant reserve cap to deviate from the fair R / N allocation in either direction.

Root cause

isActiveTranscoder() is gated on activationRound <= currentRound < deactivationRound, which is a round-level snapshot. getTranscoderPoolSize() returns the live size of the transcoderPool linked list, which is mutated immediately by bonds, unbonds, evictions, and resignations.

When an active transcoder fully unbonds in round r:

The set of eligible claimants has size N, but the divisor is N - 1. Every eligible share is inflated by N / (N - 1). The symmetric case (new transcoder joining via tryToJoinActiveSet() when a slot is free) deflates the cap in the same way.

Why it's not an issue
  • No theft. The redeemed amount is bounded by the ticket's faceValue and can never exceed the face value the broadcaster explicitly signed. No funds are created beyond what the broadcaster committed.
  • Grief is temporary. claimFromReserve is explicitly designed to pay min(shortfall, claimableReserve), not the full face value. Partial reserve payment for a valid ticket is normal protocol behavior. After a revert, usedTickets[hash] remains false and the ticket can be retried in a later round (subject to ticketValidityPeriod).
  • Restrictive preconditions. The attack requires (1) a valid pre-signed winning ticket where faceValue - deposit > R / N, (2) the attacker accepting the opportunity cost of fully unbonding (or coordinating with a separate pool-shrinker), and (3) no other transcoder bonding into the freed slot between the pool shrink and the redeem call. Splitting the pool-shrinker and the overclaimer into separate accounts reintroduces a race: the pool shrink and the redemption can no longer be bundled into one transaction, so any transcoder bonding into the free slot between the two steps restores the pool size and cancels the inflation.
  • Protocol spec acknowledges the behavior. The Livepeer technical spec documents a scenario where an orchestrator sets their ticket's face value to R / N, but by the time they redeem, the active set has grown to N + 1, dropping the cap to R / (N + 1). This is treated as a known limitation of the reserve mechanism. The invariant claimableReserve == R / active_set_size at all times is not guaranteed by the spec.
Out of scope for bug bounty

Reports targeting the claimableReserve accounting mismatch in MixinReserve.sol, and the associated griefing/payment-disruption paths through MixinTicketBrokerCore.redeemWinningTicket(), BondingManager.resignTranscoder(), or BondingManager.tryToJoinActiveSet(), are closed as known issues and not eligible for rewards under the Livepeer Immunefi bug bounty program.

References
Dominant language
JavaScript
Stars
155
Forks
50
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from livepeer/protocol

All issues in livepeer/protocol

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.