The DCENT XRP Incident: How the Exploit Works

Only weeks after the Coldcard hack, where a weak random number generator in the hardware wallet's firmware made seeds predictable and let an attacker sweep more than $116 million in Bitcoin, another wallet has been drained on a large scale. In September 2026, an attacker emptied thousands of XRP Ledger wallets created with the DCENT App Wallet, the software wallet built into DCENT's mobile app (not its hardware device). Public reporting puts the total near 12.4 million XRP across roughly 7,393 accounts.

DCENT acknowledged the incident in its official status report and traced it to a flaw in the App Wallet that was fixed in app version 8.1.0. According to DCENT, you may be affected if you used the App Wallet, your recovery phrase was stored in the app, and you signed at least one transaction with a version prior 8.1.0.

At first glance, this looks like a repeat of Coldcard. It isn't. The Coldcard attack targeted how the seed was generated. DCENT's seed generation is sound: the recovery phrases were created with strong randomness. The attacker got in through a different door. The victims' phones were never hacked and many of them did nothing wrong at all. What gave the keys away were the transaction signatures.

In this article, we explain on a technical level how that was possible and which method the attacker used to exploit the wallet.

When your wallet sends a transaction, it has to sign it. To do that, it calculates two numbers: r and s. Together, those two numbers are your signature, and they get published on the blockchain for everyone to see.

We can ignore r for now. The danger hides in the second number, s. That’s what the attacker was after.

In technical terms, here's how your wallet calculates s:

s = k⁻¹ · (z + r · d) (mod n)

• z: the transaction itself, turned into a number. Public.
• r: the first number from before. Public.
• n: a fixed number everyone uses. Public.
• d: your private key. Secret.
• k: the nonce. Also secret.

Your private key d is sitting right in this open equation. It's the crucial secret and the only thing hiding it is k, the nonce. As long as k stays secret, your private key is safe, even though z, r and n are all public. The moment someone knows k, they can rearrange the equation and your private key d falls right out:

d = (s · k − z) · r⁻¹ (mod n)

That's where the attacker stepped in. A correctly built wallet makes k impossible to guess. It either draws k from a cryptographically secure random source or derives it deterministically from the transaction and the private key (RFC 6979).

Our own research shows that DCENT's App Wallet did neither. We reverse-engineered the DCENT Android app and traced its signing code down to the native library. It generated k with the phone's ordinary rand() function, seeded once from the current clock time.

In simple terms, the App Wallet fed the time in whole seconds into rand() and used the output to build k. The seed was a single 32-bit value, which allows only about 4.3 billion possibilities. The attacker didn't even need to know when the app was started. Trying all 4.3 billion seeds is an easy job, even for an ordinary laptop. Knowing the transaction's timestamp, which sits publicly on the blockchain, only narrows the search further. So the attacker's recipe became almost mechanical:

1. Take a victim's public signature from the XRP Ledger.
2. Run through the possible seed values (or just the plausible clock seconds around the transaction).
3. For each candidate, replay rand() to reproduce the nonce k.
4. Drop k into the equation, compute a candidate private key and check it against the victim's public key. A match means the private key is exposed.

A nonce is supposed to be a 256-bit needle in an impossibly large haystack. This one was only protected by 32 bits, even fewer than the 40 bits that sank Coldcard's seed phrases. That also explains what the theft looked like: the keys weren't cracked live during the attack. They were computed in advance into a prepared list and then drained in one coordinated sweep.

And here is the part that makes it permanent: a single outgoing transaction is enough to expose that private key forever. The signature is already public and stays public, so updating the app afterwards changes nothing. The exposure happened the moment you first signed a transaction with a vulnerable version of the DCENT App Wallet.

One note for the technically inclined: This is a predictable-nonce flaw, not the classic nonce-reuse bug where the same k is used twice. Here every nonce is different, but because the whole sequence can be replayed from the seed, every one of them is still recoverable. The result is identical.

