When Keystone won’t sign

Incongruent Transaction

The transaction doesn't belong to the current wallet.
Please check the transaction information.

What the device is actually doing

The Keystone walks through every input in the PSBT asking one question: is there anything in here I can sign? It answers that from the PSBT’s BIP32_DERIVATION field, which carries three things per input.

1. The master fingerprint — four bytes identifying which seed this wallet came from
2. The derivation path — a position such as m/84'/0'/0'/0/5
3. The public key — what should come out at that position

If any one of the three disagrees with what the device holds, that input belongs to somebody else as far as the Keystone is concerned. When every input fails that test there is nothing left to sign, and you get this message.

So this error does not mean the QR was read badly. The QR was read perfectly, understood, and then rejected. That distinction matters — a reading problem would have surfaced as a parse error long before this screen.

How to narrow it down

Eliminate the three in order. It is the fastest route.

1. Is the account type right? If your wallet selected an m/84' account (addresses starting bc1q) but the Keystone was paired on m/49' (starting 3), the paths will never line up. This is the most common cause and the easiest to check — compare the first address your wallet shows against the first address on the device.
2. Is a passphrase involved? A passphrase produces an entirely different wallet. The device has to be in the same state it was in when you paired it.
3. Does the device hold more than one seed? The Keystone can carry several wallets. The name in the top-left corner is the one currently open — make sure it is the one you paired.
4. Is the wallet software writing the fingerprint wrong? If the first three all check out and it still fails, this is where you are. It gets its own section below.

Byte order in the fingerprint — an easy place to get it wrong

BIP174 states that derivation path elements are written as 32-bit little-endian integers. About the master fingerprint that sits immediately before them, it says only “the master key fingerprint as defined by BIP 32”. And BIP32 defines that fingerprint not as a number but as the first four bytes of a hash160 — bytes, in the order they appear.

So one field uses two different conventions back to back. The official test vectors make it obvious once you look:

… a5877110 | d90c6a4f | 00000080 | 00000080 | 04000080 …
            pubkey     fingerprint  path        path        path
            (tail)     (as-is)      (reversed)  (reversed)  (reversed)

The fingerprint d90c6a4f is not reversed. The path element 00000080 is 0x80000000 — hardened zero — written backwards.

Reverse the fingerprint along with the path and the device looks for a value that is no longer there. In our case the wallet fingerprint was 37b5eed4 and what went out was d4eeb537. The Keystone could not find itself, so it concluded — correctly, from its point of view — that this transaction belongs to someone else.

Once fixed, the identical transaction produced Confirm Transaction on the first try, with the right amount and the right input addresses.

No error text — the animated QR just keeps cycling, or the device freezes, or the scan never completes. More often than not this is a size problem rather than a failure.

Why it grows

Save a little every month for a few years and you end up with hundreds of UTXOs. Move them all at once and every one of them becomes an input in a single transaction, which overruns the device’s memory.

But the format matters more than the count. When a wallet builds a PSBT the legacy way, each input has to carry the entire previous transaction along with it. SegWit only needs the amount. The same hundred inputs can differ by an order of magnitude because of that alone.

• SegWit, 100 inputs — roughly 13 KB
• Legacy, 100 inputs — can pass 1 MB

Which is why the first thing to check is not “how do I split this” but what the wallet is set to. Changing the format alone often removes the need to split at all.

The order to work in

1. Work out why it got big — count, or format
2. If it is the format, fix only that
3. If it really is the count, measure how many the device tolerates, then split

Do not guess at step three. The limit moves with firmware and input type even on the same model. Measuring it is the only answer you can rely on.

If the device does not react in the slightest, the problem is delivery rather than content.

• Wrong format. Keystone expects a PSBT wrapped as ur:crypto-psbt. A raw base64 string rendered as a QR code means nothing to it.
• The QR is too dense. Packing more into each frame shrinks the modules past what the camera can resolve. Splitting into more frames is usually faster overall.
• The screen is too bright, or too dim. Turn the monitor brightness down and wipe the fingerprints off. This fixes it more often than it has any right to.
• The animation is too fast. With many frames, a fast cycle means the device spends its time waiting for the one frame it keeps missing. Slow it down.

If microSD is an option, it is the more reliable path. QR is convenient, but for large transactions the card wins.

When the Keystone finishes signing it shows you a QR code. That QR is not a finished transaction — it is a PSBT with the signatures filled in. Before it can go to the network, those signatures have to be assembled into scriptSig and witness fields, and normally the companion wallet is what does that.

Which is how people end up holding a valid signature with no idea where to put it. You have signed, and you still need another wallet to finish the job.

• Never type your seed phrase into anything. There is no signing problem whose solution involves entering a seed. Anything that asks for one is theft.
• Read the amount and address off the device screen. Whatever software built the PSBT, the device display is the last thing you can trust. That is the entire point of owning one.
• Send a small amount first. Watch the whole path work end to end before you move the rest.