# Processing all withdrawals before all deposits can cause some deposit to not be delegated in processL1Operations

In Kinetiq StakingManager, processing all withdrawals before deposits in processL1Operations leaves some HYPE undelegated, reducing vault staking rewards.

- Payout: Contest reward
- Severity: medium
- Program: Kinetiq
- Credited: Infect3d
- Disclosed: 2025-07-07
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2025-04-kinetiq#m-04
- Library page: https://bugbountylibrary.com/r/c4%3A2025-04-kinetiq%3AM-04
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** StakingManager.processL1Operations on Hyperliquid L1 staking
**Root cause:** processL1Operations processes all withdrawals (moving staking->spot) before deposits (delegating staking), so withdrawal amounts drain the staking balance before deposits can be delegated, leaving residual undelegated funds.
**Steps:**
1. Alice stakes 10 HYPE, Bob 1, Carol 1 (1:1 kHYPE, 10% withdrawal fee)
2. Alice queues withdrawal of 10 kHYPE (9 HYPE), Bob queues 1 kHYPE (0.9 HYPE)
3. Operator calls `processL1Operations()`
4. `_processL1Withdrawals` runs first: undelegations fail (nothing delegated), 9 HYPE and 0.9 HYPE moved staking->spot
5. `_processDeposits` runs: Alice's 9 HYPE delegation fails (insufficient staking balance), Bob's 1 and Carol's 1 succeed
6. Final delegated = 2 HYPE instead of expected 2.1 HYPE; 0.1 HYPE stranded in staking balance
**How found:** Reasoned through the balance model (EVM, spot, staking, delegated) and the fixed ordering of withdrawal-then-deposit processing, then constructed a numeric example showing the staking balance is drained by withdrawals before deposits delegate.
**Exploitation:** Not an attack; operator-triggered ordering bug causes systematic under-delegation whenever withdrawals and deposits are batched together, reducing yield.
**Insight:** When auditing batched L1 operation processors, check whether per-item ordering (all withdrawals before all deposits) can transiently drain a shared intermediate balance, causing later operations to silently fail rather than net out.