Reproduced Exploit
Kinetiq — Funds can be permanently locked due to unsafe type casting
1. L1Write.sendTokenDelegate takes uint64 amount. 2. StakingManager casts uint256 → uint64 without SafeCast. 3. For amount = type(uint64).max + 1, the cast becomes 0. 4. Full HYPE is accepted and full kHYPE is minted, but 0 is delegated.
Chain
Other
Category
untagged
Date
Feb 2025
Source
AuditVault
EVM Playground
Source-level debugger — step opcodes and Solidity in sync
The attack is replayed in an in-browser EVM preloaded with the exact dumped fork state. The execution tree shows every call; step by Solidity line or by opcode across all depths — source, Stack, Memory, Storage, Balances (native / ERC-20 / NFT), Transient storage and Return value stay in sync. Click a tree node, opcode, or source line to jump. No backend, no live RPC.
Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 58613-h-05-funds-can-be-permanently-locked-due-to-unsafe-type-cast. Standalone Foundry PoC and full write-up: 58613-h-05-funds-can-be-permanently-locked-due-to-unsafe-type-cast_exp in the
evm-hack-registrymirror.
Vulnerability classes: vuln/integer-bounds · frozen-funds · known-pattern
Reproduction: a self-contained Foundry PoC that compiles & runs in an isolated project with only
forge-std— no fork, no RPC, noanvil_state. Full trace: output.txt. PoC: test/58613-h-05-funds-can-be-permanently-locked-due-to-unsafe-type-cast_exp.sol.
AuditVault taxonomy: severity/high · sector/staking · integer-bounds · frozen-funds · known-pattern
Key info#
| Impact | HIGH — stake above type(uint64).max mints full kHYPE but delegates 0; HYPE locked |
| Protocol | Kinetiq — StakingManager / L1Write |
| Vulnerable code | _distributeStake — uint64(amount) into sendTokenDelegate |
| Bug class | Unsafe downcast truncates delegation amount |
| Finding | Pashov Audit Group · Kinetiq 2025-02-26 · #58613 · H-05 |
| Report | Kinetiq-security-review_2025-02-26 |
| Source | AuditVault |
| Status | Audit finding. Reproduced as a standalone local PoC. |
| Compiler | ^0.8.24 (PoC) |
TL;DR#
L1Write.sendTokenDelegatetakesuint64 amount.- StakingManager casts
uint256 → uint64without SafeCast. - For
amount = type(uint64).max + 1, the cast becomes 0. - Full HYPE is accepted and full kHYPE is minted, but 0 is delegated.
- HYPE remains on the manager with no recovery path → permanent lock.
The vulnerable code#
l1Write.sendTokenDelegate(delegateTo, uint64(amount), false); // @> VULN
// FIX: SafeCast.toUint64(amount)
Root cause#
Solidity's explicit cast to a smaller unsigned type truncates high bits (no revert). Values >= 2^64 wrap in the low 64 bits; 2^64 itself becomes 0. Combined with unlimited maxStakeAmount, a single oversized stake bricks those funds while over-minting receipt tokens.
Preconditions#
maxStakeAmount == 0(unlimited) or> type(uint64).max- Stake amount
> type(uint64).max(PoC usesmax + 1)
Attack walkthrough#
- Stake
type(uint64).max + 1HYPE (~18.45 ether). kHYPE.mintfor the full amount._distributeStakecalls L1 withuint640.- Manager balance still holds the full HYPE; nothing usable on L1 for that stake.
Diagrams#
Impact#
User (or protocol) HYPE can be accepted and receipt-minted while never delegated. Withdrawal paths that assume L1 holdings cannot recover the truncated amount. Large stakes under unlimited caps are permanently stuck.
Sources#
- AuditVault finding #58613
- Pashov Kinetiq review 2025-02-26
- Reduced source: kinetiq-research/lst @ c83aa17 —
StakingManager_distributeStake/uint64(amount)
Sources & further analysis#
Reproductions & code
- Standalone PoC + full trace: 58613-h-05-funds-can-be-permanently-locked-due-to-unsafe-type-cast_exp (evm-hack-registry mirror).
- AuditVault finding: 58613-h-05-funds-can-be-permanently-locked-due-to-unsafe-type-cast.
Alerts & third-party analyses
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.