Does a new wallet PIN change my blockchain address?

No. A PIN generally protects access to a device or application. Changing it does not replace an existing account private key or invalidate another copy of that key.

Can I keep the old address after replacing an ordinary account key?

For a conventional key-derived account, an independently generated key normally means a different address. Some smart accounts support changing signers while retaining the account address; use their documented authorization process rather than assuming this is possible for every wallet.

Why might a recovered wallet show different accounts?

A different passphrase, derivation path, network selection, account index, or unsupported asset can change what an application displays. A display mismatch does not establish that a new independent recovery root was created. Check compatibility through official documentation without sharing the backup.

Is connecting a hardware wallet to a dApp the same as sharing its seed?

No. A supported hardware connection can request signatures without revealing recovery words. It still requires review of the requested transaction or permissions. Typing the words into a software wallet is a separate action with different exposure.

Will an incoming payment automatically follow my new wallet?

No. A transfer to an old address still targets that address. Update saved exchange withdrawal destinations, payment instructions, and other senders after verifying the new destination. Do not assume an application label redirects funds.

Does a repeated DCENT action warning prove another theft occurred?

No. DCENT says its action-required screen can appear after assets have been moved. Reconcile the migration against the actual accounts and transactions; a repeated notice alone does not establish a new unauthorized transfer.

DCENT App Wallet Incident: Recovery Is Not Key Migration

Restoring a software wallet's recovery phrase on a hardware wallet does not replace its keys. If those keys may already be exposed, the practical migration is to create an independent wallet and transfer assets to it. The September 2026 DCENT App Wallet security notices make this distinction especially relevant: the same mobile application can display hardware-wallet accounts and also manage software-wallet keys.

Quick Answer

A new device is not necessarily a new wallet. Recovery recreates access to existing keys; migration moves assets to keys generated independently. For the DCENT incident, check your historical App Wallet use and shared recovery phrases against the official eligibility notice, then follow its current update and transfer instructions if action applies.

Key Takeaways

Whether keys ever entered software matters more than the device currently showing the balance.
Connecting a hardware wallet to its companion app is different from importing its recovery words.
A newer app version does not establish that an older wallet was never exposed.
A migration needs a verified destination, the correct network, and a check of assets beyond the main balance.
Recovery phrases must stay out of support chats, incident checkers, screenshots, and unsolicited forms.

What DCENT reported in September 2026

DCENT's September 17 status report says its first customer report of an unauthorized transfer arrived early on September 16, Korea Standard Time. The company describes an ongoing investigation and cooperation with authorities, exchanges, and security specialists. Those are the company's reported response actions, not a guarantee that assets will be recovered.

Its incident guidance published September 16 distinguishes App Wallet mode, where keys are created or imported on the phone, from hardware mode. DCENT said it had not confirmed an impact on hardware wallets themselves. It also warned about recovery phrases shared between the two modes. Pairing a device to view its accounts is not itself an import of the device's recovery phrase.

SlowMist's wallet incident register separately records the DCENT alert and the shared-phrase concern. That corroborates the existence of the reported incident; it does not independently settle its full technical cause. This article does not assign a cause or a final loss total. The useful decision for a wallet owner is whether the published action criteria apply to their setup.

The historical version matters

The September 17 eligibility notice identifies App Wallet signing in versions before v8.1.0, released November 5, 2025, as a relevant condition. It also addresses shared phrases and old App Wallet phrases restored onto hardware. Hardware-only users who never signed through App Wallet and never shared the phrase are distinguished from these cases.

Use the notice's full criteria and its in-app checking procedure, available in v10.0.0 or later. An inconclusive check is not a clean bill of health. A recent phone installation can also hide an older usage history. If your history is unclear, follow the official manual-check and support guidance rather than guessing from the version displayed today.

Why recovery does not replace a key

A recovery phrase is an input used to reconstruct wallet secrets. For BIP39 wallets, the BIP39 specification defines a deterministic conversion from the words and optional passphrase to a seed. The same inputs reproduce the same seed. Compatible derivation settings can then reproduce the same accounts. A different device enclosure does not change that calculation.

Recovery is valuable when access is lost but the backup remains trustworthy. A replacement device can recover a wallet after the original device fails. But that process cannot make another copy of a secret disappear. If somebody else can reconstruct the same signing key, securing your own copy inside new hardware does not prevent use of theirs.

Ethereum's account documentation explains the distinction between an account and the wallet used to interact with it. For an ordinary key-controlled account, signing authority comes from the private key. The chain does not require an attacker holding that key to use your particular phone, device, or app PIN.

This is also why adding a new account beneath a potentially compromised recovery root is not a reliable way to establish independent custody. A different visible address does not by itself prove a different recovery root. For the terminology behind this distinction, see how seed phrases and individual private keys differ.

Connection, restoration, and migration are different actions

These examples are illustrative wallet setups, not accounts attributed to the DCENT victims. They help identify which action actually changed control.

Example 1: A hardware wallet connected to a phone

Maya created her wallet on a hardware device. She uses a phone app to see balances and prepare transactions, but the device performs the signing. She has never typed the backup words into the phone. Seeing an account in that app does not mean the app holds its recovery secret. Her review should focus on the actual mode and usage history, not the presence of the app icon.

