51288 sc insight validators commission can be permanently lost

Submitted on Aug 1st 2025 at 13:07:43 UTC by @Outliers for Attackathon | Plume Network

  • Report ID: #51288

  • Report Type: Smart Contract

  • Report severity: Insight

  • Target: https://github.com/immunefi-team/attackathon-plume-network/blob/main/plume/src/facets/ValidatorFacet.sol

  • Impacts:

    • Permanent freezing of funds

Description

Brief/Intro

Validator commission claims become permanently locked if the validator's l2WithdrawAddress gets blacklisted by reward tokens like USDC or USDT. When a commission claim is requested, the system locks the claim to the original withdraw address and prevents new claims from being initiated, creating an irrecoverable loss scenario.

It should be noted that blacklisting is not a rare event — for instance, by the time this report was written, USDC had 371 blacklisted addresses, while USDT had 2,378 blacklisted addresses (https://dune.com/phabc/usdt---banned-addresses), and reasons for blacklisting vary; legitimate addresses can also be blacklisted (https://bglaw.eu/articles/tether-and-circle-blocking-usdt-and-usdc-addresses/).

Stable-coins like USDT and USDC are frequently used in fraud or scams. If an exchange or platform detects fraudulent activity linked to a specific wallet address, they may freeze that address to prevent further abuse or loss. Unfortunately however, alongside with the criminal transactions, many legitimate addresses are also blocked.

Vulnerability Details

The issue stems from the interaction between three key functions in the commission claiming process.

addValidator - Sets the l2WithdrawAddress that will receive commission claims

requestCommissionClaim : Validator requests commission claim for USDC/USDT

finalizeCommissionClaim - Attempts to transfer tokens to the blacklisted l2WithdrawAddress via distributeReward

When finalizeCommissionClaim is called, it attempts to transfer tokens via distributeReward which internally calls: soliditySafeERC20.safeTransfer(IERC20(token), recipient, amount);

If the recipient is blacklisted by the token contract this transfer will revert. Because the code deletes the pending claim only after preparing the transfer (but before calling distributeReward) — actually in this snippet the claim is deleted before calling distributeReward; however the transfer fails and the claim ends up effectively blocking further claims (the revert prevents state changes from persisting in the call that attempted the transfer; the design still relies on a single recipient persisted by request). The net effect is that the existing claim logic prevents new claims from being initiated until the pending claim is removed, and there is no mechanism to:

  • update the withdraw recipient for a pending claim,

  • cancel a pending claim,

  • recover or redirect the locked funds if the recipient is blacklisted.

Therefore a blacklisted withdraw address causes claim finalization to fail and leaves commission unclaimable.

Impact Details

  • Permanent loss of validator commissions for affected tokens

  • Ongoing accumulation of unclaimable rewards as commission continues to accrue

References

Add any relevant links to documentation or code

Proof of Concept

1

Step

Validator added with withdraw address 0xABC...

2

Step

Validator earns commission and requests claim:

3

Step

Address 0xABC... gets blacklisted by USDC:

4

Step

Attempt to finalize claim fails:

5

Step

Attempt to request new claim fails:

6

Step

Commission continues to accrue but remains permanently unclaimable:

Was this helpful?