We didn't analyse this from the outside. We disassembled the DCENT Android app and traced the signing path all the way down: from the Java layer, through the native signing library, to the exact instruction that generates the nonce. The chain ends here:

    HAL_Chip_Random_Generate32:

        if (!seeded) srand(time(0));
        r = rand();          ← the nonce source

Several findings from our analysis support this:

• The seed generation is clean. On the Java side, wallet seeds and keys are created with strong randomness (SecureRandom), and other libraries in the app use RFC 6979 correctly. The flaw lives only in the native C signing library, dcent-core-lib. The source-file names embedded in the binary (knl_hal_chip_random.c, knl_random.c) confirm where it comes from.

• The weak source is library-wide. The same rand()-backed generator feeds other cryptographic material too, not just the nonce. The broken randomness is the library's general random source, so the impact is not limited to one narrow code path.

• It matches DCENT's own statements. DCENT has pointed to a flaw in how the App Wallet signed transactions, and it limits the affected users to those who signed with a version before 8.1.0 (released November 5, 2025). That is exactly the version boundary and the signing-based exposure our findings predict.

DCENT has confirmed the general direction but has not revealed the technical details. Our research fills in that gap. By reverse-engineering the app on an affected version, we traced the flaw down to the exact code that generates the nonce and showed why a single signature was enough to give away the private key. The flaw is verified in the app's code and matches everything we can observe: only wallets that had signed transactions were hit, the affected versions end exactly at 8.1.0, and the funds were drained from a prepared list in one sweep. Unlike the Coldcard incident, the seed generation itself is sound. The weakness sits entirely in the signing process.

A logical question: if the flaw is in the signing library, why was only XRP drained? The flaw is chain-agnostic because it sits below any particular coin. Any signature the App Wallet ever produced on the secp256k1 curve is mathematically exposed in the same way, including Bitcoin, Ethereum, TRON and EVM tokens. DCENT's own list of affected chains reflects this. XRP seemed to be simply the easiest and most profitable place to start for the attacker.

Two things made the XRP Ledger the ideal first target:

• It's trivial to scrape. Balances and signatures sit together in one public, easily queried ledger, so building a target list of exposed high-value accounts is straightforward.
• It settles in seconds, for near-zero fees. Once keys are revealed, moving funds is fast and cheap, which suits a coordinated sweep.

The important takeaway for readers on other chains: the absence of reported losses elsewhere is not proof of safety. Only XRP wallets being drained, solely reflects where the attacker chose to cash out first. Assume exposure on every chain, not just your XRP private keys.

You may be affected if all of these are true:

1. You used the DCENT App Wallet (the software wallet in the app, not the DCENT Biometric hardware device holding the keys).
2. Your recovery phrase was stored or imported in the app.
3. You made at least one outgoing transaction on an ECDSA chain (BTC, ETH, XRP, TRON, EVM tokens).
4. The app version was below 8.1.0 (released November 5, 2025) at the time of signing.

You are not affected by this flaw if your keys only ever lived on the DCENT hardware device, if your App Wallet never sent a single transaction, or if you only ever signed with version 8.1.0 or later. Even so, if you ever entered your seed phrase in the mobile app, we recommend treating the seed as compromised.

Although one could argue that only the private key for the affected chain is revealed, we suggest to act as though every key from that recovery phrase is at risk. Therefore we suggest:

1. Generate a brand-new wallet with a brand-new recovery phrase. Use a different seed and never reuse the old words. Ideally, do this on a hardware wallet.
2. Move all funds to the new wallet promptly. Don't leave dust behind; the attacker watches old addresses.
3. Never sign from the old wallet again. The old keys are public knowledge permanently, and updating the app does not undo that.
4. Don't restore the old phrase into anything, including an updated DCENT app. Create a fresh wallet instead.

One warning matters right now: incidents like this are always followed by a wave of phishing. Fake crypto "recovery" services and impersonators will contact affected users with promises to get their funds back. DCENT itself states that it will never ask you to send assets to an address for "recovery" or "compensation."

Check DCENT's official channels for any remediation or compensation announcements, and verify anyone who reaches out before you engage with them.