BattleChain Confidence Pools

DESCRIPTION

The Protocol assumes the use of standard ERC20 tokens as stakeToken, where transfers succeed, balances only change through normal transfers, and transfer() moves exactly the requested amount. However, there are standard ERC20 tokens like USDC that are not immutable or permissionless. USDC implementation includes administrative controls such as pausing, blacklisting, minting/burning, and upgradeability. If USDC is used as a pool’s stakeToken, the pool becomes dependent on Circle’s token-admin behavior. If the implementation of the used stakeToken is upgraded to include fees, this could brick accounting logic, especially if the fees are charged on the sender.

Let's say users stake USDC into the pool through:

Later withdrawals and claims rely on USDC transfers succeeding:

If USDC transfers are paused, or if the pool address, a claimant, the attacker, or the recovery address is blacklisted, these transfers can revert, causing a temporary DOS. Meanwhile deadlines are still being observed.

Affected functions:

stake()

contributeBonus()

withdraw()

claimSurvived()

claimExpired()

claimCorrupted()

claimAttackerBounty()

sweepUnclaimedCorrupted()

sweepUnclaimedBonus()

This can cause funds to become temporarily stuck.

SCENARIO

A pool is created with USDC as stakeToken.

Users stake USDC and/or bonus contributors add USDC.

The pool later reaches a withdrawal or claim phase.

USDC is paused, or the pool/recipient address is blacklisted.

The pool calls safeTransfer().

USDC transfer reverts.

Users cannot withdraw or claim even though pool accounting says they are owed funds.

RECOMMENDED MITIGATION

The protocol should consider cases of standard mutable ERC20 tokens being paused, blacklisted, or upgraded, and account for lost time during such situations, so it can be added back to extended deadlines after the token becomes active again.