Sparrow’s reviewed Satochip ECDSA path sends a transaction digest. Check that protocol boundary before treating a custom card’s refusal as a wallet fault.
In Sparrow 2.5.6’s reviewed Satochip ECDSA signing path, the card receives a transaction digest, not the complete transaction structure. A custom card that rejects that digest-signing command cannot use this path merely because its interface is otherwise Satochip-compatible. Check the protocol mismatch before changing wallet settings.
This is a developer integration question, not a diagnosis of every retail Satochip signing failure. In a November 9 request, the MyBTCwallet integrator described firmware that deliberately disables unrestricted hash signing and instead expects transaction inputs, outputs and related data for on-card checks. The report names Sparrow 2.5.3. HideFi checked the later released 2.5.6 code to see whether the relevant path still sends a digest.
Follow the signing payload, not the PSBT label
A PSBT is a partially signed Bitcoin transaction: a container for transaction data and signing information. Sparrow can work with that container without forwarding the whole container to every signing device.
In SatoCardApi, Sparrow selects the signing input and derivation path. Its ECDSA signer then calls cardSignTransactionHash with hash.getBytes() and no challenge-response value. The distinction is where transaction interpretation happens: having a PSBT on the host does not show that the card received its inputs and outputs.
The command builder requires a 32-byte digest. With no challenge-response, its command data is those 32 bytes. The instruction constant identifies that operation as 0x7A. This describes the signing-command payload; it makes no claim that the transport is unencrypted.
A deliberate refusal is different from a missing signer
Consider the integrator’s stated design as a conditional example: the card accepts the connection but refuses 0x7A because it requires transaction-aware validation. Retrying that same digest-based request does not supply the missing transaction structure. That is a compatibility boundary, rather than evidence that a seed or account needs replacing. HideFi did not reproduce a card error or verify the custom firmware.
The reviewed message-signing method also uses the hash-signing command. Disabling it can therefore affect more than transaction signing. Taproot uses a separate Schnorr branch; this ECDSA explanation should not be stretched into a diagnosis for every signature type, PIN error or card-detection failure.
If the actual failure is a duplicate key during import, follow the separate Sparrow extended-key warning guide. That failure occurs before the command boundary discussed here.
The supported next step is a protocol proposal
The repository collaborator’s response directs the transaction-aware proposal to the upstream Satochip applet protocol rather than a vendor-specific Sparrow extension. Future consideration is conditional on upstream adoption; the response is not an announcement of released support. The same reply also cautions that on-card hash computation alone cannot provide output confirmation on a device without a display.
For an integrator, the useful outcome is a precise comparison between the card’s accepted commands and Sparrow’s actual signing payload. Keep a proposed transaction-aware extension separate from current compatibility. This guide offers no firmware patch, protection-disablement or funded signing test, and no guarantee that a proposed extension will be adopted.
Official sources
Product interfaces and recovery policies can change. Confirm the current steps before acting.