Hinkal Hack: How 772,000 USDC Was Stolen and Laundered

AML Crypto traced the 772,000 USDC stolen from Hinkal through Tornado Cash, THORChain, and Bitcoin, uncovering digital traces that could help identify the attacker.
Get advice from AML Crypto experts
This article examines the incident involving the Hinkal privacy protocol that occurred on July 2, 2026. The case is noteworthy from several perspectives: the attacker’s actions, the traces they inevitably left while withdrawing and laundering the funds, and the messages sent via the blockchain during negotiations with them.

The AML Crypto team reconstructed the flow of the stolen funds using Bholder.
Below, we examine the victim, the mechanics of the attack, the withdrawal timeline, and, most importantly from a practical standpoint, the services that may retain digital traces relevant to the further investigation.
  • Victim:
  • Brief overview:
    Hinkal is a zero-knowledge-based privacy protocol for private transactions on public blockchains. Its purpose is to conceal wallets, transaction amounts, and counterparties from external observers while keeping transactions publicly verifiable.

    What it does: It allows users to deposit assets into a “shielded” or private layer and then privately transfer, withdraw, swap, or use them in DeFi without creating a direct link to the originating address.
  • Date of the incident:
    July 2, 2026, at 19:05 UTC
  • Nature of the incident:
    Hinkal reported a security incident involving anomalous USDC activity on the Ethereum network. According to the team and external investigations, the incident was limited to a single smart contract and its associated liquidity pools on Ethereum; deployments on other networks were not affected. The estimated loss was approximately 772,000 USDC.

    Preliminary findings indicate that the attack was linked to a flaw in the smart contract’s logic. According to on-chain analysis, the attacker was able to exploit this flaw, execute transactions without properly confirming a deposit, and then withdraw USDC from the contract through a series of transactions. On-chain data suggests that the attacker used a “proofless deposit” scenario before carrying out multiple USDC withdrawals from the contract.
Proofless deposit
In privacy pools such as Hinkal, balances are hidden. As a result, the right to withdraw funds is not verified through a publicly visible balance, but through a cryptographic proof—a zero-knowledge proof stating, in effect, “I hold a valid note for this amount, and it has not already been spent.” The contract verifies the proof and only then recognizes the transaction as legitimate.

A proofless deposit is the registration of a deposit record in the pool without this mandatory verification. Due to an error, the contract accepts a “receipt” for funds even though no tokens were actually deposited and no valid cryptographic proof exists.

Actions taken as of the time of publication

  • Hinkal paused its smart contracts to investigate the incident, address the issue, and conduct additional security checks.
  • The team is also tracking the funds in cooperation with blockchain security firms, has reported the incident to U.S. federal law enforcement agencies, and has committed to compensating affected users on a 1:1 basis. Details of the compensation process and timeline are expected to be published separately.
  • Hinkal sent the attacker an on-chain message offering to resolve the incident as a white-hat recovery: return 90% of the funds to the Hinkal owner address,
    0xBdc77a0c69f13207aCB70a6981Cad60B4c1D1942, and retain 10% as a reward. If the funds are returned, the company stated that it would not pursue civil action and would publicly describe the incident as a recovery rather than an attack. The deadline for accepting the offer was set for July 11 at 23:59 UTC; after that, Hinkal intends to pursue the matter through law enforcement. Similar messages were sent on the Bitcoin network through the following transactions: 6e46ebf43a11788c428025907e17597506f64a5d0d55563c48b57a997334e8f9 36c7a0e3af6c17986a4c47063d6a0a931a79268bbcee36c214f04cea61d7f6e5 1ec41c2cd2c4c2e0dc0ed2f42d5c2678166001ae14962dc00f77f039735f8a49 dcd96497c8c723a34626bf0817d389e963520724fd117d3a928ace587059092f d396afc1c94ba0efa00323e81498a118398d130ee0962c96473c9dbb87e9d4a3
Requests for the return of funds:
We think you may not be someone who does this kind of thing, and that this may have gone further than you expected. If that's true, there's a clean way out, and it's still fully open to you. Return 90% to 0xBdc77a0c69f13207aCB70a6981Cad60B4c1D1942 (the Hinkal owner address, which you can verify) and keep 10%. If you do, we treat it as a white-hat recovery, take no civil action, and describe it publicly as a return rather than an attack. This ends here, and it doesn't have to define you. The funds are also difficult to move without exposure, and that only grows over time. Decide within 72 hours, by 11 July at 23:59 UTC. If the funds aren't returned by then, we'll pursue this through law enforcement. But that's not the outcome we're hoping for. The choice is yours. If you want to talk it through, we're at recover@hinkal.pro. [link]
Hinkal exploit notice: whitehat deal, keep 10%. 72h. Email: team_acc@hinkal.pro [link] [link]

List of services the attacker interacted with

