🐞 Ledger returns `EthAppCommandError` 6a80 (invalid data) when signing ERC-20 transfer on Arbitrum (blind signing enabled)

[superKalo]

Attempting to deposit USDC into the wETH vault on Arbitrum via app.katana.network fails at sign step on Ledger with 6a80 Invalid data, despite Blind signing = Enabled.
Same flow signs fine with Trezor and with a hot wallet.

You can reproduce with Ledger + Ambire Wallet (but also with Rabby and MetaMask).

Steps to reproduce:

1. Connect Ledger and unlock; open Ethereum app.
2. Ensure Blind signing is enabled in the Ethereum app settings.
3. On https://app.katana.network/ choose the wETH vault on Arbitrum and deposit USDC (receiving yvvbETH).
4. Initiate the deposit; dApp prepares an ERC-20 transfer transaction to USDC contract on Arbitrum.
5. When prompted, send the transaction for signing to Ledger.

Expected result:
Ledger shows transaction review (or blind-sign prompt) and allows signing.

Actual result
Signing fails immediately with:

{
  "status": "error",
  "error": {
    "_tag": "EthAppCommandError",
    "errorCode": "6a80",
    "message": "Invalid data"
  }
}

Raw signing input:

02f88c82a4b113830137f483f3b6a082df4494af88d065e77c8cc2239327c5edb3a432268e583180b864a9059cbb000000000000000000000000f70da97812cb96acdf810712aa562db8dfa3dbef0000000000000000000000000000000000000000000000000000000000104de9fbf299033e365d673d3054146d84c44078643b3305a71004b574076d06939920c0

(in hex, that I convert to bytes when sending to the device)

Environment:

• Device: Ledger Nano X (latest firmware 2.5.0)
• Ethereum app: 1.18.1
• Blind signing: Enabled
• Transport: WebHID (@ledgerhq/device-transport-kit-web-hid@1.2.0)
• SDKs:
  • @ledgerhq/context-module@1.6.0
  • @ledgerhq/device-management-kit@0.8.0
  • @ledgerhq/device-signer-kit-ethereum@1.6.0
• Derivation path: m/44'/60'/0'/0/0
• Network: Arbitrum One (chainId 42161)
• dApp: https://app.katana.network/ (deposit USDC → receive yvvbETH)
• Chrome v140.0.7339.133
• MacOS 15.6

[superKalo]

No. Waiting for a reply from the Ledger team since about 1y.

[superKalo]

@r3764394-eng thanks, but I don’t think a support agent is the right path here.

I’m a developer integrating your SDK, and I’m reporting what appears to be a reproducible bug directly against the package, with a minimal example and evidence.

Could you please involve someone from the engineering team so we can investigate and fix the root cause? I’d much rather help improve the SDK than go through a generic support flow.