DCENT App Wallet Security Incident: Which Users Need to Act and How to Protect Their Assets

🔐 If you used DCENT App Wallet and signed transactions with a version earlier than v8.1.0, act now. Version 8.1.0 was released on November 5, 2025. DCENT says this group should move its assets to a wallet protected by an entirely new recovery phrase. If you are unsure when you installed the app, which version you used, or whether you signed transactions, treat yourself as potentially affected until you complete the migration.

This scope concerns the software-based App Wallet mode. It is not a general alert for every DCENT hardware device. That distinction only provides protection when recovery phrases remain separate. A seed created or used on hardware and then entered into App Wallet is no longer isolated, and it requires the same preventive response.

What to do, in this order

Updating an application while keeping the previous recovery phrase is not enough. If that phrase may have been exposed, the keys derived from it may also be exposed. The migration must replace the wallet's cryptographic root.

1. Confirm that you have a secure copy of your current backup. Make sure you can read the phrase without entering it into websites, forms, browser extensions, or direct messages.
2. Update the app through the official channel to version 10.0.0 or later. Do not follow links from announcements, impersonated accounts, or alleged support teams.
3. Generate an entirely new recovery phrase. Do not reuse the old phrase or an account derived from it.
4. Make a test transfer. Confirm that you can receive and send a small amount with the new wallet before moving the full balance.
5. Move all assets to the new wallet. Check networks, tokens, NFTs, and secondary accounts that rely on the old phrase.
6. Retire the old phrase from use. Do not import it again into App Wallet, other software, or a new device.

DCENT's general FAQ recommends migration after exposure to App Wallet or when a recovery phrase has been shared between App Wallet and a hardware wallet. The goal is to remove dependence on a seed whose exposure level can no longer be considered acceptable.

App Wallet and hardware wallet are not the same

A hardware wallet is designed to keep the seed and transaction signing inside the device. App Wallet operates as a software wallet on the phone. These are different threat models and should not be grouped under one product label.

According to DCENT's published scope, users who used only the hardware wallet are not currently in scope if their hardware recovery phrase was never entered into App Wallet. That condition is critical. Sharing one seed between hardware and software modes removes the separation that limits the impact of an incident in the application layer.

For teams that custody funds, the operational lesson is clear: do not reuse recovery phrases across environments with different risk profiles. The convenience of holding one backup does not justify the larger blast radius.

Confirmed facts, reported claims, and open questions

DCENT published general migration instructions and, in a supplementary guide, specified that action is required for users who used App Wallet versions earlier than v8.1.0 and signed transactions. Version 8.1.0 was released on November 5, 2025. The company also publicly communicated updates about the incident. These are verifiable facts from its official communications.

Losses and the number of affected people require a different label. ZDNet Korea reported approximately 20 damage reports and nearly US$110,000 in losses, mostly in XRP. This is a figure attributed to that outlet, not a definitive accounting confirmed by DCENT.

Separately, XRPL.to said it had identified 1,552 wallets and 2,009,321 XRP linked to a drain. This is an independent, unconfirmed attribution. Ledger evidence can show transfers among addresses, but it cannot by itself prove how private keys were obtained or that every address belonged to a DCENT user. Turning on-chain clusters into a definitive victim list would go beyond what the available data supports.

DCENT has not confirmed a root cause or final losses. Nor should a technical hypothesis be presented as if it closes the investigation. In custody incidents, attribution discipline matters as much as response speed.

Technical hypothesis: why the signing surface deserves review

XRPL.to published a static review of App Wallet 9.2.1 and identified a remote web interface, missing origin checks, blind-signing risk, an unsigned remote engine, and a lack of certificate pinning. These observations describe a possible risk surface. If a remote component or approval flow does not provide sufficient authenticity, origin, and context, a user may authorize an operation without being able to reliably verify what they are signing.

However, this review does not prove the cause of the incident. It also did not evaluate the current v10.0.0 release. A static assessment of one specific version does not establish exploitation, infrastructure compromise, key extraction, or a causal connection to every observed transfer. Confirming any of those points would require forensic evidence, verifiable telemetry, and a technical statement from the vendor.

The broader lesson applies to every wallet. Signing flows should verifiably show the network, recipient, asset, amount, and consequences of approval. Product teams should reduce unauthenticated remote dependencies and separate key generation, storage, and use according to the threat model.

Conclusion

The priority is not to speculate about the attack vector, but to reduce exposure. If you fall within DCENT's scope, or cannot demonstrate that you are outside it, back up your information, update through the official channel, create a new recovery phrase, test the new wallet, and migrate every asset. Never type a seed phrase into a website or send it through direct messages, even if the other party claims to be support.

At Seclat, we help Web3 teams review signing surfaces, custody, frontend integrations, and flows that can turn an ordinary approval into a loss of funds. If your product manages keys, authorizes transactions, or integrates remote components, a security review should include these boundaries before an incident forces the work under pressure.

Sources

• DCENT, FAQ on required action for App Wallet
• DCENT, how to check whether App Wallet action applies
• DCENT, how to move assets from DCENT App Wallet
• DCENT Wallets, public update on X
• Yonhap News Agency, incident report
• ZDNet Korea, report on losses and complaints
• XRPL.to, DCENT App Wallet blind-signing review
• XRPL.to, attributed drain timeline