How a Wallet App's Signing Flaw Emptied 1,552 XRP Ledger Wallets

Between 16:29 and 18:34 UTC on September 15, an automated process emptied 1,552 XRP Ledger wallets holding 2,009,321 XRP — about $2.86M at that day's price. Nothing in the drain required the victims to click a link, sign a transaction or approve a contract. The wallets belonged to users of DCENT, the Korean wallet maker known until recently as D'CENT, and what failed was the part of the product that signs: the App Wallet's signing path in versions released before November 2025.

That combination — no user error, no broken cryptography, a key held exactly where the product said it was safe — is what makes the incident worth taking apart. The company's own exposure criteria are the most useful part of the disclosure, because they describe a class of user rather than a class of transaction, and the test they apply is not which device signed but where the recovery phrase went.

1. The Incident in Six Lines

2. What the App Wallet Is, and Where the Phrase Sits

DCENT builds both a hardware wallet and a phone app wallet, and the two differ in exactly one respect that matters: where the private keys exist. A hardware wallet keeps them in a secure element and signs on-device. The App Wallet has to be able to sign from a phone, which means the keys must exist as data inside the phone's software. That is not a defect — it is what an app wallet is — and the same architecture is why the app offers the feature that makes migration convenient: a recovery phrase can be entered to restore a wallet, move to a new device, or simply view a balance.

The detail that turns that convenience into a liability is the nature of the phrase itself. A recovery phrase is a key generator, not a file: it derives, deterministically, every private key the wallet uses, on every chain it supports. Once the phrase exists in software, every key derived from it exists there too — whether or not the user ever signs on the affected chains. That is why a single signing flaw in one app version reached XRP Ledger wallets, and why the exposure criteria had to be written as a condition on the phrase rather than on any one device, chain or transaction.

3. Timeline

4. Where It Broke: The Signing Path

DCENT's public description is deliberately narrow. The company says the App Wallet's signing path in versions before 8.1.0 contained a signing vulnerability, and it withholds the technical detail on the grounds that publishing it would make the technique reusable against people who have not yet migrated. What that leaves on the record is the location of the failure rather than its mechanism: not key generation, not the recovery flow, not the user's behaviour, but the code that turns a key into a signature.

For a wallet user, the location is the transferable lesson. An app wallet is a hot key by design, so the useful question is not whether it is safe in the abstract but how much of a balance that key should ever be able to move. The same month produced a joint advisory from IC3 and its partner agencies describing malware families that harvest wallet keys and seed phrases from developer machines — the identical asset, taken by a different route. Every step that reduces the number of places a phrase exists shrinks both problems at once.

5. Who Was Actually Exposed

The most useful artifact of this incident is the company's own exposure criteria, because they define a class of user rather than a class of transaction. Four conditions place an address inside the affected set: its recovery phrase was at some point entered into the App Wallet; the address has a history of sending or signing, including token transfers, approvals and dApp calls; the signing happened on an app version earlier than 8.1.0; and the address lives on Bitcoin, Ethereum, XRP Ledger, TRON or an EVM network. Read together, those conditions describe anyone who ever typed a seed into a phone app and then used the wallet — a far larger group than the 1,552 already drained.

The same criteria draw a line that many hardware-wallet owners will not expect to be on the wrong side of. A hardware wallet sits inside the affected group only where its recovery phrase had been entered into the app. That is the detail separating "I own a hardware wallet" from "my keys never touched software" — and it means the control is not buying the device but keeping the phrase out of software. On the numbers, only the XRP Ledger leg has been measured, so every total is a floor: on-chain trackers put the XRP drain near $2.86M, SlowMist's public tracker records about $6.57M, and a later XRPL community count describes 6,160 potentially affected addresses and 9.3M XRP. The wallets hit had mostly been created between 2021 and 2023, and the pace of the drain — 204 wallets in fifteen minutes, then a deliberate pause, then 1,336 more — is the signature of a prepared list.

6. The Rest of the Week on the Same Boundary

Three other losses landed in the same seven days, and none of them shared a mechanism with DCENT. What they shared was a property: in each case the system verified exactly what it had been designed to verify, and paid out against something that was not true.