Example 2: A software backup restored onto hardware

Leo originally created a software wallet, then restored its words onto a hardware device to avoid paying transfer fees. His old address still shows the same assets because he restored access to it. He has changed where he now signs; he has not established an independent destination. If the original key is exposed, the funds remain under that key's authority.

Example 3: An independent destination and an on-chain transfer

Nora creates a fresh wallet using the new-wallet setup process on a trusted device, records its new backup, verifies a receiving address, and transfers assets from the old account. She can identify both the old and new addresses and the transfer between them. Her next task is to find anything still tied to the old account, including deposits expected later.

The distinction is consistent with Trezor's migration guidance, which recommends a new wallet and transfers rather than importing a software-wallet backup as a security upgrade. The principle applies across brands. Our hardware and software wallet comparison covers the broader signing tradeoffs.

Build a migration record before moving assets

For an affected DCENT setup, the official asset migration guide is the procedure to follow. It warns against restoring the current App Wallet phrase into hardware. DCENT's instructions put updating the official app before transferring assets. Do not replace that sequence with a generic tutorial or a direct-message offer.

A short inventory makes the process easier to verify. Record public account addresses, networks, asset names, known protocol positions, and the independently generated destination. Do not include recovery words or private keys. Mark each item as transferable now, subject to a protocol process, or still unresolved. This is an organizational aid, not a tool for determining whether a key is compromised.

For example, a portfolio might contain an immediately transferable token, a staked position with a withdrawal delay, and a future payment scheduled to the old address. A successful token transfer closes only the first item. Treating the entire portfolio as migrated would hide two remaining dependencies. Keep the record private: even public addresses can reveal your holdings when collected together.

Verify the destination separately

Use the receiving wallet's documented address-verification process. Where a trusted device display is available, compare the complete destination against that display. Confirm that both the wallet and receiving account support the asset on the intended chain. A familiar token symbol does not identify a network, and copying an address successfully does not prove it is the intended one.

For a planned migration, a small test followed by confirmation can reveal a network or destination mistake. During an active theft, additional transactions and delays may change the rescue risk; follow the specific incident guidance. Never assume that a completed test proves the old account is now safe or that the next copied address is unchanged.

Account for the funds needed to transact

Tokens may require the chain's native asset to pay transaction fees. Plan the order of operations so that moving the native balance does not strand a remaining token. However, an account monitored by a sweeper can lose newly supplied gas immediately. MetaMask's compromised-account guidance explicitly warns against adding gas when a sweeper is suspected.

If incoming funds disappear or transactions appear that you did not authorize, stop repeating the same funding attempt. Preserve transaction hashes and seek help through a verified response channel. No public blog can promise a successful rescue race. Our wallet-compromise response guide explains how the response changes with the type of exposure.

Check what remains after the first transfer

Use the migration record to distinguish three questions: has the asset moved, has the new account received it, and does anything still depend on the old account? These are separate checks. A wallet dashboard can omit an unsupported asset or an unfamiliar network, so a zero balance in one view is insufficient evidence that the process is finished.

Holdings: Review known native coins, tokens, NFTs, and accounts used on other networks.
Protocol positions: Check whether withdrawals, claims, or ownership changes require a separate documented process.
Future receipts: Replace saved withdrawal addresses, recurring payment destinations, and instructions you previously gave senders.
Authority: Identify any contract or smart-account roles still assigned to the old signer. Moving a balance does not automatically change those roles.

Do not interact with every unknown token that appears during this review. Record recognized holdings first and use official protocol documentation for positions you actually opened. An unsolicited asset with an embedded website or a claim prompt can turn a migration into a second incident.

For smart accounts, the control structure may differ from an ordinary private-key account. A signer can sometimes be replaced through the account's authorized process. That is a separate operation from restoring a seed or moving a token, and it needs account-specific verification. Do not assume a successful transfer removes an old signer, module, or delegated permission.

What hardware and backups can actually change

A correctly configured hardware wallet can keep newly generated signing secrets away from general-purpose software. It can also give the user a separate place to review supported transaction details. Neither function revokes someone else's knowledge of an old secret, reverses a completed transfer, or repairs a vulnerable third-party protocol.

A backup preserves access to the wallet it represents. Making that backup more durable does not create independent keys. Label retired and current backups clearly without exposing their contents, and preserve the information needed to investigate unresolved positions. Avoid destroying the only access path while assets or claims still depend on it.

For UKey users, follow the official UKey Help Center for the specific device and recovery workflow. Device signing and recovery backup serve different purposes. Choosing a new storage product should follow the key-history decision, rather than substitute for it.

For a broader checklist after migration, use the guide to protecting keys, backups, and signing. For the distinct case of replacing a missing device while retaining a trustworthy backup, read hardware-wallet loss and recovery steps.

Reviewed September 22, 2026. Incident-specific statements above are attributed to the dated official notices. This is security education, not a guarantee of recovery; consult the current incident instructions before an irreversible transfer.

DCENT App Wallet Incident: Recovery Is Not Key Migration

Quick Answer

Key Takeaways