Service 1: Metamask
  • Nature of the connection:
    An address believed to be part of the suspected attacker’s cluster used the MetaMask Swap service, indicating that the address was accessed through the MetaMask wallet.
  • Reason for contacting the service:
    MetaMask’s official Terms of Use state that, by using MetaMask and its offerings, users consent to the collection, use, disclosure, and other processing of information in accordance with the Privacy Notice. The official Consensys/MetaMask Privacy Notice indicates that MetaMask/Consensys may process IP addresses, wallet- and transaction-related information, wallet addresses submitted through API requests under the default settings, as well as device and usage information, including IP addresses, approximate location, device data, browser type, device identifiers, cookie data, and interactions with the offerings.
  • Contact information:
Service 2: Vizor.cash
  • Nature of the connection:
    A portion of the funds held at the attacker’s address originated from Vizor.cash, a cryptocurrency wallet that uses the NEAR Intents API to execute swaps.
  • Reason for contacting the service:
    When synchronizing and broadcasting transactions, Vizor connects to Zcash network services and lightwalletd endpoints. Endpoint operators and network providers may receive technical metadata, including the user’s IP address, request timestamps, endpoint requests, requested blockchain data, and transaction broadcast data. Although the contents of shielded Zcash transactions are protected by the protocol, network-level metadata may still be visible to infrastructure providers.
Service 3: OKX DEX
  • Reason for contacting the service:
    According to the OKX Web3 Privacy Notice, OKX may collect and retain data related to transactions conducted through the OKX Web3 Platform, balances of connected wallets, communications with customer support, and technical identifiers such as device fingerprints, IP addresses, MAC addresses, geolocation data, unique device identifiers, and session information. OKX may also collect information about activity on third-party web applications and websites when the OKX Web3 Wallet interacts with those services.
  • Contact:
Service 4: Thorchain
  • Reason for contacting the service:
    If the attacker used swap.thorchain.org specifically, the Privacy Policy states that the service may collect wallet addresses, transaction information, correspondence, and chatbot interactions. It may also automatically collect IP addresses, browser, device, and operating system data, access times, pages viewed, log files, referring and exit pages, clickstream data, and analytics information. RPC providers, analytics services, Cloudflare, and customer support tools may also be involved.
  • Contact:
    The emergency procedures documentation recommends contacting the team or administrators through the Dev Discord, tagging
    @thorsec when necessary, or submitting a report through the bug bounty program.
Service 5: Binance
  • Reason for contacting the service:
    According to Binance’s Privacy Notice and Privacy Portal, Binance processes the following categories of data: identity and KYC information, contact details, financial information, transactional information, browsing information, usage data, and information related to AML/KYC procedures and account security. Privacy notices applicable in certain jurisdictions also explicitly mention government-issued identifiers, sensitive and biometric personal data, blockchain data, communications with customer support, and browsing and service usage data.
  • Contact:
    Binance Government Law Enforcement Request System (LERS). A separate Binance Legal form is available for legal representatives and third-party court orders.

Timeline of Events

  • Stage 0: Identified On-Chain Preparations for the Criminal Activity
2026-07-01 09:35:59
2026-07-01 09:35:59
Test run through Tornado Cash: verification of the mixer as a laundering tool one day before the incident.
2026-07-02 19:02:11
2026-07-02 19:02:11
Swap of ZEC for ETH through Vizor.cash (0.26 ETH, approximately $436) to test the vulnerability and provide native tokens to the addresses involved in the testing and subsequent theft.
2026-07-02 19:05:11
2026-07-02 19:05:11
Swap of ETH for USDC through OKX DEX to test the vulnerability in Hinkal.Pro.
  • Stage 1: Execution of the Criminal Scheme
2026-07-02 19:56 – 22:21
2026-07-02 19:56 – 22:21
Final testing of the protocol vulnerability.
2026-07-02 21:42:11 – 21:49:47
2026-07-02 21:42:11 – 21:49:47
Funding of the addresses involved in the attack with ETH to cover gas fees.
2026-07-02 22:11:35 – 2026-07-03 00:19:23
2026-07-02 22:11:35 – 2026-07-03 00:19:23
Withdrawal of funds from the contract: 797,000 USDC and 0.08 ETH across 85 transactions. The attack lasted 2 hours, 7 minutes, and 48 seconds.
2026-07-03 00:07:23
2026-07-03 00:07:23
Transfer of 25,000 USDC back to Hinkal.Pro, presumably in an attempt to carry out an additional theft. The attempt was likely unsuccessful; the final amount stolen was 772,000 USDC.
  • Stage 2: Laundering of the Funds
