Self-Custody
D'CENT Wallet Hack: The Numbers That Decide Your Exposure
D'CENT's report narrows the app wallet hack to versions before 8.1.0 and addresses that signed. The numbers, and what they mean for a mining payout address.
Two days into the D'CENT wallet hack, the company behind it has replaced a broad warning with a narrow test. On September 16, IoTrust told everyone with assets in the D'CENT App Wallet to move them. On September 17 it published a preliminary incident report and a self-check guide that define who is exposed, using a version number, a date and one question about your own history. The brand now spells itself DCENT, but the searches, the headlines and most of the victims still use the old name, so this post does too.
Meanwhile the damage count keeps climbing. ZDNet Korea reported on September 18 that IoTrust has received about 110 reports of abnormal transfers, roughly five times the figure known on day one, when about 20 users had lost XRP worth around 150 million won. If you ever touched the D'CENT app, six numbers from those documents decide what you do next, and one of them reaches into your mining setup.
8.1.0: the version cutoff in the D'CENT wallet hack
The whole test pivots on one release. IoTrust says the issue concerns App Wallet signing done in app versions earlier than 8.1.0, which shipped on November 5, 2025, at about 07:40 UTC. The report stresses that what counts is the version at the moment you signed, not the version installed on your phone today. An app you updated last week does not clean up a transaction you signed with an older build in 2024.
The date also shows how long the exposure sat unnoticed. From that release to the first user report, early on September 16 Korea time, is 315 days. The Crypto Basic's on-chain reconstruction puts the XRP drain between 16:29 and 18:34 UTC on September 15, which is 01:29 to 03:34 on September 16 in Korea, so the first complaints arrived within hours of the attack, not days.
3 conditions, and you need all of them
IoTrust's criteria read like a short checklist. An address is in the affected group when all three of these are true:
- The recovery phrase has been in the App Wallet. That covers wallets created in the app, hardware wallet phrases restored into the app, and App Wallet phrases later moved onto a hardware wallet.
- The address has signed something. Sending coins counts, and so do token and NFT transfers, token approvals and dApp transactions.
- The signing happened on a version before 8.1.0.
The second condition is the new information. IoTrust says addresses that have only ever received are at "comparatively lower" risk, while adding that this "does not mean all risk is excluded." That wording tells you the company's analysis centers on signing, not only on how the phrase was created. It has not published the mechanism, and says it is holding back technical details so copycats cannot reuse them. ZDNet quotes Hanyang University professor Oh Hyun-ok, who suspects the old app used randomness that was too weak when it created recovery phrases or signed transactions, which would let an attacker calculate candidate keys. That is an informed guess, not a finding, and a second expert in the same article notes that phishing has not been ruled out.
5 named networks, Bitcoin included
XRP carries most of the losses, but the report lists Bitcoin, Ethereum, XRPL, TRON, EVM-based chains "and others." ZDNet adds that the stolen funds include Bitcoin, USDT and TRX alongside XRP, now spread across 11 wallets believed to belong to the attacker, with IoTrust asking police and exchanges to freeze them.
Two details are easy to miss. USDT on Ethereum or TRON uses the same key as the chain's native coin, so a token transfer counts as signing even if you never sent ETH or TRX. And on EVM chains one key controls the same address on BSC, Polygon, Base, Arbitrum and the rest, so IoTrust tells affected users to empty that address everywhere, not just on the chain where they noticed a loss.
1,552 wallets in 2 hours and 5 minutes
The best-documented slice of the D'CENT wallet hack is on the XRP Ledger. On-chain records analyzed by XRPL.to and published by The Crypto Basic show 1,552 wallets drained of 2,009,321 XRP in a single window of 2 hours and 5 minutes. That works out to an average of about 1,295 XRP per wallet. Sweeping more than 12 wallets a minute takes an automated script. The pace alone cannot tell you whether the keys leaked from the app or from phishing.
0 reuse: why a mining payout address is in scope
For miners, the key line in the D'CENT wallet hack guidance is about reuse. IoTrust's instructions say to create a brand-new recovery phrase rather than restore the old one, and to never use a previous address again "for any purpose, including deposits." A mining payout address is exactly that: a deposit address you typed into a pool configuration once and then forgot about.
On a non-custodial solo pool like NexusPool, a found block pays straight to the address in your miner's username. There is no pool balance in between, which is the point of the design described on the technology page. It also means nobody in the middle can stop a reward from landing on a key an attacker already holds. If your payout address came from a D'CENT App Wallet phrase that meets the criteria above, the fix is on your side: generate a fresh phrase on a device that never touched the app, change the address in your miner, and confirm the change took. A block reward is 3.125 BTC plus fees, far too large to leave pointed at a key you can no longer vouch for.
Changing the address does nothing to your chances of finding that block. Your odds are set by your hashrate as a share of the whole network's, which difficulty tracks, and they are the same at every pool. What a new address changes is who can spend the reward if it comes. After you update it, Payout Preflight lets you check that the pool's coinbase transaction pays the new address, and Glass Ledger records pool work in a form you can verify offline instead of taking on trust.
The numbers, and what they leave open
The picture as of September 18: one version cutoff (8.1.0, November 5, 2025), three conditions that all have to hold, five named networks including Bitcoin, about 110 reports and rising, 11 attacker wallets, and 1,552 XRP Ledger wallets emptied in just over two hours. What is still missing is the one number that would close the story, a confirmed root cause. IoTrust says it will publish more once disclosure no longer helps attackers. Until then, treat any confident explanation as ahead of the evidence, including the ones quoted here. This post is not investment advice, and it says nothing about the safety of any wallet brand beyond what IoTrust itself has confirmed.
Trust nothing. Verify which recovery phrase your payout address came from, before a block lands on it.