A white-hat researcher’s recovery of 1,003.62 ETH from a failed 2016 Ethereum ICO has turned an old smart contract flaw into a reminder that Ethereum’s earliest technical decisions can remain live for nearly a decade.
The researcher, known as 0xFlorent, said he unlocked the ETH from the HongCoin contract after the funds had been trapped for nine years. Using a June 1 Ethereum price of roughly $1,983, the recovered amount was worth about $1.99 million.
The recovery depended on the original HongCoin multisig. The HongCoin contract still required action from that management path for the relevant admin calls.
That made the episode closer to contract archaeology than to a conventional exploit: the same immutable code that preserved the refund failure also preserved a forgotten route around it.
HongCoin’s contrast is stark. Ethereum’s base layer stayed still. A still-valid permission path and coordinated signing from the original multisig made 48 original investors eligible to claim funds through a refund mechanism that had been broken for years.
How the refund path broke
HongCoin was a 2016 Ethereum project whose public repository described it as a decentralized venture fund. The token sale failed to reach its funding goal, and contributors were supposed to be able to reclaim their ETH through the contract’s refund function.
The problem sat inside the contract’s accounting. In the HongCoin source code, the refundMyIcoInvestment() function checks whether the caller’s token balance is greater than tokensCreated. If that condition is true, the refund call fails.
If it passes, the function zeroes the caller’s token balance, clears related accounting, reduces tokensCreated by that token balance, and then sends the refund.
Over time, earlier refunds reduced the global tokensCreated counter. That left larger holders in a strange position: they still had balances tied to their original claims, but those balances could be too large for the contract’s remaining counter.
The refund function then treated them as invalid, blocking the very users it was supposed to repay.
The escape path was another old piece of code. The multisig-restricted mgmtIssueBountyToken() admin function could add a supplied amount to a recipient’s balance and to bountyTokensCreated.
That path belonged to the management side of the contract, which is why the original multisig had to participate. Modern Solidity arithmetic reverts by default on overflow.
Before Solidity 0.8.0, arithmetic wrapped on overflow unless developers added their own checks. The older behavior shaped the escape route.
0xFlorent identified a way to use the admin function’s arithmetic behavior to reset a holder’s balance low enough for the refund check to pass. The result was paradoxical: one stale bug helped undo the practical damage caused by another stale bug.
| Stage | Key detail |
|---|---|
| 2016 token sale | HongCoin collected ETH for a venture-fund-style Ethereum project that later failed to reach its goal. |
| Refund failure | The refund function rejected larger holders once the global token counter fell below their balances. |
| Old admin path | A multisig-restricted function still existed that could change balances using pre-0.8 Solidity arithmetic behavior. |
| Whitehat recovery | 0xFlorent coordinated with the original HongCoin multisig to make blocked holders eligible to claim funds. |
| On-chain proof | A May 29 transaction shows a successful refundMyIcoInvestment() call producing an internal 96 ETH transfer. |
The multisig made it a coordinated recovery
The multisig requirement set a boundary for the HongCoin recovery. The sensitive path required HongCoin’s original management address to execute the relevant calls, so the practical recovery depended on cooperation between the researcher and the old control path.
The coordination carried as much weight as the code. The recovery involved 41 signed transactions for blocked holders, while another seven smaller holders could refund directly without the workaround.
The ICO began on Aug. 29, 2016, ended on Oct. 28, 2016, and failed to meet its funding goal.
The on-chain record already shows refund activity. A May 29 on-chain transaction called refundMyIcoInvestment() and produced an internal transfer of 96 ETH from the HongCoin contract to an investor address.
The top-level transaction value was 0 ETH because the actual movement happened inside the contract call.
Anyone following the money should separate eligibility from completed distribution. The contract state and multisig execution reopened a claim path for funds that had been inaccessible for years.
The visible on-chain examples show refund activity rather than a full accounting of every eligible investor’s claim.
The HongCoin case should be read carefully before anyone generalizes it to other old stuck funds. The ingredients were unusually specific: identifiable contract logic, an admin function still usable by the original control path, a whitehat willing to coordinate, and enough remaining on-chain value to make the effort worthwhile.
The practical detail is ownership and permission. The old function could change balances, but only the management path could call it.
That gives the recovery its ethical and operational boundary: outside research found the path, original signers executed it, and the claim route reopened for investors.
The same facts also make the case hard to generalize. Many dormant contracts lack an active control key, a clean claimant set, or a public trail that makes responsible recovery plausible.
That boundary also reduces the temptation to treat the episode as a broad exploit template. The technical mechanism explains why the refund gate reopened, but the story’s consequence comes from the combination of old code, living permissions, and public settlement.
Similar archaeology becomes riskier when a contract lacks one of those elements, because discovery can expose a weakness before it creates a usable recovery route.
Ethereum keeps the mistake and the remedy
The broader Ethereum history makes the HongCoin recovery more than a curiosity. A 2025 analysis citing Coinbase’s Conor Grogan put permanently lost ETH at more than 913,111, framed as a conservative estimate across user and contract-related errors.
That category includes funds sent to burn addresses, contract bugs, and major historical incidents.
Some of Ethereum’s most consequential early moments were also recovery debates. In 2016, the DAO hard fork moved roughly 12 million ETH from DAO-related contracts into a recovery contract after the network’s defining governance crisis.
In 2017, Parity Technologies’ multisig library self-destruct incident blocked 513,774.16 ETH across 587 wallets.
Those episodes were larger and politically heavier than HongCoin. They still help frame why this smaller recovery resonates.
Ethereum’s promise that code and state persist is a security property and a memory system. It preserves errors, half-forgotten assumptions, old permissions, and the occasional remedy whose future relevance was invisible at deployment.
That long memory now sits beside a maturing security culture. In January, Ethereum veterans announced plans to convert roughly 75,000 ETH in leftover TheDAO recovery funds into a staked endowment for Ethereum security.
The HongCoin case works on a much smaller scale, but points to the same afterlife of early Ethereum decisions.
The next test is recoverability: whether other old contracts contain paths that can be used responsibly. A white-hat recovery needs more than a bug. It needs a rightful control path, public on-chain evidence, careful disclosure, and a way to avoid turning contract archaeology into a playbook for opportunistic attacks.
HongCoin shows that some trapped funds can remain suspended inside old logic, waiting for someone to understand both the flaw and the permission structure around it. That is a hopeful result for the 48 investors now eligible to claim.
It is also a warning for the rest of the ecosystem: Ethereum remembers bad code, and sometimes it remembers the escape hatch too.
The post Failed Ethereum ICO from 2016 just unlocked 1,003 ETH by exploiting itself appeared first on CryptoSlate.