The first was a Gnosis Safe on Ethereum holding a leveraged rsETH position on Aave V3. Safe's core contracts were not compromised and neither were the owner keys. What failed was a whitelisted strategy-executor module: according to BlockSec, SlowMist and AstraSec, it exposed an entry point that forwarded fully caller-supplied calldata into execTransactionFromModuleReturnData with the operation flag set to DELEGATECALL, without gating who could call it. The attacker reached it through a public keeper multicall whose target parameter could be aimed at the contract's own address — and because the module was already trusted, the Safe's signature threshold was never consulted. About 2,900 rsETH, roughly $7.8M, left the Safe. An MEV bot tagged "Yoink" then paid about $47,000 to take the first position in block 25,980,525, captured 2,882.37 rsETH, and left the attacker's own transaction to revert. Kelp DAO placed a 24-hour wallet-level pause on the receiving address; it expired with the funds still there. The conclusion most holders miss is that a Safe's security boundary is the union of everything enabled on it, and that a front-run is not a rescue.

The second was an attacker working one cluster across three projects with two stolen keys. At 20:21:47 UTC on September 19, a call to Fetch.ai's TokenConversionManagerV3 converter moved 8,721,530.40 FET, about $1.53M, to an attacker address; twenty-eight minutes later the NuNet deployer account minted 408.53 million NTX, roughly 42% of that token's circulating supply. The same actor minted 260 million AGIX and 53.838 million WMTx the next day. Fetch.ai attributed the event to a compromised SingularityNET bridge authorizer key and a separately compromised NuNet minting key. Realized proceeds were about $2.25M plus $289,575 taken from a payroll contract, set against roughly $16.77M of unsold minted inventory the market would not absorb — NTX fell between 65% and more than 90%, and WMTx's decline was smaller. Bitquery also reported that most of the compromised signing keys had not been replaced at the time of its analysis, which is what makes a second incident plausible rather than theoretical. Mint authority damages holders without transferring anything out of their wallets: nobody drained a balance, a balance was diluted.

The third was the oldest idea in DeFi, still working. Nostra, a lending market on Starknet, valued NSTR collateral using a price traced back to a pool-selection mechanism on a third-party aggregator. According to GoPlus Security, an attacker seeded a fake NSTR/SolvBTC pool with 1.5 SolvBTC of one-sided liquidity — enough for that pool to be chosen as the reference source — then wash-traded inside it to move the quoted price from about $0.006 to $49.5 within a minute. One account then borrowed approximately $3.5M in ETH, STRK, USDC, USDT, WBTC and DAIv1 against NSTR collateral whose total circulating market capitalisation was under $600,000. PeckShield traced about $1.92M bridged to Ethereum, CertiK placed roughly $1.55M still on Starknet, and 2.2 million STRK left through the NEAR Intents bridge. Nostra paused lending, borrowing, withdrawals and liquidations at 13:28 UTC and its total value locked fell from about $4M to just over $710,000. The question is not how a thin pool was manipulated — that recipe is years old — but why a lending market accepted a collateral asset whose entire float was smaller than the loan it backed.

7. What to Do With This

• The phrase: treat any recovery phrase that has been typed into software as burned. Generate a new one on a device that has never had a wallet app installed, retire the old phrase even after migrating, and never "test" a hardware seed by restoring it into an app.
• The scope of the phrase: assume one phrase protects every chain at once. If it moves into software, everything it derives moves with it — so keep separate phrases for separate purposes, and never reuse an old one after a migration.
• The module: list everything enabled on a smart wallet — modules, guard, fallback handler, helper contracts — and remove anything you cannot explain in one sentence. A module that forwards caller-supplied data is a signing key; a public keeper function reachable by anyone is an attack surface with a queue.
• The project's keys: prefer projects that publish a key inventory and rotate on a schedule. A compromised key that is still live after an incident is a second incident waiting for a quiet weekend, and an unreplaced mint key is an unpriced dilution risk.
• The collateral: before lending into a market, check where the price comes from and how deep it is. If the feed can be satisfied by a pool anyone can create, or the asset's entire float is smaller than your position, you are trusting the attacker to behave.

8. What to Watch

Three questions decide whether this week was an aberration. First, does DCENT publish a root cause and measure the other chains? A floor of $6.57M from one chain family, with Bitcoin, Ethereum, TRON and EVM chains unquantified, is a number that will move — and how the company handles tracing and compensation will set a precedent for app-wallet vendors generally. Second, do the three affected projects reconcile circulating supply and rotate their keys? Until exchanges lift deposit halts and the issuers publish a single supply table, every holder of those tokens is exposed to a quantity they cannot verify. Third, does the exposure test DCENT published become the norm? Describing the affected set by where a phrase went rather than which device signed is the first vendor statement in this record to do so, and if other vendors adopt the same test, migration advice gets simpler for everyone.

Disclaimer: This content is for informational purposes only and does not constitute financial, legal or security advice. No checklist or tool eliminates risk entirely; self-custody means you are responsible for your own keys.