On a good-faith CORRUPTED resolution the entire pool is reserved as the named whitehat's bounty; claimAttackerBounty() pays the attacker and unblocks claimCorrupted(). docs/DESIGN.md §12 asserts there is no stuck-state because "a true stuck-state would require a defective stake token that freezes the pool's own balance, which the factory allowlist exists to exclude", and the factory allowlist natspec names only fee-on-transfer and rebasing tokens.
That reasoning is incomplete: a compliance blocklist token — USDC/USDT, the canonical stablecoins a pool would use — is a standard ERC20 (no fee, no rebasing) that IS allowlistable, yet it reverts on transfer to a blocklisted recipient. When the moderator-named good-faith attacker is on the issuer blocklist, claimAttackerBounty's payout reverts and can never be claimed; claimCorrupted then stays permanently gated by MustClaimBountyFirst. The whole pool is frozen for the 180-day CORRUPTED_CLAIM_WINDOW, after which anyone sweeps it to recoveryAddress — the whitehat who performed the in-scope breach receives 0.
Likelihood:
The pool's allowlisted stake token is a blocklist-capable standard ERC20 (USDC or USDT — the dominant stablecoins for this use case), which the allowlist rationale does not exclude.
The moderator-named good-faith attacker (or the sponsor's recoveryAddress) is on the token issuer's blocklist at claim time, and the moderator does not re-name a clean attacker within the correction window.
Impact:
The full CORRUPTED payout path is frozen for up to 180 days (claimAttackerBounty reverts; claimCorrupted is blocked by MustClaimBountyFirst).
A blocklisted named whitehat who performed the in-scope breach ultimately receives 0; the pool sweeps to recoveryAddress after the window elapses.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
View preliminary resultsAppeals are being carefully reviewed by our judges.
The contest is complete and the rewards are being distributed.