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

[rickstaa]

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:

• resignTranscoder() removes them from transcoderPool immediately, so getTranscoderPoolSize() returns N - 1.
• It sets deactivationRound = currentRound + 1, so isActiveTranscoder() still returns true for the remainder of 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

• Source: contracts/pm/mixins/MixinReserve.sol
• Related: contracts/pm/mixins/MixinTicketBrokerCore.sol, contracts/bonding/BondingManager.sol
• Deployed TicketBroker (Arbitrum): 0xa8bB618B1520E284046F3dFc448851A1Ff26e41B