Reproduced Exploit
Hyperstable — RewardsDistributor.claim reverts once a ve lock expires and the reward stays in the distributor
Chain
Other
Category
dos
Date
May 2025
Source
AuditVault
EVM Playground
Source-level debugger — step opcodes and Solidity in sync
The attack is replayed in an in-browser EVM preloaded with the exact dumped fork state. The execution tree shows every call; step by Solidity line or by opcode across all depths — source, Stack, Memory, Storage, Balances (native / ERC-20 / NFT), Transient storage and Return value stay in sync. Click a tree node, opcode, or source line to jump. No backend, no live RPC.
Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 55694-h-03-rewarddistributorclaim-will-revert-for-tokens-with-expi. Standalone Foundry PoC and full write-up: 55694-h-03-rewarddistributorclaim-will-revert-for-tokens-with-expi_exp in the
evm-hack-registrymirror.
Vulnerability classes: vuln/dos/frozen-funds · vuln/logic/incorrect-state-transition · vuln/logic/missing-check
Reproduction: Local Foundry reproduction of the verbatim
claim/deposit_forpair. No fork. Trace: output.txt.
Root cause#
RewardsDistributor.claim always forwards a non-zero reward into the voting escrow with deposit_for. vePeg.deposit_for reverts when locked.end is not strictly after block.timestamp ("Cannot add to expired lock. Withdraw"). increase_unlock_time uses the same require, so the lock cannot be extended after expiry. The claim reverts and the PEG stays in the distributor.
if (amount != 0) {
// @> VULN:
IVotingEscrow(voting_escrow).deposit_for(_tokenId, amount);
token_last_balance -= amount;
}
Attack path#
PoC#
One transaction. The expired lock's claim is a low-level call and reverts. The live lock's claim succeeds and compounds 1000 PEG into the escrow. The distributor's PEG balance is the expired 1000.
The fixed distributor pays an expired lock by transferring PEG to the owner. That control leaves the distributor at 0.
cd 55694-h-03-rewarddistributorclaim-will-revert-for-tokens-with-expi_exp
forge test -vv
Remediation#
If locked.end <= block.timestamp, transfer the reward to the lock owner instead of calling deposit_for. Hyperstable did this in commit 3012a71.
References#
- AuditVault finding 55694
- Report: https://github.com/solodit/solodit_content/blob/main/reports/0x52/2025-05-02-Hyperstable.md
Sources & further analysis#
Reproductions & code
- Standalone PoC + full trace: 55694-h-03-rewarddistributorclaim-will-revert-for-tokens-with-expi_exp (evm-hack-registry mirror).
- AuditVault finding: 55694-h-03-rewarddistributorclaim-will-revert-for-tokens-with-expi.
Alerts & third-party analyses
These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.