Skip to main content
• 4 min read

hinkal Exploit: $797K
Drained via Proofless Deposit Logic Flaw

$797K in USDC was drained from hinkal after a proofless deposit enabled repeated transact() calls; 454 ETH then moved through Tornado Cash and THORChain.

AUTOSEC.DEVAUTOSEC.DEV
hinkal Exploit: $797K Drained via Proofless Deposit Logic Flaw
  • Incident Date: July 3, 2026
  • Target: hinkal
  • Target Overview: hinkal is a privacy infrastructure protocol that uses zero-knowledge technology to support shielded asset transfers across multiple blockchains. The incident was isolated to one Ethereum smart contract and its related liquidity pools.
  • Total Loss: Approximately 797,000 USDC ($797K)
  • Reported Attacker Address: 0xbB3f01a1b1C68F3DEB36C55342b5F5706c32fc20
  • Affected Contract: 0x25e5e82f5702A27C3466fE68f14abDbbAdFca826
  • Initial Exploit Transaction: 0xbf7252af56be8867a12e27cc332f85e8f39e906756e559d6a076dc8bd9d50008
  • Attack Vector: Smart-contract logic flaw / proofless deposit validation failure

Incident Review & Technical Details​

1. Attack Path​

  1. The attacker prepared the Ethereum address: The reported attacker wallet received ETH for gas before interacting with hinkal's affected contract. Etherscan records show the wallet was active only around the incident window.
  2. A Proofless Deposit transaction established the exploit path: At 00:07:23 UTC on July 3, the attacker called the affected contract in transaction 0xbf7252...d50008, which Etherscan decoded as Proofless Deposit. Public analyses associate this step with a suspected validation flaw, but hinkal has not yet published enough technical detail to confirm the exact missing check.
  3. Repeated transact() calls extracted USDC: The attacker then issued a rapid sequence of transact() calls against the same contract. On-chain reporting identified repeated 25,000 USDC transfers across a compressed block range, indicating an automated withdrawal loop rather than manual execution.
  4. The stolen USDC was converted into ETH: hinkal later confirmed that approximately 797,000 USDC ($797K) was extracted and swapped into approximately 454 ETH.
  5. The proceeds were split across two laundering routes: Approximately 410 ETH was deposited into Tornado Cash in 10 ETH and 100 ETH denominations. A further 44.67 ETH was routed through THORChain and converted into Bitcoin, moving part of the trail beyond Ethereum.

2. Impact Scope​

  • Protocol-Level Loss: hinkal confirmed that approximately 797,000 USDC ($797K) left the affected Ethereum contract.
  • Affected Component: The team said the exploit was isolated to a single Ethereum smart contract and the related Ethereum liquidity pools.
  • Multi-Chain Scope: Deployments on other supported chains were not affected. All contracts were nevertheless paused as a precaution while remediation and security verification continued.
  • User Impact: hinkal committed to reimburse affected users 1:1. The compensation process and schedule had not been published at the time of writing.
  • Fund Recovery Risk: Most of the converted ETH entered Tornado Cash, while the remaining tracked portion crossed into Bitcoin through THORChain, materially complicating tracing and recovery.

3. Official Statements​

  • hinkal: The team said the incident was isolated to one Ethereum contract, other chain deployments were unaffected, and all contracts would remain paused while its preliminary root-cause finding was validated with external security specialists.
  • hinkal reimbursement update: The protocol confirmed the approximately 797,000 USDC ($797K) loss, the conversion into approximately 454 ETH, and its commitment to compensate affected users 1:1.
  • External investigators: CertiK, PeckShield, GoPlus Security, and independent on-chain researchers reported the attacker address, the repeated transact() pattern, and the subsequent Tornado Cash and THORChain fund movements.

4. Investigation Progress​

hinkal said it was working with external security teams to validate the preliminary root cause and trace the stolen assets. The protocol also reported the incident to U.S. federal law enforcement. No recovered funds or completed user reimbursements had been publicly confirmed in the reviewed sources at the time of writing.

The final technical post-mortem should resolve several open questions:

  • Identify the exact invariant or proof-validation check that allowed the Proofless Deposit state to support repeated withdrawals.
  • Explain whether every transact() call reused the same deposit state, nullifier, commitment, or accounting balance.
  • Publish the affected contract version, vulnerable code path, patch, and regression tests.
  • Reconcile the full 797,000 USDC loss against the observed 25,000 USDC transfer batches and any residual transfers.
  • Document the pause timeline, cross-chain verification scope, reimbursement eligibility, and compensation schedule.

AUTOSEC.DEV Solution​

Preventing this failure mode requires testing the proof-validation boundary and the withdrawal state machine as one adversarial system.

  1. Secure Code Review - hinkal's exploit path began with a Proofless Deposit transaction and continued through repeated transact() calls. AUTOSEC.DEV reviews zero-knowledge proof gates, commitment and nullifier handling, state-consumption rules, and asset-accounting invariants to find paths where one accepted state can authorize value movement more than once.
  2. Penetration Testing - The attacker converted a suspected validation gap into an automated series of withdrawals within minutes. We reproduce hostile transaction sequences on a fork, fuzz deposit-to-withdrawal state transitions, and verify that malformed proofs, replayed state, and repeated calls cannot extract more assets than a valid deposit authorizes.

Reference​