What happened — in plain terms
When you redeem HCHF through the classic flow, your wallet first creates a token allowance (an "approval") and only then calls the redemption. In the seconds between those two steps, an automated bot sees the open allowance on-chain and uses a public function of the token wrapper contract to sweep the approved amount to itself.
So far: 10 victims, 5,907.60 HCHF stolen, in several waves since July 2026. In the September case the drain happened ~7 seconds after the approval. The core protocol logic worked as designed — the theft happens in the gap between "approve" and "use", and the deployed contracts are immutable, so there is no admin switch to flip.
Reference drain transaction: HashScan ↗ · Full forensics: GitHub ↗
What is safe, what is not
| Action | Status | Why |
|---|---|---|
| Sending HCHF or HLQT to another account | Safe | Plain transfers never create an allowance. |
| Redeem: approve, then redeem in two separate transactions | Exploitable | The standing allowance is visible and can be swept in seconds. |
| Redeem: approve + redeem in one atomic batch transaction | Safe | No allowance exists outside the batch — nothing to steal. Mainnet-tested by a community contributor. |
| Stability-pool withdrawals, unstaking, collateral claims | Safe | These need no allowance and work as normal contract calls. |
1What to do now — three steps
- Don't create fresh HCHF/HLQT approvals through any old frontend or mirror site.Check which site you are really on, and never approve more than exactly what a transaction needs.
- Check your open allowances on HashScan and revoke what you don't need.Open your account on HashScan ↗ — allowances are listed on your account page; anything you don't recognise or no longer need should be revoked.
- If you want to redeem: use the atomic batched flow from the community guide.The approval and the redemption execute as one indivisible transaction. Test with a small amount first. Guide, CLI tool and frontend reference code: GitHub ↗
Important deadline
The atomic-batch method works because Hedera currently allows one smart-contract call inside a batch transaction. Hedera has announced this will be removed around March 2027 (estimated). Until then the batched redemption is the safe exit path — but treat it as a bridge, not a permanent solution. If you plan to exit, don't leave it to the last weeks; the community's planning buffer is end of January 2027.
Verified contract addresses
Counterfeit HLQT/HCHF tokens exist. Always verify against this list (mirrored from the repository manifest ↗, which is the canonical source).
0.0.6070123 0.0.6070128 0.0.6070118 0.0.6070094 0.0.6070108 Scam warning — please read
Nobody legitimate will ever DM you about refunds, "recovering" funds, or a migration tool. That is always a scam. There is no operator, no support team, and no recovery service. The only canonical documentation is the GitHub repository linked on this page. Verify every contract address against the list above, and treat any private message about this incident as hostile.
For developers
The repository contains the full incident report, the complete batched-exit guide (HTML/PDF), a runnable CLI, React + HashPack reference code, and the verified address manifest. If you maintain a frontend, wallet integration or tooling: build the batched flow (native approval inner + single contract call as the final inner transaction), reject truncated redemption amounts, and never request full-debt approvals.