Cabinet
Back to Technology Insights
2026.09.01

Ledger Is Dropping `signEIP712HashedMessage` — All of LedgerJS Goes Deprecated and DMK Migration Becomes Mandatory

Ledger Is Dropping `signEIP712HashedMessage` — All of LedgerJS Goes Deprecated and DMK Migration Becomes Mandatory

What happened

Ledger's developer portal (last updated 2026-08-31) states that in September 2026 the Ethereum device app will drop support for signEIP712HashedMessage. That API is the hashed, blind-signing variant of EIP-712: the host passes the domain separator and message hash to the device rather than the typed data itself, and the device signs those values.

The portal is explicit that this removes the last working path for @ledgerhq/hw-app-eth, and declares that all LedgerJS packages — hw-app-* and hw-transport-* — are deprecated from that date. The destination is the Device Management Kit, and the page publishes the mapping: @ledgerhq/hw-app-eth to @ledgerhq/device-signer-kit-ethereum, hw-app-btc to device-signer-kit-bitcoin, hw-app-solana to device-signer-kit-solana. On the transport side, hw-transport-webhid maps to device-transport-kit-web-hid, hw-transport-web-ble to device-transport-kit-web-ble and hw-transport-node-hid to device-transport-kit-node-hid.

What is announced is "September 2026." No day is given — which, as set out below, is a practical problem rather than a concession.

Why blind signing is being cut

EIP-712 exists so that structured data can be signed in a form a human can read. The point is that the user understands what they are approving. signEIP712HashedMessage defeats that by never sending the structure to the device: all the device can display is two 32-byte hashes, so the signer sees neither the domain, nor the types, nor any field value.

That path survived for implementation reasons. Fully parsing typed data on device firmware means handling arbitrary type definitions in constrained memory, and support arrived slowly. In the meantime wallets and dApps shipped features using the hashed variant.

The consequences are visible in the last several years of loss patterns. Unlimited token approvals, orders authorising bulk NFT transfers, delegation of authority through relayers — each is established by a single EIP-712 signature, and each shows the user nothing but meaningless hex. The safety argument for a hardware wallet rests on final confirmation happening on the device screen; blind signing voids that argument. The fact that Ledger's portal now carries Clear Signing sections for both dApps and wallets shows where this sits: the removal is the end point of that policy, and as a design choice it says backward compatibility does not justify keeping a hole in the safety argument open.

What it takes for "displayable" to actually hold

Clear signing requires more than a device capable of parsing typed data. Widely used structures such as Permit get standard renderings, but a contract with bespoke type definitions needs additional information mapping field names and values to wording a human can act on. In other words, the user only gets to read "approve unlimited USDC to 0x…" when device support and application-supplied display metadata are both present.

That shifts part of the responsibility from the hardware vendor to dApps and wallets. The explanation that used to be "Ledger doesn't support this, so it can't be shown" becomes "we never supplied the display information, so it can't be shown." Ledger's portal carrying Clear Signing sections for both dApps and wallets is how that division of labour is being made explicit.

The other dimension is transport. The deprecation list includes hw-transport-webhid, hw-transport-web-ble and hw-transport-node-hid — packages abstracting WebHID in the browser, Web Bluetooth and Node.js HID respectively, each mapping to its own replacement. Products spanning several runtimes — a browser extension, a desktop app, a signing batch in CI — should expect migration and regression testing per environment rather than once.

Pitfalls to watch

First, what breaks is not the version of your package but the device app in the user's hand. Pinning your JavaScript dependency changes nothing: the hashed path disappears once the device's Ethereum app is updated, and the user chooses when that happens. So nothing breaks all at once at a flag date — it breaks user by user. Support will see an intermittent trickle of "it worked yesterday," with root cause depending on the version of an app you do not control.

Second, migrating to DMK is not a package rename. DMK separates device management, transport and signing into distinct layers, with connection establishment, device-state subscription and signing requests handled separately. Existing hw-app-eth-based code does not map one-to-one onto the new calling conventions despite the tidy migration table, so budget refactoring time.

Third, it is easy to miss that the deprecation is not limited to Ethereum. The trigger is the removal of an Ethereum app API, but what is declared deprecated is all of hw-app-* and hw-transport-*. Teams that only use the Bitcoin or Solana LedgerJS packages are on the same deadline.

Fourth, expect post-migration cases of "it cannot be displayed, so it cannot be signed." Clear signing presumes the device can interpret and render the typed data. If your contracts use bespoke type structures and no display metadata exists for them, the user experience degrades — or the signature is refused outright. Migration should come with an inventory of every typed-data structure you ask users to sign, each checked on real hardware to see how it renders.

[Technical Insights & Actions]

  1. This removal redefines where hardware-wallet safety comes from: not "the private key never leaves the device" but "what is being signed can be verified on the device screen." Any internal documentation or threat model that argues safety from key isolation alone needs the same revision. [Product / security] This month, inventory every data type for which you request a signature and identify the places where users are signing content they cannot read on device.
  2. Because the deadline is tied to device-app updates, failures arrive user by user rather than on a flag day. The same structure recurs in every integration that depends on a component installed in the user's environment — browser extensions, mobile apps, firmware. [Integrators / support] Within two weeks, make the device app version identifiable from telemetry or error logs so signing-failure reports can be triaged by version.
  3. A deadline stated only as "September 2026" is a risk, not a grace period. A removal without a fixed date hands your own validation schedule to someone else's discretion. [Contract developers / frontend] Do not wait for a date. Get the DMK migration branch into a staging environment early in September and run tests that simulate the old path being gone.

[Sources]

This article is a technical commentary based on publicly available information and is not investment advice.

Previous ArticleBase plans native account abstraction in Cobalt — EIP-8130 drops bundlers and EntryPoint, cutting USDC transfer gas 63.2% against ERC-4337Next Article Injective loses roughly $4.9M through a binary-options "no price, refund" path — 3h42m without blocks, and a gap between the official account and third-party analysis