OTSea Staking Exploit — `claim()` Re-Arms Already-Withdrawn Deposits (Double-Withdraw Drain)

Source & credit. Exploit reproduction, trace data, and analysis adapted from DeFiHackLabs by SunWeb3Sec — an open registry of reproduced on-chain exploits. Standalone Foundry PoC and full write-up: 2024-09-OTSeaStaking_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/OTSeaStaking_exp.sol.

Vulnerability classes: vuln/logic/incorrect-state-transition · vuln/reentrancy/single-function

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder (the umbrella DeFiHackLabs repo contains many unrelated PoCs that do not whole-compile, so this one was extracted). Full verbose trace: output.txt. Verified vulnerable source: contracts_token_OTSeaStaking.sol.

Key info#

TL;DR#

OTSeaStaking lets a user manage many individual deposits (a Deposit[] per account). A deposit's rewardReferenceEpoch field doubles as both its reward-accounting anchor and its "is-this-deposit-still-alive" flag:

• withdraw() pays out the deposit's principal and marks it dead by writing rewardReferenceEpoch = 0 (:382), guarding against immediate double-withdraw with a rewardReferenceEpoch == 0 ⇒ revert check (:381).
• claim() — meant only to harvest ETH rewards — unconditionally overwrites rewardReferenceEpoch = currentEpoch (:416) for every index passed, with no check that the deposit is still alive.

So claim() re-arms a dead (already-withdrawn) deposit: it flips rewardReferenceEpoch from 0 back to a non-zero value, while leaving deposit.amount fully intact. The deposit looks brand-new again, and withdraw() happily pays out its amount a second time.

The attacker (whose own pre-existing OTSea balance was 0) simply looped claim(indexes) → withdraw(indexes) over their own deposit indexes. Each pass paid out the same principal again. After 46 such loops they had pulled 43,944,445 OTSea out of a contract that held 43,944,819 OTSea — draining essentially everyone's stake — then dumped 6M of it on Uniswap for ETH.

Background — what OTSeaStaking does#

OTSeaStaking (source) is a fee/revenue-sharing staking vault for the OTSea token:

• Users stake() OTSea; each stake creates a Deposit{ rewardReferenceEpoch, amount } pushed onto _deposits[msg.sender] (:152-163, _createDeposit :357-363).
• The OTSeaRevenueDistributor periodically calls distribute() (or skipEpoch()), which closes the current epoch and rolls a sharePerToken accumulator forward (:133-146). Rewards for a deposit are amount × (sharePerToken[now-1] − sharePerToken[ref-1]) / PRECISION (_calculateRewards :451-460).
• Users claim() ETH rewards for a list of deposit indexes (without unstaking), or withdraw() to both claim and pull their OTSea principal back.

The Deposit.rewardReferenceEpoch field carries a triple meaning that the NatSpec itself spells out (:44-53):

• On deposit → currentEpoch + 1
• On claim → currentEpoch
• On withdraw → 0

That overloading — using 0 as the "withdrawn / dead" sentinel and letting claim() write a non-zero value with no liveness check — is the entire bug.

The vulnerable code#

1. withdraw kills a deposit (sets the dead-sentinel) and uses it as the only double-spend guard#

function _withdrawMultiple(uint256[] calldata _indexes)
    private returns (uint88 totalAmount, uint256 totalRewards)
{
    uint256 length = _indexes.length;
    _validateListLength(length);                       // only checks 1..500, NOT uniqueness
    uint256 total = getTotalDeposits(_msgSender());
    uint32 currentEpoch = _currentEpoch;
    for (uint256 i; i < length; ) {
        if (total <= _indexes[i]) revert DepositNotFound(_indexes[i]);
        totalRewards += _calculateRewards(_msgSender(), _indexes[i]);
        Deposit memory deposit = _deposits[_msgSender()][_indexes[i]];
        if (deposit.rewardReferenceEpoch == 0) revert OTSeaErrors.NotAvailable();   // L381 guard
        _deposits[_msgSender()][_indexes[i]].rewardReferenceEpoch = 0;              // L382 mark dead
        _epochs[...].totalStake -= deposit.amount;
        totalAmount += deposit.amount;                                             // L396 pay principal
        unchecked { i++; }
    }
}

_withdrawMultiple, :370-402

The amount is never zeroed — only rewardReferenceEpoch is. The deposit struct keeps its full principal forever; the only thing that says "this principal is already gone" is rewardReferenceEpoch == 0.

2. claim resurrects any deposit — including dead ones#

function _claimMultiple(uint256[] calldata _indexes) private returns (uint256 totalRewards) {
    uint256 length = _indexes.length;
    _validateListLength(length);
    uint256 total = getTotalDeposits(_msgSender());
    uint32 currentEpoch = _currentEpoch;
    for (uint256 i; i < length; ) {
        if (total <= _indexes[i]) revert DepositNotFound(_indexes[i]);
        totalRewards += _calculateRewards(_msgSender(), _indexes[i]);
        _deposits[_msgSender()][_indexes[i]].rewardReferenceEpoch = currentEpoch;   // ⚠️ no liveness check
        unchecked { i++; }
    }
    if (totalRewards == 0) revert NoRewards();
    return totalRewards;
}

_claimMultiple, :408-423

