Sorra Staking Reward Drain

Epoch advancement is exposed through the public revenue distributor. OTSeaRevenueDistributor.distribute() reads the current epoch from the staking contract and, after the initial owner-only epoch, any caller may trigger the next epoch once minInterval has elapsed. If the distributor holds enough ETH and staking total stake is above the configured minimum, it forwards its ETH into OTSeaStaking.distribute(); otherwise it calls skipEpoch(). This means an unprivileged attacker can make rewards claimable whenever the public timing condition is met.

The relevant public protocol components in this incident are:

• OTSea staking contract: 0xF2c8e860ca12Cde3F3195423eCf54427A4f30916
• OTSea token: 0x5dA151B95657e788076D04d56234Bd93e409CB09
• OTSea revenue distributor: 0x34BCcF4aF03870265Fe99cEc262524F343Cca7ff
• OTSea/WETH Uniswap V2 pair: 0x75eabb7cb05a5057e092fdbbd86fb801b4d02b1f

3. Vulnerability Analysis & Root Cause Summary

The vulnerability is an accounting and lifecycle bug in OTSeaStaking, not a pricing anomaly or privileged backdoor. The intended safety invariant is that once a deposit has been withdrawn, it is terminal and must never again earn rewards or release principal. OTSeaStaking::_withdrawMultiple() enforces the first half of that lifecycle by reverting if rewardReferenceEpoch == 0, then setting rewardReferenceEpoch to 0 and returning deposit.amount to the caller.

The bug is in OTSeaStaking::_claimMultiple(). That function loops over each requested deposit index, adds the rewards from _calculateRewards, and then writes _deposits[_msgSender()][_indexes[i]].rewardReferenceEpoch = currentEpoch for every listed deposit. There is no check that the deposit was still active. If at least one index in the claim list has positive rewards, totalRewards is non-zero, NoRewards() is avoided, and previously withdrawn deposits are revived along with the live deposit.

Once revived, the deposit still retains its original amount. A later withdraw() call will load that same amount and transfer it again, producing duplicate principal release. The public distributor is what makes the sequence practical for any attacker: it lets the adversary create a reward-bearing deposit in the same public environment and then pair it with a previously withdrawn index during claim().

4. Detailed Root Cause Analysis

The key victim-side code path is the interaction between withdraw() and claim() in OTSeaStaking:

function _withdrawMultiple(uint256[] calldata _indexes)
    private
    returns (uint88 totalAmount, uint256 totalRewards)
{
    ...
    Deposit memory deposit = _deposits[_msgSender()][_indexes[i]];
    if (deposit.rewardReferenceEpoch == 0) revert OTSeaErrors.NotAvailable();
    _deposits[_msgSender()][_indexes[i]].rewardReferenceEpoch = 0;
    ...
    totalAmount += deposit.amount;
}

function _claimMultiple(uint256[] calldata _indexes) private returns (uint256 totalRewards) {
    ...
    totalRewards += _calculateRewards(_msgSender(), _indexes[i]);
    _deposits[_msgSender()][_indexes[i]].rewardReferenceEpoch = currentEpoch;
    ...
    if (totalRewards == 0) revert NoRewards();
}

_withdrawMultiple() treats rewardReferenceEpoch == 0 as the terminal withdrawn state. That matches the submitted invariant. But _claimMultiple() does not preserve that terminal state. It recalculates rewards and overwrites the epoch for every index in the claim list, even if that deposit was already withdrawn.

The seed transaction and the validator fork both show the same exploit chain:

1. The attacker buys OTSea from the public Uniswap V2 pool.
2. The attacker stakes twice, creating deposit indexes 0 and 1.
3. The attacker triggers OTSeaRevenueDistributor.distribute() once using the distributor's existing ETH balance and again after funding the distributor and waiting the public interval, advancing staking to a reward-bearing epoch.
4. The attacker withdraws deposit 0, causing rewardReferenceEpoch for deposit 0 to become 0.
5. The attacker calls claim([0,1], attacker). Deposit 1 contributes positive rewards, so the call succeeds. During the same loop, deposit 0 is rewritten from 0 to the active epoch.
6. The attacker calls withdraw([0,1], attacker) and receives principal for deposit 0 again.

The validator fork trace reproduces the exact breakpoint:

