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.

Feb 2025Otheruntagged3 min read

Chain

Other

Category

untagged

Date

Feb 2025

Source

AuditVault

EVM Playground

Source-level debugger — step opcodes and Solidity in sync

evm-hack-analyzer

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.

Loading fork state…

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-registry mirror.


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, no anvil_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#

ImpactHIGH — stake above type(uint64).max mints full kHYPE but delegates 0; HYPE locked
ProtocolKinetiq — StakingManager / L1Write
Vulnerable code_distributeStakeuint64(amount) into sendTokenDelegate
Bug classUnsafe downcast truncates delegation amount
FindingPashov Audit Group · Kinetiq 2025-02-26 · #58613 · H-05
ReportKinetiq-security-review_2025-02-26
SourceAuditVault
StatusAudit finding. Reproduced as a standalone local PoC.
Compiler^0.8.24 (PoC)

TL;DR#

  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.
  5. HYPE remains on the manager with no recovery path → permanent lock.

The vulnerable code#

SOLIDITY
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 uses max + 1)

Attack walkthrough#

  1. Stake type(uint64).max + 1 HYPE (~18.45 ether).
  2. kHYPE.mint for the full amount.
  3. _distributeStake calls L1 with uint64 0.
  4. Manager balance still holds the full HYPE; nothing usable on L1 for that stake.

Diagrams#

sequenceDiagram participant User participant SM as StakingManager participant L1 as L1Write User->>SM: stake type uint64 max plus 1 SM->>SM: mint full kHYPE SM->>L1: sendTokenDelegate uint64 cast Note over L1: amount becomes 0 Note over SM: full HYPE locked on manager

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#


Sources & further analysis#

Reproductions & code

Alerts & third-party analyses

  • Web3Sec X hacked database: search.
  • Rekt leaderboard: search.
  • Solodit incident search: search.

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.