D'CENT's App Wallet Leaked Keys Across 6,160 Addresses. Check 3 Things Right Now

What Happened

On September 16, 2026, IoTrust, the South Korean company behind the D'CENT wallet brand, published an urgent notice that it had detected abnormal asset transfers involving its mobile App Wallet and had opened an emergency investigation. A status report followed on September 17 setting out the impact criteria.

The initial documented sweep took roughly 2 hours and emptied more than 1,500 XRP Ledger wallets; coverage on September 23 cites XRPL Intel, an on-chain tracking account, estimating that about 6,160 addresses may be victims and that near 9.3 million XRP was taken, about $15 million at the roughly $1.

64 XRP traded at before its September 24 fall. IoTrust has not confirmed those figures. IoTrust says the problem is confined to the App Wallet, the software product, with no confirmed compromise of D'CENT hardware devices, and it has asked Korea's police cyber unit and exchanges to trace and freeze the proceeds.

It has not published a technical cause. Researchers looking at the pattern have pointed to weak randomness in how older app versions generated keys, which the company has not confirmed and which the disclosed criteria fit poorly: the test turns on whether a key was ever used to sign, and it covers phrases generated on D'CENT hardware and later restored into the app.

A badly generated seed can be found by brute force whether or not it ever signed; a requirement for signing history is more consistent with keys exposed during signing, for example through weak signing randomness, or in how the app handled them.

A secure element protects a key from being extracted. It cannot protect a key that was exposed by the software you typed it into, and that is a question about the software, not the enclosure.

What This Means for You

Run the 3-part test now if you have ever touched this product. Did you type a recovery phrase into the D'CENT App Wallet, did you sign anything with it, and was the app older than version 8.1.0 from November 5, 2025? If all 3 are true, move every asset to a freshly generated wallet on a device you trust and abandon the old seed permanently.

Rotating an address is not sufficient, and neither is updating the app, because the exposure is the seed rather than the software holding it. The same logic makes the shared-mnemonic case worse than it looks: if you imported one phrase into both the app and a hardware device, the hardware device is exposed too.

A secure enclosure protects a key from extraction, and protects nothing about a key that has already leaked from somewhere else.

This is the limit of key control stated as plainly as a week can state it. Self-custody means no third party can move your coins, and it silently assumes that the software touching your seed is sound, from the randomness that created it to the code that signs with it. That assumption sits upstream of every practice the craft recommends, which is why the Coldcard seed flaw in July and this incident belong in the same broad category despite one being hardware and the other an app, whatever the cause here turns out to be.

The durable habit that would have helped here is to keep long-term savings on a seed that has never been typed into general-purpose software. Generating seeds where you can see the randomness (dice rolls, or a device that shows you its entropy source) guards against the Coldcard kind of failure, not against a seed typed into an app.

And read vendor advisories as instructions rather than announcements.

Tracked entities this report names, with total coverage across the archive. Follow one into the Actor Network to see every report it appears in.

Other reports that name the same tracked actors — a different thread than “related,” which follows wording. These are linked by who appears in them.