Verify Your Addresses on Your Hardware Wallet

When you open your vault and Keystody shows you a receive address, that address was computed on Keystody's servers. At each address index your three extended public keys each produce a child public key; those three are sorted (BIP-67), assembled into a 2-of-3 witness script, and hashed into the bc1q… string on your screen. The maths is deterministic — the same keys always produce the same addresses — and it is verified against Bitcoin Core on every build we ship.

But determinism is not the same as trust. The question a careful person asks is not “is the code correct today” — it is “what if the thing showing me this address were compromised?”

A stolen key cannot do it: your vault needs two of three signatures, and Keystody holds none of them. What a compromised coordinator could do is show you the wrong address. Not steal from your vault — send your next deposit somewhere else entirely. If someone replaced the address on that screen with one of their own, nothing about the page would look different. There is no signature to check, no warning to ignore. You would copy it, send Bitcoin to it, and it would be gone.

This is the honest limit of what any coordination platform can promise about itself. It is also completely solvable, and the solution is already in your hand.

Your hardware wallet holds one of the three keys and re-computes the address from your vault's full key set — a 2-of-3 address is a function of all three public keys, not just one — on a screen no website can reach.

That makes the key set itself worth checking once, and how you do it depends on your device.

Ledger registers your vault as a named policy: the first time you use it, the device shows you the quorum and all three keys and asks you to approve them. Read the three fingerprints on that screen and compare them to the descriptor on your Recovery Document. Ledger then remembers the approval, and any change to the key set forces a fresh approval you cannot miss.

Trezor has no equivalent stored policy — it is handed the vault's key set each time. So do the comparison deliberately: open your Recovery Document and check the three fingerprints against the ones shown when you set the vault up. Once you know the key set is right, address verification behaves the same as on Ledger.

Coldcard and other air-gapped devices store the multisig config on the device, so the import screen is the check — see below.

Why it matters: a coordinator that swapped two cosigners for its own keys would produce an address that genuinely is a 2-of-3, and the device would display it quite happily. Checking the fingerprints once is what closes that door.

So when the address on the device matches the address on your screen, you have confirmed something meaningful: two independent systems, one of which is offline and in your possession, agree that this address belongs to your vault. A compromised server cannot fake that.

Do this the first time you use a vault, and any time you are about to receive a meaningful amount.

1. In Keystody, open your vault and go to receive an address.
2. Choose to verify on device. Keystody will ask your hardware wallet to display the same address.
3. Connect and unlock your device.
4. Read the address on the device screen — not on your computer. Compare it to what Keystody shows.
5. Compare the whole string if you can — it is 62 characters and takes ten seconds. If you abbreviate, ignore the bc1q prefix that every address shares and compare at least the eight characters after it and the last eight.

If they do not match, stop. Do not send anything. Contact us at support@keystody.com, and if you believe you are looking at an attack rather than a bug, report it privately.

Keystody supports on-device verification for both Ledger and Trezor. For Coldcard and other air-gapped devices, first import the vault's multisig config onto the device (use the Coldcard/BlueWallet or BSMS export). The device shows the quorum and all three keys for you to approve — that is the moment to check them against your Recovery Document. Afterwards, Address Explorer shows the vault's addresses on the device screen.

The same principle applies with more force when Bitcoin is leaving your vault.

When you sign a transaction, your hardware wallet shows you what you are actually authorising: the destination, the amount, the fee, and the change. Read those on the device, every time. The device is signing what is on its screen, not what was on your browser's.

Here is the part that surprises people: your device does not print your own change on screen. It recognises change belonging to your registered vault and validates it silently — which is exactly what makes the check easy.

Because if a coordinator redirected your change somewhere else, the device can no longer recognise it as yours, and it appears as an extra payment to an address you never chose. So the rule is simple: the device should show exactly the payments you intended, and nothing else. One unexpected recipient is the attack.

Verifying on device confirms that an address belongs to your vault. That is the specific thing worth confirming, and it is enough to defeat address substitution.

It does not check that Keystody's records are complete, and it is not a substitute for keeping your recovery descriptor safe and offline. Those are different problems with different answers — the Security & Trust page covers both.

It is also worth saying what verification is not: a sign of distrust. Verifying on-device is a normal, expected part of multisig operation. Every serious coordinator recommends it, and the reason is the same everywhere — it is the one check the software cannot perform on its own behalf.

Fifteen seconds, on the device you already own, and the only attack that could take your coins stops working.