Ledger’s DMK migration changes wallet connections

Ledger is changing the connection software

Ledger is moving software wallets from its older LedgerJS connection libraries to the Device Management Kit, or DMK. The company warns that legacy integrations may encounter signing failures from mid-September 2026. Wallet developers handle the migration. Ledger says the change does not alter users’ recovery phrases, accounts or private keys. A failed connection should therefore be investigated as a compatibility issue before assuming that a wallet needs recovery.

What the connection layer actually does

A software wallet and a hardware signer have different jobs. The software prepares an action; the signer must receive enough information to let its owner review and approve it. Ledger’s developer documentation describes DMK as a way to simplify this communication, so wallet teams need less knowledge of the low-level messages exchanged with a device.

The documentation identifies practical weaknesses in LedgerJS, including unexpected disconnections when opening an app and restrictions around simultaneous device connections. DMK addresses these integration problems and supports communicating with multiple devices. However, the same documentation acknowledges gaps in some blockchain-specific signing components. That qualification matters: a developer needs to check support for the particular chain and transaction, rather than treating the name of a library as proof that every action works.

A useful way to investigate a failed signature

Consider an illustrative case: Maya can see an account in her wallet, but attempting a token transfer produces a connection error. She also uses another software wallet with the same device. The useful first question is where the attempt stops. Does the software fail to detect the signer? Does the device show an app but no transaction? Or does the transaction appear and then get rejected?

Maya can record the wallet name and version, the network, the action she selected, the connection method and the exact error. She can also note whether the device was locked at the time. Those observations create a reproducible report. “My hardware wallet stopped working” gives a support team very little to investigate; “this version fails before displaying this transaction over this connection” narrows the problem considerably.

This example is a troubleshooting method, not a diagnosis of a particular wallet. It deliberately avoids assuming that a visible balance proves signing works, or that a signing failure proves funds are missing. Both conclusions would go beyond the evidence collected.

How a wallet team can make the change understandable

For a developer, a useful acceptance test follows a person’s task from start to finish. A test that merely detects a connected device is too narrow. A proposed test sequence would include connecting, selecting an account, reviewing a representative transaction, rejecting it once, and successfully approving a fresh attempt. The team should also check the message displayed when the device is unavailable.

Suppose a wallet offers transfers, swaps and contract approvals. A clear release note would identify which of those paths has been tested and which device or connection combinations were covered. That is more informative than a single “Ledger supported” badge. It also gives users a reason to update and a precise description of any remaining limitation. These are suggested release-quality checks, not claims about tests already performed by Ledger or a wallet provider.

What a reader should look for next

The most useful follow-up is the release note for the software wallet you actually use. Look for a named version, an explanation of the affected actions and a way to report a problem. An undated compatibility claim is less helpful when diagnosing a change that appeared after a particular update.

For example, if the wallet’s note names a newer release than the one installed on your computer, that is a concrete lead to investigate through its normal update process. If the versions already match, send the reproducible report rather than repeatedly trying the same unexplained failure. The aim is to establish whether the supported transaction path works in your setup. That gives this infrastructure change a practical meaning: fewer ambiguous interruptions between deciding what to do and reviewing what you are about to sign.