OTSeaStaking::withdraw([0], attacker)
...
OTSeaStaking::getDeposit(attacker, 0) -> Deposit({ rewardReferenceEpoch: 0, amount: 1609078533632580711145 })
OTSeaStaking::claim([0, 1], attacker)
...
OTSeaStaking::getDeposit(attacker, 0) -> Deposit({ rewardReferenceEpoch: 33, amount: 1609078533632580711145 })
OTSeaStaking::withdraw([0, 1], attacker)
...
OTSeaERC20::transfer(attacker, 3218157067265161422290)

The seed balance diff is consistent with the same bug at incident scale. OTSeaStaking lost 43944445168159512442507586 raw OTSea units, and the adversary profit-taking contract 0x5aec8469414332d62bf5058fb91f2f8457e5c5cb gained 37944445168159512442507586 raw OTSea units while another 6000000000000000000000000 raw OTSea units were sold into the public Uniswap pool during the same transaction. That state transition is consistent with duplicate release of principal from staking followed by partial monetization.

The ACT conditions described in root_cause.json are also supported by code and traces:

• The attacker can buy OTSea publicly on Uniswap.
• The attacker can open at least two deposits.
• The attacker can trigger a public epoch distribution once the public timing condition is met.
• At least one live deposit with positive rewards can be paired with a previously withdrawn deposit in claim().
• The revived deposit can then be withdrawn again.

5. Adversary Flow Analysis

The seed transaction sender was EOA 0x000000003704bc4ffb86000046721f44ef3dbabe, which called helper contract 0xd11ee5a6a9ebd9327360d7a82e40d2f8c314e985. The submitted root cause also identifies 0x5aec8469414332d62bf5058fb91f2f8457e5c5cb as the contract that ended the transaction with the drained OTSea balance reflected in the balance diff. Those account assignments are consistent with the seed metadata and balance deltas.

The on-chain execution has three stages:

1. Epoch Trigger The helper path calls the public distributor. The seed trace records OTSeaRevenueDistributor::distribute() followed by OTSeaStaking::distribute{value: 295647903437594148}(), proving the attacker relied on a public epoch transition.

2. Deposit Reactivation Earlier in the sequence, a deposit is withdrawn and its rewardReferenceEpoch is zeroed. Later, claim() is invoked with a mixed list that includes a withdrawn index and a still-live reward-bearing index. Because _claimMultiple() rewrites all listed indexes, the withdrawn deposit becomes active again.

3. Duplicate Withdrawal And Monetization The attacker withdraws the revived indexes again, receives duplicate OTSea principal and ETH rewards, then routes part of the OTSea through the public Uniswap market. The trace also contains the large 6000000000000000000000000 OTSea sale size cited in the root cause.

The exploit is single-transaction and permissionless. No privileged role, leaked key, attacker-side ABI, or off-chain secret is required. The only requirements are public contracts, public balances, and a reward-bearing deposit to avoid NoRewards().

6. Impact & Losses

The measurable loss in the submitted analysis is:

• OTSea: 43944445168159512442507586 raw units (decimal = 18)

The seed balance diff shows that OTSeaStaking lost exactly that amount during the transaction. The same artifact shows the adversary profit-taking contract ending with 37944445168159512442507586 raw OTSea units and the remaining 6000000000000000000000000 raw OTSea units being sold during the same transaction. The incident therefore drained principal directly from the staking contract rather than merely extracting rewards.

The affected parties are OTSea stakers and the staking pool itself. The exploit breaks the protocol's expected conservation of staked principal, so any remaining users are exposed to a direct depletion of the staking contract's token reserves.

7. References

1. Seed transaction metadata for 0x90b4fcf583444d44efb8625e6f253cfcb786d2f4eda7198bdab67a54108cd5f4
2. Seed trace for 0x90b4fcf583444d44efb8625e6f253cfcb786d2f4eda7198bdab67a54108cd5f4
3. Seed balance diff for 0x90b4fcf583444d44efb8625e6f253cfcb786d2f4eda7198bdab67a54108cd5f4
4. OTSeaStaking.sol source bundle containing withdraw() and _claimMultiple()
5. OTSeaRevenueDistributor.sol source bundle containing the public distribute() gate
6. Validator fork execution log showing independent reproduction in forge test