# Users Who Queue Withdrawal Before A Slashing Event Disadvantage Users Who Queue After And Eventually Leads To Loss Of Funds For Them

Queued withdrawals lock in pre-slash HYPE amounts, so early withdrawers drain the pool after a slashing event, leaving later stakers unpaid.

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

**Target:** StakingManager/StakingAccountant withdrawal queue
**Root cause:** queueWithdrawal stores hypeAmount computed at queue time; confirmWithdrawal pays that stored amount without recalculating against the post-slash exchange rate.
**Steps:**
1. User queues withdrawal via `queueWithdrawal`, storing `hypeAmount = kHYPEToHYPE(postFeeKHYPE)` at pre-slash ratio
2. Slashing event reduces total HYPE backing, lowering exchange rate
3. Early queuer calls `confirmWithdrawal`, receives full stored `hypeAmount`
4. Contract balance depleted; later queuers cannot be paid their fair share
**How found:** Code reading of queueWithdrawal/confirmWithdrawal showed stored hypeAmount is never recomputed, then modeled a slashing scenario with concrete numbers.
**Exploitation:** Pre-slash withdrawers front-run the slashing impact by confirming first, extracting the full pre-slash HYPE amount and leaving insufficient balance for post-slash queuers.
**Insight:** In staking/withdrawal queues, check whether payout amounts are snapshotted at queue time and whether slashing or rate changes between queue and confirm create a first-come-first-served drain.