There is no if (deposit.rewardReferenceEpoch == 0) revert here. A deposit that withdraw() set to 0 is silently flipped back to currentEpoch. Because the deposit's amount was never cleared, it is now indistinguishable from a live deposit, and the next withdraw() pays its principal again.

The claim/withdraw public wrappers (:170-191) add no further protection, and _validateListLength (ListHelper.sol:71-73) only bounds the array length to [1, 500] — it never rejects duplicate indexes either, which is a second, independent way to re-spend the same deposit.

Root cause — why it was possible#

rewardReferenceEpoch is asked to be two things at once:

1. a reward-math anchor that claim() legitimately needs to advance, and
2. a liveness flag where 0 means "this deposit has been withdrawn, never pay it again".

withdraw() respects role #2 (it refuses to act on a 0). claim() only knows about role #1, so it overwrites the flag back to a live value without ever asking "is this deposit still alive?". The two functions disagree about what the field means, and the attacker exploits that disagreement:

withdraw consumes a deposit by setting rewardReferenceEpoch = 0. claim undoes that by setting it back to currentEpoch. Looping the two reuses the same amount indefinitely.

The same field-overloading mistake also leaves the deposit's amount resident in storage after withdrawal. A correct design would either delete the deposit entry on withdraw, or carry a separate boolean withdrawn flag that claim() must honor.

Contributing factors:

• No duplicate-index rejection. _validateListLength checks length only, so even a single withdraw([i, i, …]) would (absent the L381 guard) re-spend i; and a single claim([i, i, …]) re-arms the same index repeatedly.
• claim() is permissionless and free. Re-arming a dead deposit costs only gas, and a closed epoch (any non-zero accrued reward) is enough to clear the NoRewards revert in _claimMultiple.

Preconditions#

• The attacker must own at least one deposit (they staked legitimately first; deposit indexes 0..43+ belong to them). In the PoC the staking position address already held those deposits at the fork block.
• There must be at least one closed epoch with non-zero accrued reward so that claim() passes its totalRewards == 0 ⇒ NoRewards check (:421). The PoC manufactures this by first calling OTSeaRevenueDistributor.distribute(), which ends the current epoch (epoch 31 → 32, distributing 0.2956 ETH) so that _calculateRewards returns a small positive value for every deposit.
• No working capital is needed — the attack pulls the contract's principal directly; the only ETH out is the tiny per-claim reward (10,261,035 wei) and the optional 6M-OTSea → ETH cash-out at the end.

Attack walkthrough (with on-chain numbers from the trace)#

All figures are taken directly from the Withdrawal/Claimed events and storage diffs in output.txt.

The repetition is visible in the raw amounts: 14 consecutive Withdrawal events of 3,026,996.6474802836xx OTSea (decrementing only in the last few wei as totalStake accounting shifts), then 10 of 151,349.83, then 22 of 2,408.80.

Profit / loss accounting#

Reported headline loss: ~$26K (OTSea's market value of the stolen principal at the time).

Diagrams#

Sequence of the attack#

Deposit-state evolution (the resurrection cycle)#

Where the two functions disagree about rewardReferenceEpoch#

Remediation#

1. Give claim() a liveness check. Mirror withdraw's guard inside _claimMultiple: skip or revert on any deposit whose rewardReferenceEpoch == 0. A withdrawn deposit must never be claimable or re-armable.
   SOLIDITYCopy

   // in _claimMultiple, inside the loop:
   if (_deposits[_msgSender()][_indexes[i]].rewardReferenceEpoch == 0)
       revert OTSeaErrors.NotAvailable();
   

2. Stop overloading one field for two jobs. Track withdrawal with a dedicated bool withdrawn (or delete the deposit / zero amount on withdraw) instead of using rewardReferenceEpoch == 0 as both reward anchor and tombstone. Then no amount of claim() can revive consumed principal.
3. Reject duplicate indexes. withdraw/claim should reject repeated indexes in the input list (require strictly increasing indexes, or dedup), closing the within-a-single-call re-spend variant that _validateListLength does not cover.
4. Zero the principal on withdraw. Setting deposit.amount = 0 (in addition to the epoch flag) makes a re-armed deposit pay out nothing, defending in depth even if a liveness check is missed.

How to reproduce#

The PoC was extracted into a standalone Foundry project (the umbrella DeFiHackLabs repo has many unrelated PoCs that fail to compile under a whole-project forge build):

_shared/run_poc.sh 2024-09-OTSeaStaking_exp -vvvvv

• RPC: an Ethereum mainnet archive endpoint is required (fork block 20,738,190). foundry.toml is preconfigured with an Infura archive endpoint; the test reads historical state at that block.
• Result: [PASS] testExploit() with Attacker earned: 37944445168159512442507586 (≈ 37.94M OTSea).

Expected tail:

Ran 1 test for test/OTSeaStaking_exp.sol:ContractTest
[PASS] testExploit() (gas: 6416132)
  Attacker earned: 37944445168159512442507586

Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 37.72s (36.29s CPU time)

Reference: OTSea Staking, Ethereum mainnet, Sep 2024, ~$26K. PoC source: test/OTSeaStaking_exp.sol.

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2024-09-OTSeaStaking_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: OTSeaStaking_exp.sol.

Alerts & third-party analyses

• DeFiHackLabs incident explorer: search "OTSea Staking Exploit".
• Web3Sec X hacked database: search.
• Rekt leaderboard: search.
• Solodit incident search: search.

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.