Temporary freezing of funds for at least 24 hours (e.g., stuck withdrawal proofs, locked dispute game bonds)
Description
Brief/Intro
The claimCredit() function has a 14-day bond recovery fallback, but it only activates when expectedResolution == type(uint64).max (i.e., zero proofs submitted). When at least one proof exists, expectedResolution is set to a finite timestamp (e.g., block.timestamp + 7 days), and the 14-day fallback path is unreachable.
Vulnerability Details
With PROOF_THRESHOLD=2, if only one proof type is submitted before the 7-day expectedResolution timer expires, the game enters an irrecoverable dead state:
resolve() fails: proofCount(1) < PROOF_THRESHOLD(2) reverts with NotEnoughProofs()
verifyProposalProof() fails: gameOver() returns true, reverts with GameOver()
claimCredit() fails: expectedResolution != type(uint64).max enters the first branch, which requires resolvedAt != 0, but the game can never resolve
The code comment at line 610-612 states "The game must have resolved or 14 days have passed since creation" (an OR condition), but the implementation uses conditional branching on expectedResolution that restricts the 14-day fallback to only the no-proofs case.
The issue has the same root cause as 1.1 Unconditional Proof Threshold Check in resolve Blocks Normal Bond Recovery When Parent Game Is Invalid from Cantina Multiproof security report, BUT the currently reported issue is a broader dead state scenario, (especially for first games or games with valid parents) and the specific claimCredit() conditional fallback gap. Fixe introduced in commit dd587c9adc84a768eb540a88ef479275c5db97e9 addresses only the resolve() path when the parent is invalid.
Impact Details
For first games (parent = AnchorStateRegistry), there is no instant recovery path since _getParentGameStatus() always returns DEFENDER_WINS. Impact is systemic when a verifier is globally nullified: all in-progress games needing the nullified verifier type and having only one proof submitted become unresolvable with temporaly locked bonds, until governance / ProxyAdmin owner use hold / recover. That is at least 24h in any realistic scenario.