# Mishandling of receiving HYPE in the StakingManager, user can’t confirm withdrawal and inflate the exchange ratio

StakingManager's receive() auto-stakes any incoming HYPE, so validator-withdrawal HYPE sent back gets re-staked, blocking user withdrawal confirmation and inflating exchange ratio.

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

**Target:** StakingManager.sol receive() on HyperEVM/Hypercore
**Root cause:** receive() unconditionally calls stake(), so HYPE returned from validator undelegation (native gas token on HyperEVM) is re-staked instead of being held for withdrawal payout.
**Steps:**
1. User stakes 1 HYPE via `stakingManager.stake{value: 1 ether}()`; HYPE forwarded to system address on Core.
2. Operator calls `processL1Operations(0)` to delegate to validator.
3. User calls `kHYPE.approve(stakingManager, 1 ether)` then `stakingManager.queueWithdrawal(1 ether)`.
4. Operator calls `processL1Operations(0)` to undelegate; Core sends HYPE back to StakingManager.
5. `address(stakingManager).call{value: 1 ether}("")` triggers `receive()` -> `stake()`, re-staking the HYPE; balance stays 0.
6. After 7 days, `stakingManager.confirmWithdrawal(0)` reverts due to missing HYPE balance.
**How found:** Read Hyperliquid docs noting HYPE is native gas token on HyperEVM, then inspected receive() and traced the withdrawal flow to see returned HYPE re-enters stake().
**Exploitation:** Any HYPE transfer to StakingManager (validator withdrawal return or delegation reward) is auto-staked; with targetBuffer=0 the withdrawing user cannot confirm withdrawal, and with buffer the HYPE is re-staked, minting kHYPE to the system address (locked forever) and inflating the exchange ratio.
**Escalation:** Exchange-ratio inflation via kHYPE minted to system address that is permanently locked, diluting/benefiting remaining holders.
**Insight:** On HyperEVM, native-token transfers hit receive()/fallback; audit any payable receive() that auto-invests funds, since protocol-internal refunds and validator returns will be silently re-deployed instead of held.