2026-07-03 00:17:11
2026-07-03 00:17:11
Start of the USDC-to-ETH swap through the decentralized exchange Uniswap.
2026-07-03 00:43:23 – 00:48:11
2026-07-03 00:43:23 – 00:48:11
Deposit of ETH into Tornado Cash across 14 transactions.
2026-07-03 01:18:35 – 01:28:11
2026-07-03 01:18:35 – 01:28:11
Withdrawal of funds from Tornado Cash.
2026-07-03 01:23:23
2026-07-03 01:23:23
Swap of 44.67 ETH for BTC through THORChain.
2026-07-03 02:35:23 – 03:20:12
2026-07-03 02:35:23 – 03:20:12
Transit activity on the Bitcoin network.
2026-07-03 03:25:51
2026-07-03 03:25:51
Withdrawal of a portion of the funds to a Binance deposit address.
2026-07-03 04:03:57
2026-07-03 04:03:57
Deposit into an unidentified service. Address 1 displayed an “accumulation → spending” pattern, while Address 2 showed extensive transaction activity involving funds from multiple participants.
2026-07-03 11:56:38 – 2026-07-08 19:16:32
2026-07-03 11:56:38 – 2026-07-08 19:16:32
Deposits into an unidentified exchange or wallet with a built-in CoinJoin function.

Analyst’s Notes

  • Correlation of Fund Flows Through Tornado Cash
    It can be inferred with a high degree of confidence that a portion of the funds was routed through Tornado Cash. This hypothesis is based on the convergence of several factors: the timing pattern, the amounts involved, the number of transactions, and the correspondence between deposit denominations and subsequent withdrawals from Tornado Cash.

    In other words, the timing and amounts of the incoming and outgoing transactions are consistent with one another, providing a reasonable basis for treating Tornado Cash as one of the stages used to obscure the trail of funds.
  • Pre-Incident Testing of Tornado Cash
    Two days before the main incident, the suspected attacker carried out a test withdrawal of 0.1 ETH through Tornado Cash. Such a test may indicate that the withdrawal infrastructure was prepared in advance and that the intended fund-routing path was verified before the main attack.

    This, in turn, strengthens the hypothesis that the attack was premeditated rather than spontaneous.
  • Attacker Activity in the Zcash Ecosystem
    The suspected attacker was also observed operating within the Zcash ecosystem. In the context of this case, the use of privacy tools and anonymizing blockchain services appears to form a consistent part of the attacker’s operational pattern.

    Particular attention should be paid to the fact that a portion of the funds originated from Vizor.cash, a privacy-focused service associated with Zcash that supports swaps through NEAR Intents.
  • Evidence of CoinJoin Use on the Bitcoin Network
    Activity associated with the suspected attacker was also identified on the Bitcoin network. In particular, CoinJoin transactions were observed, potentially executed using a specialized privacy tool, most likely Wasabi Wallet.

    This type of activity may indicate an additional attempt to hinder the subsequent attribution and tracing of the funds after they were moved onto the Bitcoin network.
  • Interpretation of Fund Flows Through Tornado Cash and THORChain
    As part of the incident, the suspected attacker began moving the stolen funds through Tornado Cash between 2026-07-03 00:43:23 and 2026-07-03 00:48:11.

    Subsequent withdrawals from Tornado Cash were recorded between 2026-07-03 01:18:35 and 2026-07-03 01:28:11.

    Later, at 2026-07-03 01:23:23, a transaction was executed through THORChain. This indicates that the attacker used several routes simultaneously during the laundering process: a portion of the funds may have been retained or withdrawn as an “operational balance” or potential reward, while the main flow may have been directed toward further obfuscation.

    It can be preliminarily assumed that the branch involving THORChain may be the most promising avenue for further analysis, as the attacker may have made an operational mistake or left additional traces that could help establish the subsequent movement of the funds.
  • Conclusions on the incident
    The combined evidence suggests that the attack on Hinkal was planned in advance. This is supported by the test transaction through Tornado Cash before the incident, the consistent use of anonymization tools, and the rapid distribution of the stolen funds across multiple blockchains and services. The use of Tornado Cash, Zcash infrastructure, and CoinJoin appears not to be a series of isolated actions, but rather part of a coordinated strategy aimed at breaking transactional links and complicating subsequent attribution.

    However, complete anonymity was not achieved. Temporal and value-based correlations, distinctive transaction patterns, and interactions with THORChain, MetaMask, Vizor.cash, Binance, and OKX DEX create several potential avenues for further investigation. The branch involving THORChain and the subsequent movement of funds onto the Bitcoin network appears to be the most promising, as the attacker may have left additional technical and behavioral traces there.
    Obtaining data from the services involved and correlating it with the results of the on-chain analysis could significantly narrow the pool of potential actors and help establish the subsequent route of the stolen assets.

Attacker’s addresses

Fraud transactions

  • Transaction in the Reverse Direction:
Want to learn more and get expert advice? Leave your email and we will contact you promptly!
We also recommend